|How to build your own stack frames? (interpreter questions) email@example.com (1995-08-20)|
|Re: How to build your own stack frames? (interpreter questions) firstname.lastname@example.org (1995-08-21)|
|Re: How to build your own stack frames? (interpreter questions) Lassi.Tuura@hut.fi (1995-08-21)|
|Re: How to build your own stack frames? (interpreter questions) email@example.com (1995-08-22)|
|Re: How to build your own stack frames? (interpreter questions) firstname.lastname@example.org (1995-08-22)|
|From:||email@example.com (Antoun Kanawati)|
|Date:||Mon, 21 Aug 1995 03:26:17 GMT|
firstname.lastname@example.org (Ralph Seguin) wrote:
> We are looking at creating some interpreter code, and we would
> very much like to have the interpreter call into various methods and
> functions that we have available.
> The problem is that I have no idea how to build a proper stack frame
> on the fly (ie, interpreted code). In compiled code, this is no
> problem obviously.
For "cover methods", you can use a code generator, and create highly
portable code. Of course, you may have to write the code generator.
This is limited to a static set of external procedures.
Or, if you want to get your hands dirty, you'll generate metadata, either
statically, or by dynamically parsing procedure interfaces. Then, you'll
write an assembler program which builds the stack frame and jumps or
calls to the right place. The techniques vary per compiler and per
target architecture and per compilation options. This approach is
notoriously difficult, and often bug-ridden. If the metadata is
preloaded into the program and cannot be added later, the previous
method is safer, and cleaner.
Antoun (Tony) Kanawati
Return to the
Search the comp.compilers archives again.