[self-interest] Sends, calls, stacks, scopes
datique at alcatel.com.br
Mon Jul 5 18:11:18 UTC 1999
In my interpreter, I am trying to associate each instance of the
interpreter with one object, named the "evaluatee". As an oop, the
evaluatee can be:
- a data object, without any code inside:
-> the evaluation returns the evaluatee.
- a method object, with code inside:
-> the evaluation clones the evaluatee, creating the activation, binds
the arguments on the stack to the arg slots* on the activation and
finally gets the bytecodes and the literals from the activation and
follows the instructions.
In the case of the code object, the bytecodes tell the interpreter what
to do, namely:
- to push the evaluatee onto the stack;
- to push a literal, given by its index into the literals vector, onto
- to return an object;
- to load a delegatee, given by its index into the literals vector, into
the delegatee register;
- to load an extended index into the index register;
- to evaluate a send;
-> if the selector is a primitive*** (in particular check for _Restart,
which has to be supported by the interpreter directly, by resetting the
bytecode counter) get its pointer (with getPrimDesc and PrimDesc::fn())
and execute it
-> if the selector isn't a primitive:
--> lookup the slot matching the selector, checking that one and only
one slot is found
--> if the selector is an assignment, perform the assignment with
oopClass::find_assignee_slot(stringOop) and oopClass::define_prim(oop)
--> if the selector isn't an assignment:
---> create a new instance of the interpreter passing the object
referred to by the matching slot and the stack (possibly with other
arguments already pushed)
---> evaluate the object and push the result on the stack
- to evaluate an implicit (self) send;
-> do the same as the send, only that the receiver is the activation.
- to evaluate a super (re)send;
-> do the same as the send, only that the receiver is the activation**
but also the lookup of the selector will start not at the activation
proper, but at either
1) a parent slot of the receiver whose name matches the delegatee (in
case the delegatee is non-NULL) or
2) any of the parent slots of activation (undirected resend).
I tried to describe the algorithm I am developing with details, but I
may have missed something. Would anyone like to make comments on the
I was thinking of the stack I am supposed to use. I would like best to
use the new Standard C++ Library's stack container, but I am afraid it
won't work well with the resource and heap allocation schemes, as well
as with the garbage collector. Would anyone say anything about this?
I appreciate comments, suggestions, doubts, any feedback.
* I still don't know how to assign the arguments to the argument slots
on the activation, but I understand that they should be on the stack,
ready for popping.
** It is not very clear yet to me if the receiver can be the parent
whose slots match the selector.
*** I still don't know how to call the primitives from the interpreter.
eGroups.com home: http://www.egroups.com/group/self-interest
http://www.egroups.com - Simplifying group communications
More information about the Self-interest