[comp.lang.forth] BLOCK interpretation

wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (07/11/90)

> The implementation of SOURCE that Mitch describes is better than the
> traditional source stream logic but still relatively inefficient.

> In LMI systems, the source stream itself is cached on a block-by-block
> or line-by-line basis before INTERPRET is called.  Each time WORD
> executes it merely needs to use the 2EQU SOURCE (which functions like a
> 2CONSTANT to provide the base and length of the input stream) and >IN to
> parse off the next token. Nothing inside the INTERPRET loop ever looks
> at TIB, #TIB, or BLK at all.

The point of my posting was to show how Robert Berkey's suggested
"quick test to see if the input stream cache is still valid"
code sequence could apply to an LMI-style interpreter.

The code I posted was shown in high level for clarity, but in a highly-
optimized system like LMI's, it would almost certainly be written
in assembler.  In that case, 2EQU SOURCE would be replaced by a code
word which does the following (shown in pseudo-assembler):

    CODE SOURCE  ( -- )
       MOVE <BLK>  to register	\ <BLK> is "memory location containing BLK"
       CMP  <SBLK> to register	\ <SBLK> is the "saved block cache tag"
       0= IF			\ The usual case; BLK hasn't changed
          PUSH <IBASE>		\ Base address of input stream cache
	  PUSH <ILEN>		\ Length of cached input stream
	  NEXT
       THEN
       \ If the input stream cache is invalid, do whatever is necessary
       \ to refill it.  This probably involves getting back into high
       \ level code.
       ...

Robert's noted that this "quick test" code (MOVE CMP BRANCH) should take
maybe a couple of microseconds, an insignificant fraction of the total
work of interpreting a word.  For a 1,000,000 word program, this would add
2 seconds to the compile time.

Mitch