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

[David T. Lewis]

On Sun, Jul 05, 2020 at 03:00:23PM -0700, Eliot Miranda wrote:
>  
> Hi Tim,
> 
> > On Jul 5, 2020, at 12:52 PM, Tim Johnson <digit at sonic.net> wrote:
> > 
> > ???Hi all,
> > 
> > I finally achieved something I have wanted to do for ten years, though its relevance has steadily declined over that time:  build the Carbon and Cocoa VMs on a PowerPC Mac.
> > 
> > - Carbon VM (4.2.5b1, from VMMaker 4.2.4 on Squeak 4.1)
> > - iOS/ObjC/Cocoa VM (5.7b2, from VMMaker 4.2.6 on Squeak 4.1)
> > 
> > After building a successful product, I took the Carbon VM and began incrementing the non-oscog VMMaker's version in a Squeak 4.5 image.  I was able to build products along the way from 4.3.21 past 4.4.12 and beyond.  (I had to stop when [as could be expected] some plugins wouldn't export and some support code was missing.)
> > 
> > Eventually I had a Mac Carbon VM which could load 4.6's format 6505 image, and it began displaying the world, but it also had a few drawing errors and didn't respond to events.  A snip from SqueakDebug.log is at the end of this message, but probably isn't worth anyone's time to evaluate!
> > 
> > Where I think my efforts hit a dead end is with the Float changes [2] in the 6505 image format used by Squeak 4.6 [1].
> > 
> > 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 :-)
> 
> 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.
> 
> 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
> 

To add some detail:

- In a 6504 image, Floats are stored in big-endian format (as Eliot explains above) regardless of
  the endianness of the current platform

- In a 6505 image, Floats are stored in the native platform word ordering for the current platform

- When a 6505 image is loaded into a classic interpreter VM the floats are converted big-endian
  format in ContextInterpreter>>normalizeFloatOrderingInImage which effectively turns it back
  into a 6504 image

- When as 6505 image that was saved from a little-endian machine is loaded into an oscog (Cog/Spur)
  VM running on a big-endian platform, it is loaded in the saved format (presumeably little endian)

So ... I am only guessing, but AFAIK we have never tried loading a 6505 image that was saved
on a little-endian machine into a Cog/Spur VM running on a big-endian platform. Quite possibly
in needs a word-reversal operation in that case.

Dave