[Vm-dev] Probably pointless endianness question re: Float changes circa 4.6

[Eliot Miranda]

Hi Tim,

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
> below.
>
>
> 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
solution is.


> 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
> explanation.
>

Not at all.
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200706/e4645c8b/attachment-0001.html>