|Framed Stack vs. Two Stack Architecture email@example.com (Avatar) (2006-04-21)|
|Re: Framed Stack vs. Two Stack Architecture firstname.lastname@example.org (2006-04-22)|
|Re: Framed Stack vs. Two Stack Architecture email@example.com (Dmitry A. Kazakov) (2006-04-22)|
|Re: Framed Stack vs. Two Stack Architecture DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-04-23)|
|Re: Framed Stack vs. Two Stack Architecture firstname.lastname@example.org (George Neuner) (2006-04-23)|
|Re: Framed Stack vs. Two Stack Architecture email@example.com (2006-04-23)|
|Re: Framed Stack vs. Two Stack Architecture firstname.lastname@example.org (Tony Finch) (2006-04-23)|
|[5 later articles]|
|Date:||21 Apr 2006 23:49:01 -0400|
|Keywords:||interpreter, VM, question|
|Posted-Date:||21 Apr 2006 23:49:01 EDT|
We are implementing a stack-based VM for a small interpretive
language. I am currently investigating stack architectures and would
like to better understand the advantages / dis-advantages of a
framed-stack vs. two stack approach.
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?
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.
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
Any thoughts on these two stack architectures would be greatly
Return to the
Search the comp.compilers archives again.