Two Questions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Two Questions

Chris Cunnington
1. Why is #dispatchOn:in: , which looks to be the heart of
Interpreter>>#interpret,  in a subclass InterpeterSimulation? That class
is likely only used if there is a simulation going on, yet the essential
#dispatchOn:in: is in the subclass, where I'd suppose it can't be reached.

2. What is the specialObjectsOop? It's a number. OK, what what is the
context of that number? It's not some memory address in RAM, because I
think we're abstracted above that. And the oopMap I'm looking at
MicroSqueak is an IdentitySet. Something is amiss here. This
specialObjectsOop is not fish (RAM memory) and it's not fowl (an object).

I'd suppose the point of the specialObjectsOop is as a starting point.
You load the SpecialObjectsArray into the ObjectMemory and I guess you
do that by saying "start here" with the specialObjectsOop. What is the
context of that number? Is there a bank of addresses in the object
memory or interpreter that simulate the memory addresses of the RAM?

Any help would be greatly appreciated,


Chris
_______________________________________________
VM-beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners
Reply | Threaded
Open this post in threaded view
|

Re: Two Questions

David T. Lewis
On Thu, May 12, 2011 at 10:47:52PM -0400, Chris Cunnington wrote:
> 1. Why is #dispatchOn:in: , which looks to be the heart of
> Interpreter>>#interpret,  in a subclass InterpeterSimulation? That class
> is likely only used if there is a simulation going on, yet the essential
> #dispatchOn:in: is in the subclass, where I'd suppose it can't be reached.

I'm assuming that you are using Squeak, that you have loaded the
trunk VMMaker (load update.7.dtl), and that you have done a
"VMMaker updateFromServer" to bring it fully up to date.

Try this:

- Open a browser on Interpreter>>interpret. This is the main interpreter
loop, which uses #dispatchOn:in: to dispatch the bytecodes. It is
a very short method, but it does a lot and it is not short at all
by the time it gets translated to C.

- In the browser, middle row, far right, click the "Source" button,
then select "translate inlined C". This displays the C code version
of the method, which will be compiled into the executable VM.

- You need one more hint to figure this out: Search the image for
methods with source containing 'dispatchOn:in:'. This will lead you
the methods that translate the Smalltalk (aka "slang") into C. In
the C code generation, certain selectors are treated specially,
including C language operators and critical methods such as
#dispatchOn:in: which needs to be translated into an efficient
case statement in C.

When you run the interpreter within Squeak, you run a subclass
of Interpreter that adds any missing methods. Class Interpreter
is translated to C, and #dispatchOn:in: is translated specially
as part of that process. You don't want a Smalltalk implemention
of the method #dispatchOn:in: to appear in class Interpreter,
because then the C code generator would attempt to translate
it (instead you want it to use the optimized case table generator).
But when you run the intepreter in Smalltalk, you want to evaluate
an actual Smalltalk implementation of #dispatchOn:in:, and for
this reason the method is added to InterpreterSimulator.

>
> 2. What is the specialObjectsOop? It's a number. OK, what what is the
> context of that number? It's not some memory address in RAM, because I
> think we're abstracted above that. And the oopMap I'm looking at
> MicroSqueak is an IdentitySet. Something is amiss here. This
> specialObjectsOop is not fish (RAM memory) and it's not fowl (an object).
>
> I'd suppose the point of the specialObjectsOop is as a starting point.
> You load the SpecialObjectsArray into the ObjectMemory and I guess you
> do that by saying "start here" with the specialObjectsOop. What is the
> context of that number? Is there a bank of addresses in the object
> memory or interpreter that simulate the memory addresses of the RAM?
>

The specialObjectsOop is the location of the SpecialObjectsArray in
the object memory. Think of it as an integer offset (the oop) into
a big array of 32-bit values (the object memory). And in a 64-bit
object memory, it is the location of a value in a big array of 64-bit
values. So the specialObjectsOop is an object pointer that refers
to the location of an object header, which in turn gives you the
in-memory representation of the actual object, which in this case
is the special object array.

The location of the special objects array is saved in the image header
when you save your image, and it is read by the VM when load load
an image. This allows the VM to know to the location of the special
object array when it loads the image from disk, and this in turn is
the entry point that allows the interpreter to find the other objects
that it needs to know about in the object memory.

Dave

_______________________________________________
VM-beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners