Need a marker primitive

Hi,

I'd like to add a primitive pragma to InterpreterSimulator>>primitiveFail so the RSqueakVM can notice when the simulation is about to fail. What would be a good primitive number for that? Would 114 (exitToDebugger) work? If so, I would add it there.

Hi Tim,

    in what context do you want to notice something is about to fail?  Simulator, real VM under gdb or what?  And when?  Primitive failure in the Cog VM is the writing of a non-zero value to primFailCode.  That can be done with a conditional breakpoint.  I'm not sure what you mean.  Can you be more precise?

TIA

Eliot (phone)

On Apr 24, 2015, at 9:02 AM, timfelgentreff <[hidden email]> wrote:

In RSqueakVM we always run the simulation for BitBlt and Balloon (so when e.g. the copyBits primitive comes up, the VM just creates a frame running the copyBitsSimulated method). This generally works well, but when the simulation triggers a primitiveFail, it'll just be a Smalltalk-level halt, and we have to jump through hoops in RSqueakVM to catch that and run the fallback code. If instead we add a primitive into InterpreterSimulator>>primitiveFail, we can catch that and know that we should run the fallback code.

Hi Tim,

    why not create a subclass of InterpreterProxy to use as your interface and have it implement primitiveFail appropriately?  You can also create a subclass of BitBltSimulation to modify as required for your situation.  I don't see that a pragma solved anything here.

Eliot (phone)

On Apr 25, 2015, at 2:28 PM, timfelgentreff <[hidden email]> wrote:

Sure, we could do that. I wanted to have it in the VMMaker package (so that just loading the VMMaker package prepares the image for running with RSqueak), so I was looking for a minimal change. Our subclass would simply override primitiveFail to do:

primitiveFail
    <primitive: 114>
    ^ super primitiveFail

So I guess all I'm asking is, can we just put primitive 114 (or any number that's free for us to implement our custom logic in the VM in) directly into InterpreterSimulator without anybody ripping our head off? Are people debugging the simulation using gdb and the breakpoint there would annoy them?

 
On Sun, Apr 26, 2015 at 11:08:06PM -0700, timfelgentreff wrote:
Hi Tim,

Are you asking if you can add an implementation of InterpreterSimulator>>primitiveExitToDebugger
in the trunk (not oscog) VMMaker package? If so, then I would say yes, go
ahead and add it. Please give it a good method comment that explains how
you are using it for RSqueak.

Thanks,

Dave
 

Hi Tim,

your proposal is missing below:
Personally I don't get why you want a primitive.  I don't see how the RSqueak VM can use it to handle primitive failure.  I fear infinite regress :). Can you try again to mail the code?  I'm not trying to block you.  I'm just trying to understand, cuz until I do I can't respond meaningfully.

Eliot (phone)

On Apr 26, 2015, at 11:08 PM, timfelgentreff <[hidden email]> wrote:

Hi Eliot,

Sorry, I mixed up InterpreterSimulator and InterpreterProxy here. But let me explain what's happening and why I think a primitive would help us.

When the RSqueakVM encounters a named primitive, say 'primitiveCopyBits', and the VMMaker package is loaded in the image, instead of running any primitive behavior, it creates a frame to run 'simulateCopyBits' in place of the primitive behavior. From the point of view of the Smalltalk image that dispatched to 'BitBlt>>copyBits' (where the VM encountered the named primitive), instead of entering that method, the VM entered 'BitBlt>>simulateCopyBits'.

'simulateCopyBits' runs the simulation, but the simulation might fail, for example when it encounters a hibernated form as source or destination. In that case, the simulation will call 'InterpreterProxy>>primitiveFailFor:' or 'InterpreterProxy>>success:'. Both set the primFailCode, and then use a Notification to ask the user if the simulation should stop.

Now, the simulation simply failed because one of the Forms was hibernated - that's what the fallback code is for. But to run the fallback code we need the help of the VM - after all, 'BitBlt>>copyBits' is not even on the stack, and the Smalltalk code doesn't even know the VM replaced a primitive invocation with a message send to 'simulateCopyBits'. Now, if the VM could notice that the primitive fail code was set, it could simply unwind the stack (before the halt is run) and actually run the fallback code.
It is hard to notice that, though. The InterpreterProxy is just an object like any other, and the Notification that is used to inform the user isn't visible to the VM -- it is just ordinary Smalltalk code that happens to traverse the senders chain.

Now, if we add a <primitive: 114> to those two methods in InterpreterProxy, 'success:' and 'primitiveFailFor:', the RSqueakVM can use that primitive to notice that we are running the simulation for a primitive, that primitive is about to fail, so we better unwind and start running the fallback code.

Since I haven't heard back, can you take a look at these change I made in VMMaker-tfel.362 and tell me if these are ok? They should just affect the simulation, and have no effect on Cog.

And it seems I botched the merge. Vmmaker-tfel.363 should fix that. In any case, the diff should have been this:

  ----- Method: InterpreterProxy>>primitiveFailFor: (in category 'other') -----
  primitiveFailFor: reasonCode
+ "Set specific primitive failure. N.B. primitiveFailFor: PrimNoErr is expected to clear the primFailCode.
+ Primitive 255 is called to indicate that we are currently simulating a primitive that should fail and the VM should handle that case appropriately (if supported by the VM)."
+ <primitive: 255> 
+ ^ primFailCode := reasonCode!
- "Set specific primitive failure.
- N.B. primitiveFailFor: PrimNoErr is expected to clear the primFailCode."
- ^primFailCode := reasonCode!

Item was changed:
  ----- Method: InterpreterProxy>>success: (in category 'other') -----
  success: aBoolean
  self failed ifTrue: [^ self].
  aBoolean ifFalse: [
+ self primitiveFailFor: 1.
- primFailCode := 1.
  (self confirm:'A primitive is failing -- Stop simulation?') ifTrue:[self halt]]
  !

Since nobody complained, I merge the relevant change into VMMaker.oscog.

One thing I noticed is that InterpreterProxy>>success: is defined differently between the two branches. Is that intentional? Should we unify these?

 
On Wed, Apr 29, 2015 at 10:45:51PM -0700, timfelgentreff wrote:
>  
> Since nobody complained, I merge the relevant change into VMMaker.oscog.
>
> One thing I noticed is that InterpreterProxy>>success: is defined
> differently between the two branches. Is that intentional? Should we unify
> these?
>

Hi Tim,

I have been away and am just catching up, with WRT VMMaker-tfel.36[23],
it looks fine. There is no change to generated code (good) and the VMM
code generator job http://build.squeak.org/job/InterpreterVM is still
green (also good).

Checking diffs versus prior version VMMaker-dtl.359 there are some
new methods in BalloonEngineSimulation, BalloonEngineSimulation, and
BitBltSimulator. I think they are unreferenced in VMMaker, so is this
an accidental commit? If so no problem, I will just take them out in
the next update.

Thanks!

Dave
 

No, those methods should be there (and were introduced after a previous discussion in VMMaker-tfel.360). I've just checked the diff from dtl.359 to tfel.363 and all is as it should be.

For balloon the new methods are:
BalloonEngine >> simulateBalloonPrimitive: aString args: args
BalloonEngineSimulation class >> simulatePrimitive: aString receiver: rcvr args: args

There is a new method on InterpreterProxy that these need:
InterpreterProxy >> synthesizeStackFor: receiver with: args

There should be a bunch of methods added to the class side to BitBltSimulator, as well as changes to the methods halftoneAt:, initialiseModule, and initializeDitherTables

And finally BitBltSimulation>>loadColorMap was updated with a fix.

 
On Fri, May 01, 2015 at 02:19:05AM -0700, timfelgentreff wrote:
>  
> No, those methods should be there (and were introduced after a previous
> discussion in VMMaker-tfel.360). I've just checked the diff from dtl.359 to
> tfel.363 and all is as it should be.
>

Good, thank you.