Re: Optimizing stack access for a stack based VM

On Sep 13, 9:31 pm, Hans-Peter Diettrich <DrDiettri...@aol.com> wrote:
> Alex McDonald wrote:
> >>There are separate address space for (1) code, (2) data, (3) stack.
>
> > The separation between code and data isn't required in Forth (although
> > there may be advantages in certain architectures that treat each space
> > differently, or don't like mixing of code and data).
>
> IMO Forth is not a direct solution for the OP, since...


I suggested the OP look at Forth, not implement Forth. There are many
good ideas in Forth, and he can avoid many of the problems others have
solved by doing a bit of research. Generating stack-based IL from
Pascal is not difficult; getting the right stack-based IL is the hard
part.


> > "Variables" in Forth are words that push their addresses on the stack,
> > as in the @ and ! example given above. Forth also has a value, or a
> > self fetching variable.
>
> Forth has no local variables (for recursive calls),


Your assertion is not true; Forth has local variables (actually, self-
fetching values) which can be used in recursion. Preferably, the stack
can be used for recursion and avoid locals entirely.


: fib ( n -- n' )
      dup 1 > if
            dup 1- recurse swap 2 - recurse +
      then ;


> the implementation of e.g. loop counters requires two separate
> stacks, for data and return addresses.


Forth requires two stacks (data and return) as a matter of course, and
not just for loop counters or variables. This is not a big problem
even in architectures that don't directly support any stacks at all
(as I'm sure you know, stacks are easy to implement without hardware
support).


And loop counters and local variables can be held on the return stack,
but don't need to be. If recursion isn't used, the stack sizes
required for the data and return stacks need not be large; certainly,
tens of entries are more than adequate for most purposes, and rarely
if ever a requirement for hundreds or thousands of entries.


> Calling subroutines (Forth: compiled words) for the retrieval of
> references to variables IMO also is overkill, in a VM other than the
> Forth machine itself.


Your assumption is that Forth is exclusively subroutine-threaded.
Threaded code Forths are easy to implement, debug and port, which is
why threaded implementations are often described in the literature.


But modern Forths generate native code, rather than threaded code, and
(for instance) would compile this primitive and simplistic variable
increment;


x @ 1 + x !


into native code;


add x, 1


--
Regards
Alex McDonald

Return to the comp.compilers page.
Search the comp.compilers archives again.