[Vm-dev] Simulator in Pharo 3

Eliot Miranda eliot.miranda at gmail.com
Fri Feb 14 22:48:15 UTC 2014


On Fri, Feb 14, 2014 at 4:35 AM, Stefan Marr <smalltalk at stefan-marr.de>wrote:

>
> Hi Eliot:
>
> On 13 Feb 2014, at 21:04, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> > thanks, lovely.  i already addressed the getSystemParameter: issue.
>
> In the StackInterpreterSimulator, the various #run... methods do
> unconditionally the initialization of stack pages and initial context.
> This looks wrong to me, especially since the comment of #runForNBytes:
> says that I should be able to use it repeatedly.
> I would move the initialization to #initializeInterpreter: in
> StackInterpreterSimulator and remove it from all the run methods. See [1].
>

I agree.  This would be really nice.  But alas the stack zone must be
alloca'ed when first entering the interpreter :-(.

So, with all latest changes the code below gives you a
> StackInterpreterSimulator that executes the latest Pharo images.
> Until it runs into inconsistent values in the BalloonEngineSimulation. But
> for many cases this should already be more than sufficient.
>

I see this occasionally and don't understand the code well enough to fix
it.  But it seems a false error.  if you proceed through the inconsistent
value errors the system keeps on running.  Is there anyone out there who
understands the BalloonPlugin well enough to fix it?  I've tweaked out some
of the errors (and not broken anything) but it is not something I
understand.


>   InterpreterStackPage initialize.
>   StackInterpreterSimulator initializeWithOptions: Dictionary new.
>   sim := StackInterpreterSimulator new.
>   sim openOn: 'Pharo.image'.
>   sim openAsMorph.
>   sim initStackPages.
>   sim loadInitialContext.
>   1 to: 500 do: [:i |
>         sim runForNBytes: 100000.
>         World doOneCycleNow ].
>
> At the moment, there seem to be strange interactions going on between the
> simulator and the rest of the system.
> At least using `[sim run] fork` doesn't work properly, and I suppose until
> the event handling is fixed #run will not work completely either.
>
> Please note, all changes I did is merely fixing bit rot, nothing really
> broken.
> I assume that the BalloonEngine issue would take a little more to debug,
> but I am not sure what it is in the first place. So interested parties
> could try it comment.
>
>
> Best regards
> Stefan
>
> [1]
> https://github.com/smarr/pharo-vm/commit/114f5b3db0ff2185ca5eac0d033eb95b99f524cb
>
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>


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


More information about the Vm-dev mailing list