Re: Stack vs stackless operation

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.

Yes, but I actually by "Forth machine" mean the
work of the internals of the Forth compiler (and that
has been nicely described by Brad), not just NEXT alone.
I do realize that proposed OOS technique may not be
that advantageous in case of more sophisticated compiler
that's doing fine job for the programmer. Still not
everywhere such compiler is available; if I find enough
time during coming weekend, I'll try to do some
exercises and comparison using Camel Forth for 8051.
I expect the difference may be really big.

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.

Never used that one. I know nothing about Machine Forth.
BTW: is it available for download anywhere (if not
commercial/restricted)?

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.

Yes, I agree it's not necessary - still in particular
cases it may mean noticeable speed-up. In the other
cases - and especially for mentioned optimizing
compilers - it may not make much sense, probably.
--