<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Eliot,<div><br></div><div>I had a decent draft of this response, and my mail client pooped out when I hit send. Trying again. If this comes across as terse (I doubt it ;) ), please forgive.<br><div><br><div><div>On Jul 5, 2020, at 3:00 PM, Eliot Miranda wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite">But I'm just hoping to verify here that the Float changes in image format 6505 could have fatal implications for a big-endian platform like PowerPC (the formerly-native format for the Floats ;) ) on a "vintage" stack/interpreter VM, and that perhaps that would have been /expected/ to be the last straw for it. (A further question might be: how big would the lift have been to keep it going? Or was that work done and just would require some extra attention?)</blockquote><br>I designed the scheme so that it would *not* have fatal implications on any platform :-)<br></div></blockquote><div><br></div><div>This is a good point. It helps me to improve my question: </div><div><br></div><div>Q: Could my build environment (platform support code, non-oscog VMMaker sources, Squeak 4.5 hosted-VMMaker) be missing something necessary for the scheme to work as designed?</div><div><br></div><div>(This question & others summarized below.)</div><br><blockquote type="cite"><div>First let’s understand the representation. A Float is a double-precision 64-bit ieee float represented as a two element word array. <br><br>Before the changes floats were always stored in the heap in big-endian format which meant:<br><br>- aFloat at: 1 accessed the most significant word of the float on both big & little median platforms <br>- on little endian platforms the vm therefore has to word reverse Float objects, perform arithmetic to obtain a new 64-big float, and word reverse it to store it back into a new Float<br><br>This unfairly penalizes little endian platforms.<br></div></blockquote><div><br></div><div>Yes -- no doubt this was an important move.</div><br><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>My simple change was three-fold:<br>1. A bit in the image header specifies whether floats in the image are in big-endian format (bit unset) or in platform format (eg big endian on PPC, little endian on x86).<br><br>2. on load if required all Floats would be word reversed to ensure they are in platform order<br></div></blockquote><div><br></div><div>^^ this is something I'm hoping to instrument or measure; more on that below.</div><br><blockquote type="cite"><div><br>3. Float at: was modified so that on little endian platforms Float at: 1 answered the most significant word, just as it does on big endian platforms, hence hiding from the image the change in layout on little endian platforms and avoiding having to do any word reversal in arithmetic on any platforms<br><br><br>So what I did leveled the playing field. How does this have fatal consequences for big endian platforms?<br></div></blockquote><div><br></div><div>Well, I mean, that's so similar to the question I was trying to get across: could it? And, if so, under which conditions?</div><div><br></div><div>I definitely didn't mean to sound conclusive or be finger-pointy, and I'm sorry if it read that way.</div><div><br></div><div>After getting the 6505 format image to load & the world to (mostly) display, it felt like a small victory. But then seeing Float-related errors in SqueakDebug.log after force-quitting made me think this conversion process could be related, and I hoped to gather more info.</div><br><blockquote type="cite"><div>Note that the word reversal on Float at: is for free because the primitive only takes 1&2 as valid indices, so the implementation is really cheap. So in fact what I did was ensure that fp was as fast as possible on both platforms and (consciously) didn’t penalize either platform.<br><br>Does this explanation make the scheme seem more sensible now?</div></blockquote><div><br></div>I really appreciate this explanation. All I could find previously on this subject was that thread I linked in my prior message, which didn't indicate which path was actually chosen. This helps make it clear.</div><div><br></div><div>From my easy chair, your scheme looks brilliant and thorough. I never meant to suggest otherwise, and am also totally underprepared and underqualified to do so. The only thing not sensible here is that I'm trying to build & update a ten-year-old snapshot of the code for the Mac VM on an antiquated machine based on a niche architecture. :) </div><div><br></div><div>Your & Dave's responses have helped me to hone my question(s):</div><div><br></div><div>Q: Did this Float scheme for 6505 require a change to the VM in order to function properly? If so, (similar to what I asked above) is it possible that the VM I am building is missing some part of that change? (Whether that is something that exists in VMMaker-oscog but didn't make it to VMMaker, or whether it's some platform support code, or a changed version of a primitive...) If not, I am probably barking up the wrong tree.</div><div><br></div><div>Q: How long might I expect the Float conversion at load (#2 above) to take, on a slower image running on a slower computer? Milliseconds, seconds, minutes, or longer? If I wanted to log it, trace it, or debug it, how could I find it? (Dave helped with this, thanks: ContextInterpreter>>normalizeFloatOrderingInImage )</div></div><div><br></div><div>Q: If I spend the time to figure this out and do something about it, is there any way it could benefit anyone other than myself? That is the crux of my previous blathering about any hypothetical big-endian platforms of the future. </div><div><br></div></div><div>I hope I haven't wasted your time or energy, Eliot. Thanks a lot for your explanation.</div><div><br></div><div>Tim</div><div><br></div></body></html>