On 14 February 2013 01:04, Eliot Miranda <eliot.mira...@gmail.com> wrote: > > > > On Wed, Feb 13, 2013 at 1:32 PM, Stéphane Ducasse <stephane.duca...@inria.fr> > wrote: >> >> Hi eliot >> >>> I repost the mail to the mailing-list since I do not see it in the vm-dev >> >> >> did you post to vm-dev? >> >> >> yes but since I'm travelling may be the mail was lost or I could not see >> appearing because one of my rules pushed it somewhere. >> I changed machines and I have to get used to 10.8. My mail now decide to use >> the wrong account :( >> >>> >>> Hi >>> >>> I was reading the following method in the VM code and I have a couple of >>> questions: >>> >>> - I do not understand why lookupMethodInClass: may return a class. I was >>> thinking that it would return a method. >> >> >> It doesn't matter what it returns as it's return value is always ignored. >> >> >> Ok I will read again the code. reading Slang is still nicer than plain >> generated C :) >> >> It assigns to newMethod. I suspect it returns currentClass because a) the >> return type was always sqInt because Slang didn't support void functions, >> and b) currentClass is a value in hand so probably in a register and hence >> cheap to return. >> >> >> >> Ok >> I was looking for an example to show a real lookup for the students that are >> implementing ObjVlisp >> Now I will see if I show them this method. > > > So just run an image with the simulator and stop at any of commonSend, > internalFindNewMethod, lookupMethodInClass: and you'll see the call chain > form the relevant send bytecode. > > Here's an expression that loads and runs an image with the StackInterpreter: > > | vm | > StackInterpreter initializeWithOptions: (Dictionary newFromPairs: #()). > vm := StackInterpreterSimulator new. > vm openOn: '/Users/eliot/Squeak/Squeak4.4/trunk44.image'. > vm openAsMorph; run > > and if you break on entry to internalFindNewMethod you'll see this stack: > > StackInterpreterSimulatorLSB(Object)>>break > StackInterpreterSimulatorLSB(StackInterpreter)>>internalFindNewMethod > StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>internalFindNewMethod > StackInterpreterSimulatorLSB(StackInterpreter)>>commonSend > StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>commonSend > StackInterpreterSimulatorLSB(StackInterpreter)>>normalSend > StackInterpreterSimulatorLSB(StackInterpreter)>>secondExtendedSendBytecode > StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>dispatchOn:in: > StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>run > UndefinedObject>>DoIt > > If you find out what the selector is (e.g. self printOop: messageSelector) > you can then use the simulator;s own breakpoint facilities: > > | vm | > StackInterpreter initializeWithOptions: (Dictionary newFromPairs: #()). > vm := StackInterpreterSimulator new. > vm openOn: '/Users/eliot/Squeak/Squeak4.4/trunk44.image'. > vm setBreakSelector: #&. > vm openAsMorph; run > > and now it'll stop in sendBreak:point:receiver: and you'll get this stack: > > StackInterpreterSimulatorLSB(Object)>>halt: > StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>sendBreak:point:receiver: > StackInterpreterSimulatorLSB(StackInterpreter)>>commonSend > StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>commonSend > StackInterpreterSimulatorLSB(StackInterpreter)>>normalSend > StackInterpreterSimulatorLSB(StackInterpreter)>>secondExtendedSendBytecode > StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>dispatchOn:in: > StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>run > UndefinedObject>>DoIt >>> >>> - what is the invariant? >>> that currentclass always point to the currently looked up class and >>> newMethod is the found method? >> >> >> The input arguments are messageSelector, argumentCount and its argument, >> class. The VM suffers somewhat from being cluttered with global variables, >> which is I think a legacy of the blue-book specification (the Smalltalk code >> that was used to implement Interpreter in VMMaker) being derived from the >> Alto and Dorado implementations in microcode. It would be nicer if there >> were fewer variables, but e.g. supplying argumentCount as a parameter >> throughout all the message handling routines can be difficult, especially >> when things like perform: and MNU change the argumentCount during message >> send. >> >> >> I clearly see what you mean. >> >>> - why lookupMethodFor: selector InDictionary: dictionary is defined in >>> StackInterpreter but never used >>> only in CoInterpreter? >> >> >> Well, it belongs in StackInterpreter and could be used in the other lookup >> methods. I was probably considering rewriting the other lookup routines to >> use lookupMethodFor: InDictionary: but didn't get round to it. >> >> >> ok I see. >> >> While reading directly the see code I was wondering why you generate the >> ifdef for different bytecode set? >> Is it that you would have to call another object and that it would not have >> the same instance variables. >> Because I was thinking that such variation points could be handled by the >> different interpreter subclasses. > > > Bytecode dispatch is performance-critical in the context and stack > interpreters. The ifdef means that if one is not using multiple bytecode > sets dispatch is simpler and hence faster. > > Subclassing is very difficult because the simulators are not traits and so > subclass each interpreter class. hence adding a subclass to handle this > difference means adding another simulator, and they're big and tedious to > maintain. IMO the multiple bytecode set work just isn't worth that kind of > load. The VM would be nicer if more fully decomposed. I've done a fair > amount (moving the objectMemory into an instance variable, putting the Cogit > in its own class hierarchy, adding support for struct classes that define > data types like a stack page or an abstract instruction or machine-code > method in the JIT) but there's always more that one can do. >
yes.. the amount of code in one class cries for decomposition.. but it would require serious investment of manhours .. which i assume we will never have, because there's always more important things to do. -- Best regards, Igor Stasenko.
