Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007805 [Squeak] VM feature always 01-06-14 18:26 01-06-14 18:26
Reporter lewis View Status public  
Assigned To lewis
Priority normal Resolution open  
Status assigned   Product Version
Summary 0007805: Need simulation support for the BalloonEnginePlugin, FloatArrayPlugin & Matrix2x3Plugin primitives
Description VM simulation support is not available for these plugins, apparently due to issues in simulating 32 bit float access. Reported on vm-dev: [^]
Additional Information Feature request and background:
Date: Mon, 6 Jan 2014 09:30:17 -0800
From: Eliot Miranda <>
To: Squeak Virtual Machine Development Discussion <>
Subject: [Vm-dev] 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 &

cCoerce: value to: cType
^cType = 'float'
ifTrue: [value asIEEE32BitWord]
ifFalse: [value]

But soon you hit more difficult failures in the BalloonEnginePlugin, e.g.

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.
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
01-06-14 18:26 lewis New Issue
01-06-14 18:26 lewis Status new => assigned
01-06-14 18:26 lewis Assigned To  => lewis

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
29 total queries executed.
26 unique queries executed.
Powered by Mantis Bugtracker