|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)|
|How to build your own stack frames? email@example.com (1995-08-24)|
|From:||firstname.lastname@example.org (Ralph Seguin)|
|Summary:||How do you build your own call frames in an interpreted fashion?|
|Keywords:||interpreter, question, C++|
|Organization:||University of Michigan Engineering, Ann Arbor|
|Date:||Sun, 20 Aug 1995 05:06:57 GMT|
Hi. There was no comp.interpreters ;) This may be a stupid set of
questions, but here goes anyhow.
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
-How do I create a proper stack frame? Ie, how do I push 'this',
an argument list and a return address on to the stack? Portably??
I realize that this is probably a very strong portability issue
as well. For the time being, we want to solve this on SGI
machines, IRIX 5.3, SGI C++ 4.0
-What papers, code or other references that I should be looking at?
-how do you create a varargs list for function/method calls?
I know how to process VARARGS within functions/methods, but not how
to create them.
Really, I would rather NOT use varargs to solve this problem.
-How do I put "this" onto the callframe? My suspicion is that "this"
is simply the first argument to any [non-static] method.
-How do you get a method pointer for non-static class member
methods? There must be a way of doing this.
I realize that I could create a class called CallFrame, which will
bundle up arguments, and provide access methods, but I think that
a true call is more elegant (avoids having to have a cover method
which unbundles the arguments and then calls the real method).
Ie, in a cover call situation, you would have something like:
MyClass::MyMethod(int a, double b, int c)
int a = cf.GetInt();
double b = cf.GetDouble();
int c = cf.GetInt();
MyClass *mcPtr = (MyClass *)cf.GetUserData(0);
int rc = mcPtr->MyMethod(a, b, c);
This seems a bit cumbersome to me. I would prefer that the interpreter
be totally stupid (ie, not have to know anything about the methods/funtions
being called). In other words, the methods are not parts of the
[In most cases, you need an assembler stub to make the stack frame for you.
I've seen kludges with a big pile of indirect calls based on the number of
arguments, but that's not reliable if args can be of different sizes. -John]
Return to the
Search the comp.compilers archives again.