Re: CREATE

On Jul 21, 1:26 pm, Elizabeth D Rather <erat...@xxxxxxxxx> wrote:
MarkWills wrote:
Elizabeth said:

Another point that you seem to be missing is that DOCOL isn't the only
possible code field address.  You've now added DOVAR to your repertoire,
but the important thing is that every defining word may have a unique
code field address (I say "may" because they don't *have* to be unique;
CREATE, VARIABLE, and BUFFER: may share the same, for example).

DOES> works by patching the default code field address left by CREATE in
an instance definition to point to the code following DOES> in the
defining word's definition.

Cheers,
Elizabeth

With regards to CREATE, I think that the decision to merge <BUILDS
into CREATE unnecessarily restricts certain implementation techniques.

Consider an architecture that has a limited number of one-byte fast
subroutine call instructions, e.g. the Intel 8080 RST, or the RCA 1802
SEP instructions. In a direct-threaded implementation, these one-byte
calls can be dedicated to the run-time semantics of the most common
defining words like CONSTANT, VARIABLE, USER, and docolon. But you
can't compile a one-byte call for a CREATE'd object, because you don't
know whether or not its runtime semantics are going to be overridden
by a later occurring DOES>. So a CREATE'd object has to be compiled as
a more general (i.e. larger and slower) subroutine call instruction
with a modifiable destination address, typically 3 or more bytes long.
If the default runtime semantics of a CREATE'd object are never
overridden with a later DOES>, this wastes space and time.

In the old Fig-Forth days, the word <BUILDS was a signal to the
compiler that there would be a following DOES>, so it needed to be
compiled with the more general subroutine call instruction that could
be overridden. On the other hand, the Fig-Forth CREATE couldn't be
followed by DOES>, so the compiler could use a (faster) one-byte
subroutine call instruction, actually the same runtime semantics as
VARIABLE. The only difference being that, at compile time, VARIABLE
also does a CELL ALLOT.

The decision to merge <BUILDS into CREATE prevents this sort of
optimization. ANSI Forth is usually pretty good at precluding
different implementation techniques, so I wonder whether the
standardization committee considered this issue when the decision was
made to eliminate <BUILDS.
.

Relevant Pages

  • Re: CREATE
    ... possible code field address. ... defining word's definition. ... SEP instructions. ... The only difference being that, at compile time, VARIABLE ...
    (comp.lang.forth)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > the existence of an instruction to draw the proper comparison. ... > memory address pointed to by register based on the tested condition. ... > case is precisely the differing object code for the unconditional branch, ... Won't compile as is ... ...
    (comp.lang.cobol)
  • Re: Managed C++ Code Generation Bug?
    ... >> Not defining a static variable that you use in a program is undefined ... I've just managed to compile it as managed C++. ... I think this must be to do with the CLRs handling of C++ static const ... This is why you can't bind it to a reference, ...
    (microsoft.public.dotnet.languages.vc)
  • Re: CREATE
    ... into CREATE unnecessarily restricts certain implementation techniques. ... subroutine call instructions, e.g. the Intel 8080 RST, or the RCA 1802 ... compiled with the more general subroutine call instruction that could ... The only difference being that, at compile time, VARIABLE ...
    (comp.lang.forth)
  • Re: Illegal instruction (core dumped)
    ... (snip regarding "Illegal instruction (core dumped)") ... > 1) overwriting the compiled code by writing to an invalid array ... any compile time errors. ...
    (comp.lang.fortran)
Loading