Re: CREATE

Harold wrote:
....

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.

Yes, it was considered at length. That is, in fact, the reason that DOES> is defined to work only with CREATE, so VARIABLE, CONSTANT, and other defining words can be optimized differently without penalty. When it became common practice to implement DOES> with a CALL instead of the longer formulations previously common, it was no longer considered necessarily to have an extra word just to prepare for DOES>.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================
.

Relevant Pages

  • Re: no-op function pointer
    ... subroutine is just as fast as any other branch. ... using an "execute" instruction that executes an instruction stored ... own CPU cycle anyway, and with a two-instructions-per-cycle CPU, ...
    (comp.lang.c)
  • 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: CREATE
    ... possible code field address. ... defining word's definition. ... compiled with the more general subroutine call instruction that could ... The only difference being that, at compile time, VARIABLE ...
    (comp.lang.forth)
  • Re: Hi
    ... subroutine return instruction on an ARM1/2/3 - even in compiled code. ... flags preserved). ...
    (comp.sys.arm)
  • 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