[self-interest] Self bytecodes

Douglas Atique datique at alcatel.com.br
Mon May 31 14:35:23 UTC 1999

Hello, folks!
Let me bother once more with those implementation issues...
I am implementing a simple bytecode interpreter for the Self 4.0 VM,
which I suppose will make it portable among platforms other than the
I have been studying the Self bytecodes, mainly in the fast_compiler VM
code and a paper dated 1989 (from Self 1.0 or 2.0).
There are eight different codes:
SELF_CODE: push the object whose code is being interpreted on the stack
LITERAL_CODE: push a literal (the index of it on the literals vector of
the code is given) on the stack
INDEX_CODE: load the index extension register with the 6th to 10th bits
of the extended index. This will be used in the next code to indicate
that the index of the next code is greater than 31
SEND_CODE: send a message to an object. The receiver, the selector and
arguments are given somewhere.
IMPLICIT_SEND_CODE: send a message, just like the previous, only that
the receiver in this case is self.
RESEND_CODE: send a message to a parent (directed resend) or to all
parents (undirected resend). This is equivalent to Java's super.---()
method invocations or to C++'s overridden non-virtual method
invocations. Smalltalk has something similar, I have read.
DELEGATEE_CODE: load the delegatee register with the parent to whom the
next resend should be directed.

It all seems fine, but I donĀ“t understand something seemingly
straightforward: knowing that in a send the receiver and arguments are
popped off stack and the result is pushed onto stack, how is the number
of arguments of a send determined, so that my interpreter could know how
many pops it should make? It seems that in the fast_compiler, when the
machine code for a send is generated, the information of number of
arguments is kept somewhere. Where?

If someone can explain that to me, I appreciate.

Cheers to all,

(P.S.: This is the second version of an e-mail I was writing to the
list. The first was lost when Netscape exited with a GPF. This is why
you might notice that I have resumed the explanations about the


eGroups.com home: http://www.egroups.com/group/self-interest
http://www.egroups.com - Simplifying group communications

More information about the Self-interest mailing list