[Vm-dev] who is bak?
Tobias Pape
Das.Linux at gmx.de
Thu Oct 1 07:41:36 UTC 2015
Hi Eliot,
On 01.10.2015, at 03:17, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Tobias,
>
> it's potentially a tricky issue for the RPython VM. I finally fixed the source of the issues with the BalloonPlugin under simulation. Bastian had changed it from
>
> BalloonEngineSimulation>>#loadWordTransformFrom: transformOop into: destPtr length: n
> "Load a float array transformation from the given oop"
>
> | srcPtr wordDestPtr |
>
> false ifTrue:
> [^super loadWordTransformFrom: transformOop into: destPtr length: n].
>
> srcPtr := interpreterProxy firstIndexableField: transformOop.
> wordDestPtr := destPtr as: CArrayAccessor. "Remove float conversion shell"
> 0 to: n-1 do: [:i | wordDestPtr at: i put: (srcPtr floatAt: i)]
>
> to
>
> BalloonEngineSimulation>>#loadWordTransformFrom: transformOop into: destPtr length: n
> "Load a float array transformation from the given oop"
> | srcPtr wordDestPtr |
> false
> ifTrue: [^ super
> loadWordTransformFrom: transformOop
> into: destPtr
> length: n].
> srcPtr := interpreterProxy firstIndexableField: transformOop.
> wordDestPtr := destPtr as: CArrayAccessor.
> "Remove float conversion shell"
> 0 to: n - 1
> do: [:i | wordDestPtr at: i put: (srcPtr floatAt: i) asIEEE32BitWord]
>
> i.e. he changed
> wordDestPtr at: i put: (srcPtr floatAt: i)
> to
> wordDestPtr at: i put: (srcPtr floatAt: i) asIEEE32BitWord
>
> This breaks some hidden optimization in the simulator where a BalloonArray has a handle on the "object" in the memory array and a cache of object values in a parallel simArray. Unless the simArray's values correctly mirror those in the underlying heap object in the simulator's byte array, there are errors in the BalloonPluginSimulation. I finally fixed these today, changing Bastian's code to
>
> BalloonEngineSimulation>>#loadWordTransformFrom: transformOop into: destPtr length: n
> "Load a float array transformation from the given oop"
> | srcPtr |
> srcPtr := interpreterProxy firstIndexableField: transformOop.
> "Use BalloonArray's float conversion shell. It stores both the float bits into
> the heap object, and the float object into the simArray. This is needed for
> correct simulation, otherwise there will be errors in BalloonArray>>floatAt:"
> 0 to: n - 1 do: [:i| destPtr at: i put: (srcPtr floatAt: i)]
>
> i.e. nuking the unneeded "wordDestPtr := destPtr as: CArrayAccessor." and changing the code to not send asIEEE32BitWord it the float ti be stored, because this is done inside the BalloonArray that is referred to via destPtr.
>
> So. I'm strongly confident my code above is correct for simulation but it may break the Python VM. If it does then I think the RPython VM needs to avoid conflict with simulation subclasses of plugins, such as the BalloonEngineSimulation subclass of BalloonEnginePlugin, e.g. by using a subclassing naming scheme such as BalloonEngineForRPython or some such. The simulator needs to work :-).
>
RSqueak is actually not doing anything special, but reusing the Simulation code.
So as long as the simulation works, it should work for RSqueak, too :)
Best regards
-Tobias
> Hope this makes sense.
>
> On Wed, Sep 30, 2015 at 2:12 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>
> Hi,
>
> On 30.09.2015, at 22:57, Balázs Kósi <kosi.balazs at ezomer.hu> wrote:
>
> > Hi,
> >
> > It's not me. Most probably you are looking for Bastian Kruck: http://www.bkruck.de/
> >
>
> Yes, It is Bastian. He worked on this stuff earlier this year, So Eliot, you
> can also talk to Tim or me on that matter :)
>
> Best regards
> -Tobias
More information about the Vm-dev
mailing list