Re: The C Stack in interpreters - why?

[ Reordered for comprehensibility. Please don't top-post. ]


Peter Flass <Peter_Flass@Yahoo.com> wrote:
>clearm@comcast.net wrote:
>
>> I am trying to understand why the C stack is used in interpreters
>> rather than an explicity built stack on the heap? Up until now I
>> presumed that the explicit stack was how everyone did it, then I
>> learned that, apparently the way a lot of bytecode interpreters work
>> is to recursively call themselves whenever a
>> procedure/routine/method/whaterver is called. ...
>
>> Can someone tell me why the C stack is so often used instead of
>> explicit? ...
>
>If I'm understanding you correctly, it isn't the *C* stack, it's the
>hardware stack, and is set up for efficiencies a programmed-stack
>isnt't: PUSH and POP instructions, addressing via offsets from
>ESP/EBP, etc. I'm obviously thinking of x86, but other architectures
>offer similar instructions and addressing modes. Unless you have a
>good reason, why fight the hardware?


No, that is wrong. Firstly, there is no need to have a hardware stack
in the first place and, secondly, it isn't rare for the C stack not to
use the hardware facilities. The implementation of the C stack is an
orthogonal question to the one being asked.


My guess is that the main reasons are wanting to be able to use
declared variables rather than create a structure at each level
and to be able to use C's stack unwinding facilities (i.e. setjmp
and longjmp).


But I don't think that there is anything more than minor convenience
involved, and there have been plenty of good interpreters that worked
by maintaining their own stack. Any of those written in Fortran 77
and earlier (no recursion) necessarily had to.




Regards,
Nick Maclaren.
[Are there really systems with a hardware stack that C doesn't use?
I've never seen one. -John]

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