[Vm-dev] Update on Morphic Events to StackInterpreterSimulator

Eliot Miranda eliot.miranda at gmail.com
Wed Feb 5 00:15:54 UTC 2014


Hi Tty,


On Tue, Feb 4, 2014 at 2:42 PM, gettimothy <gettimothy at zoho.com> wrote:

>
> See attached screen shot.
>

Looking good!

Hi All,
>
> Quick progress report.
>
> 1. I created a mockup of Bert's SqueakJS. Its stubbed out, but the run and
> help button work. If anybody can tell me where to pull the current context
> from the vm sim, I can replace the bottom middle panel with that.
> It currently uses:
>
> SimpleHierarchicalListMorph on: [ Array with: (ObjectExplorerWrapper with:
> (self model vm) name: 'root' model: (self model vm) parent: nil) ] where
> 'vm' is the running StackInterpreterSimulator.
>
>
>
> So something like:
>
> SimpleHierarchicalListMorph on: [ Array with: (ObjectExplorerWrapper with:
> (self model vm getTheActiveContext) name: 'root' model: (self model vm
> somethingOrOtherToHangTheActiveContextUnder) parent: nil) ]
>
>
> would be appreciated if its easy.
>

There is no active context in the StackInterpreter except at snapshot load
or save.  There is an active stack frame almost always, but sometimes it is
defined by the localFP,localSP inst vars of StackInterpreter (when
executing bytecodes) and sometimes by the framePointer,stackPointer inst
vars of InterpreterPrimitives (when executing non-inlined primitives).

In the Cog VM it's even more complicated.  Sometimes the VM is in the
interpreter (frame is localFP,localSP or framePointer,stackPointer as
above), sometimes in machine-code, when the current frame is either the
machine's frame pointer,stack pointer pair (e.g. %ebp,%esp) or
framePointer,stackPointer (when machine-code calls interpreter primitives).

Knowing which state the VM is in is non-trivial.  So I don't know what to
do here.  In the old sim window you'll see the context menu has options for
printing the stack in each of these states.


> 2. Ah, events, events, events...how do I know thee...let me count the ways.
>
> Standard Morphic events are created by HandMorph>>processEvents when
> invoked by  WorldState doOneCycleNowFor:
>
> HandMorph grabs the raw evtBuf array off the Sensor (exactly as I
> forwarded in round one of this) and then wraps them to make them handy for
> Morphic. Unfortunately what is handy for Morphic is not handy for the VM
> Simulator.
>
> 2.a. The obvious solution is to reverse the wrapping. I do not see any
> existing work that does this, and it looks a bit daunting. My hunch is that
> I will have to do it. At that point, you can ridicule my lack of low-level
> bit fiddling experience.
>

:-)


> 2.a.1 Unfortunately, HandMorph's
> addEventListener/sendListenEvent/handleListenEvent event broadcasting
> framework sends these wrapped events.
>
> 2.b. I modified HandMorph and added a parallel event broadcasting/listener
> framework with
> addPrimitiveEventListener/sendListenPrimitiveEvent/handleListenPrimitiveEvent
> and that works just fine. I am able to subscribe to the primitive events
> from
> my Morph's model and forward them to the vm simulator--just like with my
> previous approach with EventSensor.
>
> 2.b.1 I am going to continue with this for a bit, as next up, I think I
> can improve performance by injecting only those events that fall within the
> bounds of the ImageMorph that houses the simulated World. I will be on that
> tomorrow.
>
> 2.c. Tim R. requested a means to feed events directly to the simulator.
> The eventListener framework in HandMorph can be ported to the GUI in 10
> minutes, so there is hope there.
>
> 3. After 2.b.1, I am going to see about injecting Morphic Events that only
> occur on the ImageMorph that houses the simulated World. I started with
> this approach initially, but chickened out when I saw the wrapping task and
> went with  the 2 series instead.
>
> I will try to get a clean copy of my code to you all in a couple of days.
> I have a lot of missteps in my work due to the various approaches I am
> trying, so its a bit messy at the moment.
>

Take missteps as a sign that you're effectively exploring the solution
space.  Anyway, this is great!  Thanks!

Anyway, that's the update.
>
>
> cordially,
>
>
> tty
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140204/b715754c/attachment.htm


More information about the Vm-dev mailing list