<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 6 January 2014 18:30, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hi All,<div><br></div><div> I'm just revising plugin treatment in Spur and came across this old snippet of mysterious code:</div>
<div><br></div><div>InterpreterSimulator>>loadNewPlugin: pluginString</div>
<div><span style="white-space:pre-wrap"> </span>| plugin simClass |</div><div><span style="white-space:pre-wrap"> </span>transcript cr; show:'Looking for module ', pluginString.</div><div><span style="white-space:pre-wrap"> </span>(#('FloatArrayPlugin' 'Matrix2x3Plugin')</div>
<div><span style="white-space:pre-wrap"> </span>includes: pluginString) ifTrue:</div><div><span style="white-space:pre-wrap"> </span>[transcript show: ' ... defeated'. ^ nil].</div><div><br></div></div></blockquote>
<div>rofl, my applauds to anyone who wrote this code :)<br><br></div><div>Sadly (or happily), except from this little comment there not much i can offer right now,<br></div><div>and have to shut up and vanish in a puff of smoke :)<br>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>In the past I got as far as rewriting it to read...</div>
<div><br></div><div>InterpreterSimulator>>loadNewPlugin: pluginString<div><span style="white-space:pre-wrap"> </span>| plugin plugins simulatorClasses |</div><div><span style="white-space:pre-wrap"> </span>transcript cr; show: 'Looking for module ', pluginString.</div>
<div><span style="white-space:pre-wrap"> </span>"but *why*??"</div><div><span style="white-space:pre-wrap"> </span>(#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue:</div>
<div><span style="white-space:pre-wrap"> </span>[transcript show: ' ... defeated'. ^nil].</div><div><span style="white-space:pre-wrap"> </span>plugins := InterpreterPlugin allSubclasses select: [:psc| psc moduleName asString = pluginString asString].</div>
<div><br></div><div>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:</div>
<div><br></div><div>cCoerce: value to: cType</div><div><span style="white-space:pre-wrap"> </span>^cType = 'float'</div><div><span style="white-space:pre-wrap"> </span>ifTrue: [value asIEEE32BitWord]</div>
<div><span style="white-space:pre-wrap"> </span>ifFalse: [value]</div><div><br></div><div>But soon you hit more difficult failures in the BalloonEnginePlugin, e.g. in </div><div><div><br></div><div>BalloonEngineBase>>transformPointX: xValue y: yValue into: dstPoint</div>
<div><span style="white-space:pre-wrap"> </span>"Transform srcPoint into dstPoint by using the currently loaded matrix"</div><div><span style="white-space:pre-wrap"> </span>"Note: This should be rewritten so that inlining works (e.g., removing</div>
<div><span style="white-space:pre-wrap"> </span>the declarations and adding argument coercions at the appropriate points)"</div><div><span style="white-space:pre-wrap"> </span>| x y transform |</div><div><span style="white-space:pre-wrap"> </span><inline: true></div>
<div><span style="white-space:pre-wrap"> </span><var: #dstPoint type:'int *'></div><div><span style="white-space:pre-wrap"> </span><var: #xValue type: 'double '></div><div><span style="white-space:pre-wrap"> </span><var: #yValue type: 'double '></div>
<div><span style="white-space:pre-wrap"> </span><var: #transform type:'float *'></div><div><span style="white-space:pre-wrap"> </span>transform := self edgeTransform.</div><div><span style="white-space:pre-wrap"> </span>x := ((((transform at: 0) * xValue) +</div>
<div><span style="white-space:pre-wrap"> </span>((transform at: 1) * yValue) +</div><div><span style="white-space:pre-wrap"> </span>(transform at: 2)) * self aaLevelGet asFloat) asInteger.</div><div><span style="white-space:pre-wrap"> </span>y := ((((transform at: 3) * xValue) +</div>
<div><span style="white-space:pre-wrap"> </span>((transform at: 4) * yValue) +</div><div><span style="white-space:pre-wrap"> </span>(transform at: 5)) * self aaLevelGet asFloat) asInteger.</div><div><span style="white-space:pre-wrap"> </span>dstPoint at: 0 put: x.</div>
<div><span style="white-space:pre-wrap"> </span>dstPoint at: 1 put: y.</div></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div>-- <br>best,<div>Eliot</div>
</div></div></div>
<br></blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div>