Re: Stack vs stackless operation

zbigniew2011@gmail.com (LIT) writes:

I mean the description how the "Forth machine" works:
>
"Assume SQUARE is encountered while executing some other Forth word.
Forth's Interpreter Pointer (IP) will be pointing to a cell in memory --
contained within that "other" word -- which contains the address of the
word SQUARE. (To be precise, that cell contains the address of SQUARE's
Code Field.) The interpreter fetches that address, and then uses it to
fetch the contents of SQUARE's Code Field. These contents are yet
another address -- the address of a machine language subroutine which
performs the word SQUARE. In pseudo-code, this is:
>
  (IP) -> W  fetch memory pointed by IP into "W" register
             ...W now holds address of the Code Field
  IP+2 -> IP advance IP, just like a program counter
             (assuming 2-byte addresses in the thread)
  (W) ->  X  fetch memory pointed by W into "X" register
             ...X now holds address of the machine code
  JP (X)     jump to the address in the X register
>
This illustrates an important but rarely-elucidated principle: the
address of the Forth word just entered is kept in W. CODE words don't
need this information, but all other kinds of Forth words do.
>
If SQUARE were written in machine code, this would be the end of the
story: that bit of machine code would be executed, and then jump back to
the Forth interpreter -- which, since IP was incremented, is pointing to
the next word to be executed. This is why the Forth interpreter is
usually called NEXT.
>
But, SQUARE is a high-level "colon" definition… [..]” etc.
>
( https://www.bradrodriguez.com/papers/moving1.htm )
>
Many of these steps in particular cases can be avoided
by the use of proposed OOS words, making (at least sometimes)
the Forth program faster — and, as a kinda "bonus", clarity
of the code increases.

What Rodriguez describes above is NEXT.  As I mentioned in the ealier
posting, using a VM with VM registers reduces the number of NEXTs
executed, but if you go for dynamic superinstructions or native-code
compilation, the number of NEXTs is reduced even more.  And this can
be done while still working with ordinary Forth code, no OOS needed.
And these kinds of compilers can be done with relatively little
effort.

Probably in case of the "optimizing compiler" the gain
may not be too significant, from what I already learned
here, still in the case of simpler compilers — and maybe
especially in the case of the ones created for CPUs not
that suitable for Forth at all (lack of registers, like
8051, for example) — probably it may be advantageous.

I cannot speak about the 8051, but machine Forth is a simple
native-code system and it's stack-based.

By the "Forth machine" I mean that internal work of the
Forth compiler - see the above quote from Brad's paper
- and when we don't need to "fetch memory pointed by
IP into "W" register, advance IP, just like a program
counter" etc. etc. — replacing the whole process,
(which is repeated for each subsequent word again and
again) by a short string of ML instructions — we should
note significant gain in the processing speed.

Yes, dynamic superinstructions provide a good speedup for Gforth, and
native-code systems also show a good speedup compared to classic
threaded-code systems.  But it's not necessary to eliminate the stack
for that.  Actually dealing with the stack is orthogonal to
threaded code vs. native code.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/