[Vm-dev] Simulating the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives

Igor Stasenko siguctua at gmail.com
Tue Jan 7 17:55:12 UTC 2014


On 6 January 2014 18:30, Eliot Miranda <eliot.miranda at gmail.com> wrote:

>
> Hi All,
>
>     I'm just revising plugin treatment in Spur and came across this old
> snippet of mysterious code:
>
> InterpreterSimulator>>loadNewPlugin: pluginString
>  | plugin simClass |
> transcript cr; show:'Looking for module ', pluginString.
> (#('FloatArrayPlugin' 'Matrix2x3Plugin')
>  includes: pluginString) ifTrue:
> [transcript show: ' ... defeated'. ^ nil].
>
> rofl, my applauds to anyone who wrote this code :)

Sadly (or happily), except from this little comment there not much i can
offer right now,
and have to shut up and vanish in a puff of smoke :)



> In the past I got as far as rewriting it to read...
>
> InterpreterSimulator>>loadNewPlugin: pluginString
> | plugin plugins simulatorClasses |
> transcript cr; show: 'Looking for module ', pluginString.
>  "but *why*??"
> (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue:
>  [transcript show: ' ... defeated'. ^nil].
> plugins := InterpreterPlugin allSubclasses select: [:psc| psc moduleName
> asString = pluginString asString].
>
> In revising the code for Spur I removed the defeat code and found out
> more.  It's essentially because the BalloonPlugin has difficulty simulating
> accesses of 32-bit floats.  If you simply defeat the code and let things
> run soon you get failures in FloatArrayPlugin & Matrix2x3Plugin primitives.
>  These can be fixed by implementing the following in the FloatArrayPlugin &
> Matrix2x3Plugin:
>
> cCoerce: value to: cType
> ^cType = 'float'
> ifTrue: [value asIEEE32BitWord]
>  ifFalse: [value]
>
> But soon you hit more difficult failures in the BalloonEnginePlugin, e.g.
> in
>
> BalloonEngineBase>>transformPointX: xValue y: yValue into: dstPoint
>  "Transform srcPoint into dstPoint by using the currently loaded matrix"
> "Note: This should be rewritten so that inlining works (e.g., removing
>  the declarations and adding argument coercions at the appropriate
> points)"
> | x y transform |
> <inline: true>
>  <var: #dstPoint type:'int *'>
> <var: #xValue type: 'double '>
> <var: #yValue type: 'double '>
>  <var: #transform type:'float *'>
> transform := self edgeTransform.
> x := ((((transform at: 0) * xValue) +
>  ((transform at: 1) * yValue) +
> (transform at: 2)) * self aaLevelGet asFloat) asInteger.
> y := ((((transform at: 3) * xValue) +
>  ((transform at: 4) * yValue) +
> (transform at: 5)) * self aaLevelGet asFloat) asInteger.
> dstPoint at: 0 put: x.
>  dstPoint at: 1 put: y.
>
> where x and y end up being the integer representation of 64-bit floats
> while dstPoint accepts the integer representation of 32-bit floats.  At
> least I think that's what's going on.
>
> In any case I need to focus on Spur and can't spare the time to fix this.
>  But I find it unsatisfactory.  It means the VM simulation isn't accurate.
>  In the simulation the primitives fail and Smalltalk code is run.  In the
> real VM the primitives work.  And that's deeply unsatisfying.
>
> So if there's anyone itching for a VM challenge try and make
> the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives
> simulate correctly, removing the defeat code above.  That would be a great
> new year's gift.
> --
> best,
> Eliot
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140107/6402c575/attachment.htm


More information about the Vm-dev mailing list