Re: Framed Stack vs. Two Stack Architecture

Avatar wrote:


> I understand that the JVM architecture implements a framed-stack: one
> frame per activation record (method call) with an embedded operand
> stack. So essentially they have rolled the execution stack and operand
> stack into one. Right?


ACK.


> I also understand that there are architectures (although I have been
> unable to find a reference implementation for this) that maintain two
> separate stacks: a execution (control) stack for function calls, and a
> separate data stack for (bytecode) instruction evaluation.


I know such an organization from FORTH.


> The language we are implementing is dynamic in nature (dynamic typing
> and alllows for on-the-fly code evaluation) so we would not have the
> advantage that the JVM has in knowing the max stack depth (operand
> stack) at compile time. At any point code can be evaluated on-the-fly
> within a function. Which I am guessing would eliminate the
> stacked-frame approach? As the frames need to be allocated to a
> certain size (can't grow based upon the demands for operand stack
> space).
>
> Any thoughts on these two stack architectures would be greatly
> appreciated?


At the most abstract level I'd say: if you ever feel a need for
contiguous *and* independently extensible areas of memory, you'll have
to implement and use as many concurrent stacks, as are required during
the dynamic execution of your code.


From the viewpoint of an general memory manager, for an limited amount
of memory, IMO it doesn't make much sense to allocate resizeable
memory areas inside an stack. Consider:


- Lifetime of the resizeable areas, with respect to the shrinking of the
stack.


- Reuse of memory areas, freed after moving their previous contents into
different places.


- From where to take memory, for reallocation of memory areas?


- When moving the remainder of the stack, in order to free memory for
the extension of an embedded frame, how to adjust all the affected frame
pointers?




So I'd say that you should consider to implement stacks as separate and
indpendent memory objects. Then it's possible to extend every stack on
demand, by moving it around in physical memory, and with a need for
updating only the (base and/or top) pointers of that particular stack.
Afterwards you can consider to merge multiple stacks into one big
(operand) stack, and to possibly insert fixed-size areas into that
stack, as stack frames. Similar considerations may apply to another
execution stack, or to other stacks for dedicated *and* compatible
purposes. The remaining stacks then can be managed in the traditional
way, as moveable and resizeable memory areas.


Hint: consider the lifetime of all dynamically allocated memory areas -
a living frame within an stack prevents the stack from shrinking beyond
that position.


<snipped many, many lines, which lead me to the above quintessence ;->


DoDi

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