From: tabemann@gmail.com   
      
   On 6/20/24 05:10, albert@spenarnc.xs4all.nl wrote:   
   > There was a lecture on interpreted control structure in Zeptoforth.   
   > That was in the forth2020 conference of april 2024   
   > I was surprised. In particular it doesnot work for looping   
   > building up the dictionary, e.g.   
   >   
   > CREATE CRCTable   
   > 100 0 DO   I 8 0 DO   
   >      DUP >R   1 RSHIFT   R> 1 AND IF CRC64_POLYNOMIAL XOR THEN   
   > LOOP ,   LOOP   
   > This IMO is the most useful application.   
      
   The reason for this is that interpreted control structures in zeptoforth   
   really are not interpreted at all. Rather, they are treated as saving   
   the RAM HERE pointer for later restoration and temporarily putting   
   zeptoforth into compilation state, with the HERE pointer pointing into   
   RAM, until all the outstanding control structures are closed, where then   
   all the newly compiled code is executed and then promptly forgotten and   
   the original RAM HERE pointer is restored (and if the HERE pointer   
   previously pointed into flash, pointing HERE into flash again).   
      
   As a result new code or data cannot be written to the dictionary,   
   because it will all be forgotten at the end. Also, words that are not   
   valid in compilation state cannot be used for the very reason that   
   zeptoforth *is* in compilation state between the initiating controlling   
   control structure and its closing.   
      
   > Other disadvantage of this implementation was that an error leads   
   > to a restart.   
      
   An error results in the HERE pointer being rolled back to its   
   original position, unless a crash occurs, which may or may not be   
   successfully recovered from, but after which it is wise to treat   
   zeptoforth to be in an undefined state and reboot once one is done   
   debugging the crashed state. (Is this what you mean by "a restart"?)   
      
   > The following simple mechanism is in ciforth, and a small   
   > adaptation runs on gforth 7.3, presumably portably, or at least   
   > quasi portably.   
   > It compiles temporarily to a kind of far PAD, then abandons the code   
   > after executing it.   
   > I commented the word TRIM out, this isn't portable (but instrumental   
   > to ciforth classes.)   
      
   zeptoforth makes no assumptions about the position of the top edge of   
   the main task's dictionary because new tasks are allotted from high   
   memory down, and if memory were allotted in high memory it would either   
   be overwritten by new tasks, or would be permanently lost if a new task   
   were created, depending on how exactly this were implemented.   
      
   Travis   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)