In article <2024Jul25.141725@mips.complang.tuwien.ac.at>,   
   Anton Ertl  wrote:   
   >fig-Forth has  (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 -   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)