[Vm-dev] handleCallOrJumpSimulationTrap: curiousity

[Clément Bera]

On Fri, May 20, 2016 at 7:29 PM, Ben Coman <btc at openinworld.com> wrote:

>
> On Fri, May 20, 2016 at 8:44 PM, Clément Bera <bera.clement at gmail.com>
> wrote:
> >
> > Hi Ben,
> >
> > The primitives present here are the primitives which create a new stack
> frame or switch to another one.
> >
> > In your new primitives:
> > - do you create a new stack frame ? For example, primitiveClosureValue
> creates a new stack frame for the block evaluation. I don't think that is
> the case.
>
> Correct.  It doesn't create a stack frame.
>
> > - do you potentially switch to another process ?
>
> It does when trying to acquire a lock held by someone else, the
> process sleeps and does wakeHighestPriority to which it transferTo:
>
> > For example, primitiveResume may switch execution to the resumed process
> if it has a higher priority, so the active stack frame may have changed. It
> could be that you have primitives like that.
> >
> > I'd recommend you not to change that method right now. Instead, you
> implement your code, then run it in the VM simulator to ensure everything
> works fine. If the simulator halts in handleCallOrJumpSimulationTrap, then
> add your primitive here if relevant, else just ignore that method.
> Changing this method ahead of time doesn't feel like a good idea.
>
> Thanks for the tip.  I hadn't come across that method yet.  I had
> already decided to try and get the simulator working for the first
> time this weekend.  Its been interesting poking through the VM with
> gdb, but its not "exactly" fun.
>

Normally if you build a cog development image:
$ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/image
$ cd ./image
$ ./buildsqueaktrunkvmmakerimage.sh

You have multiple scripts available with comments to run the simulator that
work out of the box. It should take a couple minutes to get it working.
Then the easiest is to simulate a REPL image to easily debug what you want.


> cheers -ben
>
>
> > Have fun :-)
> >
> > On Fri, May 20, 2016 at 1:46 PM, Ben Coman <btc at openinworld.com> wrote:
> >>
> >>
> >> Minor curiosity & clueless speculation...  in passing I came across
> >> the following in #handleCallOrJumpSimulationTrap and given the
> >> similarity of critical section and  ownedlock primitives to alter the
> >> running process like primitiveWait, I wondered if they should also be
> >> in this list ...
> >>
> >>
> >> "Verify the stack layout assumption compileInterpreterPrimitive:
> >> makes, provided we've not called something that has built a frame,
> >> such as closure value or evaluate method, **or switched frames**,
> >> such as primitiveSignal, primitiveWait, primitiveResume,
> >> primitiveSuspend et al."
> >>
> >> ifTrue: [(#( primitiveClosureValue primitiveClosureValueWithArgs
> >> primitiveClosureValueNoContextSwitch
> >> primitiveFullClosureValue primitiveFullClosureValueWithArgs
> >> primitiveFullClosureValueNoContextSwitch
> >> primitiveSignal primitiveWait primitiveResume primitiveSuspend
> primitiveYield
> >> primitiveExecuteMethodArgsArray primitiveExecuteMethod
> >> primitivePerform primitivePerformWithArgs primitivePerformInSuperclass
> >> primitiveTerminateTo primitiveStoreStackp primitiveDoPrimitiveWithArgs)
> >>
> >> cheers -ben
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160520/1f14fab1/attachment-0001.htm