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]
But soon you hit more difficult failures in the BalloonEnginePlugin, e.g. in
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.