Uri Guttman <[EMAIL PROTECTED]> writes:
> DS> The one handy thing about push and pop is you don't need to go
> DS> tracking the stack manually--that's taken care of by the push and
> DS> pop opcodes. They can certainly be replaced with manipulations of
> DS> a temp register and indirect register stores or loads, but that's
> DS> more expensive--you do the same thing only with more dispatch
> DS> overhead.
>
> DS> And I'm considering the stack as a place to put registers
> DS> temporarily when the compiler runs out and needs a spot to
> DS> squirrel something away, rather than as a mechanism to pass
> DS> parameters to subs or opcodes. This is a stack in the traditional
> DS> scratch-space sense.
>
>i agree with that. the stack here is mostly a call stack which
>save/restores registers as we run out. with a large number like 64, we
>won't run out until we do some deep calls. then the older registers (do
>we have an LRU mechnism here?) get pushed by the sub call prologue which
>then uses those registers for its my vars.
I don't like push/pop - they imply a lot of stack limit checking word-by-word
when it is less overhead for compiler to analyse the needs of whole basic-block
check-for/make-space-on the stack _once_ then just address it.
>
>is the sub call/return stack also the data (scratch) stack? i think
>separate ones makes sense here. the data stack is just PMC pointers, the
>code call stack has register info, context, etc.
One stack is more natural for translation to C (which has just one).
One problem with FORTH was allocating two growable segments for its
two stacks - one always ended up 2nd class.
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
