[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