VM-beginners January 2014

vm-beginners@lists.squeakfoundation.org

7 participants
12 discussions

One can pass events from EventSensor to the StackInterpreterSimulator
by gettimothy 30 Jan '14

30 Jan '14

Hi Eliot, Bob and Henry. Changeset and pic attached. (If the changeset has problems, let me know, I copied from my live CS to a clean copy to share that omits my fiddling around changes. I might have missed something) I would appreciate your advice on how to proceed from here. The approach is modeled after what I saw in HostWindowProxy. I have other things on my checklist to try, but this seemed the easiest approach, so I ran with it. My first goal was to just get the darned events into the simulator, see something on the simulated transcript and a menu to show up. Modifications were as follows (changeset attached, btw) EventSensor class side set class side accessor for instance var forwardVMSimulationEvents instance side add instance var forwardVMSimultioEvents modify processEvent:evt to forward raw events if flag is set. StackInterpreterSimulator class side I added infrastructure to make it a Singleton Created a class side accesor to invoke the instance side method instance side. Added an eventQueue (SharedQueue) instance variable queueForwardedEvent lazy initialization takes event from EventSensor and dumps it on the eventQueue ioGetNextEvent checks eventQueue and copies data from the forward event to the CArrayAccessor There is commented out code I used to verify that 1. the argument evtBuf is a bunch of zeroes coming in 2. evtBuf matched the forwarded event after copy Workspace code to launch the simulation: | vm | Transcript clear. EventSensor forwardVMSimulationEvents: true. vm := StackInterpreterSimulator newWithOptions: #(#STACKVM). vm openOn: '/home/wm/usr/src/smalltalk/buildCogDevelopmentImageCog.app/Contents/Resources/targets/Squeak4.5.image'. vm openAsMorph; run "EventSensor forwardVMSimulationEvents: false." Observations: The events get there and the WorldMenu pops up. woot. (lower case "woot", no exclamation point. not to be confused with WOOT!!!!) The tildes "~" in the simulation Transcript (in the attached pic) are generated at StackInterpreterSimulator>> ioGetNextEvent Event processing is dog slow. Be prepared to wait 5 minutes for the menu to pop up. Tightly coupled. I don't like the modification to EventSensor. I don't like having to implement a Singleton--but it was saner than Smalltalk at: #StackInterpreterSimulatorLSB allInstances do:[...] I am unfamiliar with Smalltalk Semaphores, had I known how to do the Smalltalk equivalent of event listener I would have gone that route. Consumer/Producer Semaphore examples from various books I have read are all within the same process, so I cut my losses and went with the current approach. EventSensor>>processEvent:evt does have the events in raw form, no need to translate before forwarding to the StackInterpreter. In principle, we know we CAN get the dang events into the StackIntepreter. How do I make this responsive and useful? Thank you for your time p.s. this is fun. cheers. tty.

1 0

Virtual machine applications
by Azka Niazi 30 Jan '14

30 Jan '14

I am conduction a brief research on the advantages of virtual machine applications over the usual/conventional desktop applications. Roughly, I need to understand why building an interactive graphical environment like Scratch will be better on Squeak versus building it through other programming languages like Java. Regards,Azka

3 2

One cannot pass Morphic event's along the Morhp chain from the simulation host World to the running simulation on the target World.
by gettimothy 22 Jan '14

22 Jan '14

I have some questions on how to proceed at the bottom of this post. In the host simulation environment, one cannot interact with the running simulation using the standard Morphic "event chain". One cannot do so because from the host environment, there is no World in the simulation; there is only a painted picture of a World. The key to seeing this is to grok what a running simulation actually is. StackInterpreterSimulator >> run "..simulation setup code.." [true] whileTrue: [self assertValidExecutionPointers. atEachStepBlock value. "N.B. may be nil" self dispatchOn: currentBytecode in: BytecodeTable. self incrementByteCount]. "..we never get here..." There is no 'hook' for me to chain the Morphic event's down into, there are only bytecodes being fetched and executed . (which is totally cool and awesome, btw). Those bytecodes paint a pretty picture on an ImageMorph placed on a Frame placed within a SystemWindow as seen here in StackInterpreterSimulater >> openAsMorph "...." window addMorph: (displayView := ImageMorph new image: displayForm) frame: (0@0 corner: 1(a)0.8). "...." That image is not a PasteUpMorph named TheWorld that can respond to events--it is just a pretty picture. That ladies and gentleman is the point where us fat and coddled coder Hobbit's have to enter the dragon's cave, leaving the comfortable environment of the Squeak API for whatever strange and dangerous world lies below; Me? I decided to post here instead before venturing in (: So, having learned this the hard way, there are a couple of strategies I could take--RFB, or maybe Nebraska-- to get events over to the target image but before doing that I have to ask is it really necessary? My goal is to port the StackInterpeter to native 64 (and after that 64x64). Presumably Eliot managed to do the original work without the use of direct interaction with morphic on the running world, so shouldn't my task now be to emulate whatever techiques Eliot uses? If so, that raises the final point. What exactly are those techniques? Specifically, given a running simulation, how does one produce a new VM? Do we boot up the target image on which we have developed and run VMMaker the standard way? Finally, direct interaction with the runnig simulation world is desirable, I will be happy to implement it. Just please inform me of what strategy you would prefer and I will try to get it done. Thank you for your time.

1 0

It is definitely best I start with StackInterpreter!
by gettimothy 17 Jan '14

17 Jan '14

I just diagrammed out the VMClass hierarchy to get a feel for things. That CogClass branch is definitely an ambitious undertaking!

2 1

VMSimulations are interactive--right?
by gettimothy 14 Jan '14

14 Jan '14

I am able to get menu-click functionality on the command window at the bottom right of the simulation, and I get output from that just fine. PrintFrame, clone, etc all work. What I am not getting is any GUI response from the World--no world menu, no nothing. Before I debug this I just want to verify that that is NOT normal behavior and that the simulation window should behave just like a normal session. fwiw, the simulator does not find the SocketPlugin on launch which may be the problem.

2 1

An interesting tidbit for the record
by gettimothy 14 Jan '14

14 Jan '14

in CogBytecodeDescriptor a portion of the class comment reads: " The order of my instance variables is chosen for compact struct packing." In user-space I have never even considered the order of my instance variables. From that comment, it seems it can matter. Something to file away in the back of the brain.... tty.

2 1

VMBasicConstants Heuristics Question.
by gettimothy 13 Jan '14

13 Jan '14

Two questions if you have time. Looking at the VMBasicsConstants, some observations. We have UPPERCASE and CamelCase values. We have what appear to be Directives: GCModeFull, DoAssertionChecks, etc. Defines: BaseHeaderSize, ByteXMask, etc. Question 1. are Directives and Defines a correct categorization? and are there categorizations I am missing? (I am sure I could intuit these with time, but knowing this ahead of time would be a time-saver) Question 2. I would like to verify the heuristics of COGMTVM COGVM STACKVM When I load these into the script to boot the simulator, like this: | vm | Transcript clear. vm := StackInterpreterSimulator newWithOptions: #(#COGVM true)." vm openOn: '/home/wm/usr/src/smalltalk/buildCogDevelopmentImageCog.app/Contents/Resources/Squeak4.4.image'. vm openAsMorph; run I am assuming that I am informing the StackInterpreterSimulator that it is executing on a COGVM image (which I am running) and that if I was running multi-threading enabled cog, I would feed it the #COGMTVM. I am NOT telling the Interpreter that its target is an image that has been 'fingerprinted' by being run with those VM's in the past. (I have in mind the early releases of Cog where when you ran an old VM on an image, then switched to Cog it warned you that it was a one-way-street). thanks for your time. tty. BaseHeaderSize Byte0Mask Byte0Shift Byte1Mask Byte1Shift Byte1ShiftNegated Byte2Mask Byte2Shift Byte3Mask Byte3Shift Byte3ShiftNegated Byte4Mask Byte4Shift Byte4ShiftNegated Byte5Mask Byte5Shift Byte5ShiftNegated Byte6Mask Byte6Shift Byte7Mask Byte7Shift Byte7ShiftNegated Bytes3to0Mask Bytes7to4Mask BytesPerOop BytesPerWord COGMTVM COGVM DisownVMLockOutFullGC DoAssertionChecks DoExpensiveAssertionChecks GCModeBecome GCModeFull GCModeIncr GCModeScavenge IMMUTABILITY MULTIPLEBYTECODESETS NewspeakVM PrimErrBadArgument PrimErrBadIndex PrimErrBadMethod PrimErrBadNumArgs PrimErrBadReceiver PrimErrGenericFailure PrimErrInappropriate PrimErrLimitExceeded PrimErrNamedInternal PrimErrNoCMemory PrimErrNoMemory PrimErrNoModification PrimErrNotFound PrimErrObjectIsPinned PrimErrObjectMayMove PrimErrUnsupported PrimNoErr STACKVM ShiftForWord VMBIGENDIAN

1 0

Tracing temporary variables in a BlockContext
by gettimothy 10 Jan '14

10 Jan '14

The BlueBook page 582 shows the layout of a BlockContext. Note that the MethodContext has an area labeled 'other temporaries' and the BlockContext does not. I have modified Eliot's "push n first' factorial copy example as such: | factorial n | thisContext inspect. factorial := [:factorialArgument | n := factorialArgument. n = 1 ifTrue:[ Transcript show: (n asString), '->', thisContext identityHash asString;cr. thisContext inspect. 1] ifFalse:[ Transcript show: (n asString), '->', thisContext identityHash asString;cr. thisContext inspect. n * (factorial copy value: n-1)]]. (3 to: 5) collect: factorial copy. What I am trying to verify (and I think it is true, but I want to run it by you) is that in the BlockContext section of the CompiledMethod, there are several pushTemps. 70 <C8> send: blockCopy: 71 <A4 36> jumpTo: 127 73 <6A> popIntoTemp: 2 74 <12> pushTemp: 2 75 <69> popIntoTemp: 1 76 <11> pushTemp: 1 77 <76> pushConstant: 1 78 <B6> send: = 79 <AC 14> jumpFalse: 101 81 <41> pushLit: Transcript 82 <88> dup 83 <11> pushTemp: 1 84 <D4> send: asString 85 <25> pushConstant: '->' 86 <E3> send: , 87 <89> pushThisContext: 88 <D6> send: identityHash 89 <D4> send: asString 90 <E3> send: , 91 <E2> send: show: 92 <87> pop 93 <D7> send: cr 94 <87> pop 95 <89> pushThisContext: 96 <D0> send: inspect 97 <87> pop 98 <76> pushConstant: 1 99 <A4 19> jumpTo: 126 101 <41> pushLit: Transcript 102 <88> dup 103 <11> pushTemp: 1 104 <D4> send: asString 105 <25> pushConstant: '->' 106 <E3> send: , 107 <89> pushThisContext: 108 <D6> send: identityHash 109 <D4> send: asString 110 <E3> send: , 111 <E2> send: show: 112 <87> pop 113 <D7> send: cr 114 <87> pop 115 <89> pushThisContext: 116 <D0> send: inspect 117 <87> pop 118 <11> pushTemp: 1 119 <10> pushTemp: 0 120 <D8> send: copy 121 <11> pushTemp: 1 122 <76> pushConstant: 1 123 <B1> send: - 124 <CA> send: value: 125 <B8> send: * 126 <7D> blockReturn My assumption is, that as the BlockContexts switch in and out, these pushTemps are referencing the 'other temporaries' on the MethodContext, even though we are operating within a BlockContext. Yes or No appreciated. thx for your time. tty

1 0

Please confirm/deny that MethodContext sender is nilled by the Interpreter.
by gettimothy 10 Jan '14

10 Jan '14

I while ago, while studying Eliot's factorial copy example I made the mistake of assuming that since the sender of the MethodContext was the UndefinedObject (which is the Nil object) that that was why the sender was nil. Eliot corrected me, writing: Assuming you're not joking, that's not what it means at all. The sender points to the sender context *until* it is returned from. We're inspecting a block, which got created in the Doit context for the expression [:n| ....]. And that DoIt context is the home context of the [:n|...] block. The DoIt context returned its result (the [:n|...] block) to whatever the sender context was. But when the DoIt context returned that result the DoIt context's sender was nilled, to indicate that it had been returned from. So by the time the [:n|...] block was inspected its home context's sender was nil. I spent some time trying to figure out exactly where that happens and I believe I have followed it to "system space" where I would like to leave things for now. If I am in fact correct. Following the code of Eliot's factorial copy example, The DoIt travels through user space, to the Compiler's Compiler >> evaluate: textOrStream in: aContext to: receiver notifying: aRequestor ifFail: failBlock logged: logFlag and ends up at <primitive:188> in Object >>withArgs: argArray executeMethod: compiledMethod {A whole bunch of stuff happens in System Space that I am do not know how to trace yet--but eventually, the return must happen....so..} In the BlueBook on page 608, There is a section on Return Bytecodes where bytecode 123 does set the sender nil. returnBytecode currentBytecode = 120 ifTrue: [tself returnValue: receiver to: self sender]. currentBytecode = 121 ifTrue: [tself returnValue: TruePointer to: self sender]. currentBytecode = 122 ifTrue: [tself returnVatue: FalsePointer to: self sender]. currentBytecode = 123 ifTrue: [tself returnValue: NilPointer to: self sender]. Which exists on Squeak's Interpreter and is mapped to instance method Interpreter >> returnNil. and finally, Interpreter >> commonReturn that seems the most possible path to me. Conversely, any possibility of the sender being nilled in User Space would have to call ContextPart>>privSender: aContext Browsing the senders of that method paired with no apparent semaphores in the Compiler method, leads me to conclude it happens in system space. Does that sound like its in the ballpark? Details are not neccessary as my goal was to just account for every variable we see in a Context. thx tty

2 1

Re: [Vm-dev] Simulating the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives
by Igor Stasenko 07 Jan '14

07 Jan '14

On 6 January 2014 18:30, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > I'm just revising plugin treatment in Spur and came across this old > snippet of mysterious code: > > InterpreterSimulator>>loadNewPlugin: pluginString > | plugin simClass | > transcript cr; show:'Looking for module ', pluginString. > (#('FloatArrayPlugin' 'Matrix2x3Plugin') > includes: pluginString) ifTrue: > [transcript show: ' ... defeated'. ^ nil]. > > rofl, my applauds to anyone who wrote this code :) Sadly (or happily), except from this little comment there not much i can offer right now, and have to shut up and vanish in a puff of smoke :) > In the past I got as far as rewriting it to read... > > InterpreterSimulator>>loadNewPlugin: pluginString > | plugin plugins simulatorClasses | > transcript cr; show: 'Looking for module ', pluginString. > "but *why*??" > (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue: > [transcript show: ' ... defeated'. ^nil]. > plugins := InterpreterPlugin allSubclasses select: [:psc| psc moduleName > asString = pluginString asString]. > > In revising the code for Spur I removed the defeat code and found out > more. It's essentially because the BalloonPlugin has difficulty simulating > accesses of 32-bit floats. If you simply defeat the code and let things > run soon you get failures in FloatArrayPlugin & Matrix2x3Plugin primitives. > These can be fixed by implementing the following in the FloatArrayPlugin & > Matrix2x3Plugin: > > cCoerce: value to: cType > ^cType = 'float' > ifTrue: [value asIEEE32BitWord] > ifFalse: [value] > > But soon you hit more difficult failures in the BalloonEnginePlugin, e.g. > in > > BalloonEngineBase>>transformPointX: xValue y: yValue into: dstPoint > "Transform srcPoint into dstPoint by using the currently loaded matrix" > "Note: This should be rewritten so that inlining works (e.g., removing > the declarations and adding argument coercions at the appropriate > points)" > | x y transform | > <inline: true> > <var: #dstPoint type:'int *'> > <var: #xValue type: 'double '> > <var: #yValue type: 'double '> > <var: #transform type:'float *'> > transform := self edgeTransform. > x := ((((transform at: 0) * xValue) + > ((transform at: 1) * yValue) + > (transform at: 2)) * self aaLevelGet asFloat) asInteger. > y := ((((transform at: 3) * xValue) + > ((transform at: 4) * yValue) + > (transform at: 5)) * self aaLevelGet asFloat) asInteger. > dstPoint at: 0 put: x. > dstPoint at: 1 put: y. > > where x and y end up being the integer representation of 64-bit floats > while dstPoint accepts the integer representation of 32-bit floats. At > least I think that's what's going on. > > In any case I need to focus on Spur and can't spare the time to fix this. > But I find it unsatisfactory. It means the VM simulation isn't accurate. > In the simulation the primitives fail and Smalltalk code is run. In the > real VM the primitives work. And that's deeply unsatisfying. > > So if there's anyone itching for a VM challenge try and make > the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives > simulate correctly, removing the defeat code above. That would be a great > new year's gift. > -- > best, > Eliot > > -- Best regards, Igor Stasenko.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

VM-beginners January 2014