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 |
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 |
Free forum by Nabble | Edit this page |