[Vm-dev] who is bak?

[Eliot Miranda]

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 :-).

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
>
>


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