Re: History of CREATE...DOES> ?

In article <2024Jul25.141725@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

fig-Forth has <BUILDS...DOES> (and the associated implementation with
an extra cell that points to the threaded code behind DOES>).
Forth-79 standarizes CREATE...DOES>; and a popular implementation of
that is to trampoline through the place behind DOES> to the actual
code address.  Where did that implementation and CREATE..DOES> in
general come from?

In 2000 I wanted to create a simple Forth in fig-Forth vein,
in fact merely an iso-fication of fig-Forth.
In 1993 for the transputer Forth, I proposed to get rid of
NAME>XT XT>BODY LINK>NAME FORGET>LINK ,what have you, and coined the "dea"
concept that is a token/address/handle to access all the properties
of a word. All words that handle a "word" now uses its dea, and obviously
the dea can serve as an execution token in the sense of iso.
No longer is replacing the execution token behaviour
affecting the identity of a word. No longer is it a problem
if a word has no name. You can unlink a word from its wordlist
and link it elsewhere. Etc.

I arrived at uniform cell wide fields with names
CFA DFA FFA LFA NFA [SFA] [XFA]
CFA pointer to executable code
DFA pointer to DATA
FFA flags
LFA pointer to next dea
NFA pointer to a non-brain-damaged string, i.e. one cell count + chars.
[ options SFA pointer to source code ]
[ XFA optional experimental extra pointer ]

Now it became clear that the iso-requirements of CREATE demand that a
CREATEd words have two part in the DATA field: a pointer to high
level code and the body in the ISO sense. Both fields are modifiable.
Ting came to a similar conclusion implementing a Forth in a c-type
oo language (I remember Java) for a need to two separate fields.

So it is a natural idea following from iso-demands, but maybe
hold back with implementation tricks. Notably a CALL to a the common
code with this CREATE class, immediately followed by the data,
because a pointer to this would be pushed on the stack, saving
an instruction and one byte. Forth has no problems with spaghetti
code, but spaghetti data is equally bad.
The entanglement of the data and code fields in this way,
may no longer advantageous for modern processors.
Moreover the 56 bytes a Forth header takes is no longer a
consideration with Gbyte memories.

>
My guess is that it did not come from Forth, Inc.: At the time of
Forth-79 AFAIK Forth, Inc.'s Forths were miniForth and microForth.
And given that fig-Forth started out as a port of microForth to the
6502, I doubt that Forth, Inc. used CREATE..DOES>.  Also, Forth,
Inc. ignored Forth-79 (IIRC Elizabeth Rather described it as
inconsistent or some other statement that she would not have made if
Forth, Inc. had actually accepted and implemented Forth-79).
>
At least dxf is very well versed in historic Forth developments.
Maybe he or somebody else can answer my question: Where did the
implementation described above and CREATE..DOES> in general come from?

It is a direct consequence of ISO. It has been independantly
invented (if that is the proper word) at least two times by
TING and me.

>
- anton

--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring.            - the Wise from Antrim -