Re: CREATE

Op Tue, 21 Jul 2009 16:28:14 -0700 (PDT) schreef Harold:

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.

Have good look at the CamelForth implementation for the 1802.
Indeed, it uses various SEP instructions for colon definitions,
CONSTANT and VARIABLE. But you can not tick them and use >BODY to
get to their contents. That's not even allowed in the Standard.
But words built with CREATE are tickable and subsequently >BODY will
return the correct data address. All according to the current
Standard.

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

.

Relevant Pages

  • 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: Could an Intel 486 wake up with FC3
    ... > On the sidenote, since i586 is minimal supported platform, I don't know ... There were very few instructions added to the instruction set between ... relevant), system rebooted between runs, just different compile flags. ... James Wilkinson ...
    (Fedora)
  • Re: Create, edit file list?
    ... Randy - I just redid ... Using "Start with Full Compile" ... > from the site code following the instructions there and it worked right ... folders on a drive using the DirListBox and FileListBox controls. ...
    (microsoft.public.vb.general.discussion)
  • Re: real time linux
    ... >> least that these new controls would have to use technology which is ... >> ability to edit and compile on the control. ... > B) Pick up the Nail ... > A vector architecture would issue all of the instructions at once, ...
    (alt.machines.cnc)
  • 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)
Loading