[Vm-dev] Probably pointless endianness question re: Float changes circa 4.6
eliot.miranda at gmail.com
Mon Jul 6 19:25:57 UTC 2020
On Sun, Jul 5, 2020 at 10:22 PM Tim Johnson <digit at sonic.net> wrote:
> Hi Eliot,
> 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.
> On Jul 5, 2020, at 3:00 PM, Eliot Miranda wrote:
> 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?)
> I designed the scheme so that it would *not* have fatal implications on
> any platform :-)
> This is a good point. It helps me to improve my question:
> 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?
> (This question & others summarized below.)
> First let’s understand the representation. A Float is a double-precision
> 64-bit ieee float represented as a two element word array.
> Before the changes floats were always stored in the heap in big-endian
> format which meant:
> - aFloat at: 1 accessed the most significant word of the float on both big
> & little median platforms
> - 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
> This unfairly penalizes little endian platforms.
> Yes -- no doubt this was an important move.
> My simple change was three-fold:
> 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).
> 2. on load if required all Floats would be word reversed to ensure they
> are in platform order
> ^^ this is something I'm hoping to instrument or measure; more on that
> 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
> So what I did leveled the playing field. How does this have fatal
> consequences for big endian platforms?
> Well, I mean, that's so similar to the question I was trying to get
> across: could it? And, if so, under which conditions?
Since the scheme moves the cost into Float>>at:[put:] it would be I guess
in serializing/deserializing floats etc. But I doubt the difference would
be measurable; it'll be swamped by other effects.
> I definitely didn't mean to sound conclusive or be finger-pointy, and I'm
> sorry if it read that way.
And I don't mean to sound attacked either. I was really just curious. Had
I not seem something that would affect big-endian platforms (Cog has yet to
be compiled on a big endian platform)?
> 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.
Yes. The Interpreter VM may be missing the closure support, or correct
implementation of the closure support. But it may not. I haven't used it.
Dave would know what the state of play is.
> 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.
> Does this explanation make the scheme seem more sensible now?
> 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.
> 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. :)
Sorry. I should have tried to craft my tone netter.
> Your & Dave's responses have helped me to hone my question(s):
> 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.
IIRC, yes. There's a macro in sqwMemoryAccess.h to access floats that
always did the reversal on little-endian platforms. This isn't necessary
with 6505. So look at sqMemoryAccess.h in your platform sources and in the
opensmalltalk-vm sources and that should help you decide what the right
> 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 )
Oh, nothing noticabl;e. The conversion only happens when the endianness is
changing. So in normal use you shouldn't see any slow down.
> 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?
Well any fix should go into the platform sources for the Interpreter VM.
> That is the crux of my previous blathering about any hypothetical
> big-endian platforms of the future.
> I hope I haven't wasted your time or energy, Eliot. Thanks a lot for your
Not at all.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev