[self-interest] Back to bytecodes

[Douglas Atique]

Hello, folks.
Remember my message about the bytecode interpreter for Self? It goes on,
this time I think I have refined the algorithm, which I would like to
discuss with you again.
My strategy is to replace the processor-dependent code to be able to run
the VM on Solaris x86, and in a later phase, to remove the
Solaris-dependent glue to be able to run the VM on other systems. Well,
let's see the first part.
I don't exactly know what happens in assembly inside the VM, but I have
the rough idea of the read-eval-print loop:
- user types expression on prompt
- parser generates a Self object (call it OBJ) from the text
- compiler generates a native method from the object OBJ above
- CallSelf executes the nmethod and returns an oop
- prompt waits for another expression.
My plan is to switch off the compiler and underlying support code so
that instead of compiling OBJ we feed it to an interpreter that will,
well, evaluate it.
>From the principles of the Self language, we know that an object can
have code or not. If the object has code, evaluating that object means
executing the code and returning whatever the code returns. If the
object doesn't have code, evaluating it returns itself.
So, to determine whether an object has code, I intend to use
oopClass::is_method_like(). That means my interpreter takes as argument
an oop. But if the object has code, it can also have argument slots,
which are used by the code to access its arguments. How does the VM make
the binding among the arguments that are passed from the message sent*
and the argument slots in the method object that matches the selector?
This is a question that I couldn't yet answer but is essential for my
interpreter to come true. I have read in the Self 4.0 Programmer's
Reference (§2.1.6) that the method is cloned to produce a method
activation, which I understand as isolating the definition of the method
from the execution scope of it (I'm not sure I was clear enough, but I
can't right now express it better). In this method activation, there is
at least one argument slot(:self), which is initialized to the receiver
of the message. So are any other argument slots that the method may
contain. Well, I'm still investigating.
Another issue that concerns me is the fact that inside a method there
may be a primitive call. How should that be handled? How can one perform
primitive lookup? Is there some special VM object that holds all
primitives, and can execute (or return a pointer to) a primitive upon
request?
Well, folks, this could be called a position paper, if it weren't so
informal. :-)
Comments are welcome.
Regards to all,
Douglas
______
*or expression typed by the user, which is nothing more than a message
sent by a special "object", at least IMHO as seen by the system the doIt
slot of the lobby is only a proxy for the user to act as an object.
Suppose the user were an object and had a slot with a method that did
exactly what (s)he has typed on the prompt. Suppose that the user could
send messages to other objects just by evaluating one of its slots. This
is a strange view, but it can make sense if 1) I elaborate a little more
on it, 2) one spends a lot of time simulating the VM code


------------------------------------------------------------------------

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