Smalltalk › Squeak › Squeak VM

Simulating the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Eliot Miranda-2

Simulating the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives

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

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

David T. Lewis

Re: Simulating the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives

Just in case this does not get addressed quickly, I opened a Mantis issue
for it so we do not lose track of the request:

http://bugs.squeak.org/view.php?id=7805

Dave

On Mon, Jan 06, 2014 at 09:30:17AM -0800, Eliot Miranda 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].
>
> 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

tty

Re: Simulating the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives

In reply to this post by Eliot Miranda-2

If I knew enough to help, I would.
I have to knock out some other tasks this week, and I will take a stab at it.
Do not depend on me, however.

tty

ccrraaiigg

re: Simulating the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives

Go for it, Timothy! I wrote simulator support for sockets and large
integers, and it was pretty straightforward. I can help if you like.

-C

--
Craig Latta
www.netjam.org/resume
+1 510 984 8117
(Skype rings this until 31 January 2014)

tty

re: Simulating the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives

Thank you.

I will attempt it later this week. I have some study on BlockContexts to clean up and some consulting work to do as well. I have the task scheduled in my pla

When I am done studying the problem, I will post the outlines of what I see and my approach to attack it.

I appreciate the offer to help.

tty

---- On Mon, 06 Jan 2014 18:52:00 -0800 Craig Latta <[hidden email]> wrote ----

Go for it, Timothy! I wrote simulator support for sockets and large
integers, and it was pretty straightforward. I can help if you like.

-C

--
Craig Latta
www.netjam.org/resume
+1 510 984 8117
(Skype rings this until 31 January 2014)

Igor Stasenko

Re: Simulating the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives

In reply to this post by Eliot Miranda-2

On 6 January 2014 18:30, Eliot Miranda <[hidden email]> 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.

tty

VMSqueakV3BytecodeConstants is both Subclass of VMConstants and has VMConstants in its poolDictinaries.

Is this a design pattern? an oversite? a non-issue?

thx,

tty

Eliot Miranda-2

Re: VMSqueakV3BytecodeConstants is both Subclass of VMConstants and has VMConstants in its poolDictinaries.

Hi TiTtym,

On Mon, Jan 13, 2014 at 11:10 AM, gettimothy <[hidden email]> wrote:

Is this a design pattern? an oversite? a non-issue?

Oops. It's a bug. BTW, spelling is "oversight".

--
thanks!

Eliot

Eliot Miranda-2

Re: VMSqueakV3BytecodeConstants is both Subclass of VMConstants and has VMConstants in its poolDictinaries.

In reply to this post by tty

Hi Tty,

On Mon, Jan 13, 2014 at 11:10 AM, gettimothy <[hidden email]> wrote:

Is this a design pattern? an oversite? a non-issue?

Forgive my misspelling in earlier message ;-). I deserved that. It's fixed and I'll commit soon. It should of course inherit from SharedPool.

--
best,

Eliot

tty

Re: VMSqueakV3BytecodeConstants is both Subclass of VMConstants and has VMConstants in its poolDictinaries.

Hey! I finally did something (trivially) useful. (:

Thank you for your time.

tty

---- On Mon, 13 Jan 2014 11:29:28 -0800 Eliot Miranda<[hidden email]> wrote ----

Hi Tty,

On Mon, Jan 13, 2014 at 11:10 AM, gettimothy <[hidden email]> wrote:

Is this a design pattern? an oversite? a non-issue?

Forgive my misspelling in earlier message ;-). I deserved that. It's fixed and I'll commit soon. It should of course inherit from SharedPool.
--
best,
Eliot