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

[David T. Lewis]

Hi Eliot,

On Tue, Jul 07, 2020 at 11:59:57AM -0700, Eliot Miranda wrote:
>  
> Hi Dave,
> 
> > On Jul 7, 2020, at 10:59 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > ???
> > Hi Tim,
> > 
> >> On Sun, Jul 05, 2020 at 10:54:14PM -0700, Tim Johnson wrote:
> >> 
> >> Hi Dave,
> >> 
> >>> On Jul 5, 2020, at 5:48 PM, David T. Lewis wrote:
> >>> 
> >>> 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
> >> 
> >> Thank you.  This helps me know where to possibly dig into the  
> >> conversion process.
> >> 
> >> Also, I wanted to try this.  So I just did:
> >> 
> >> 1) I loaded Squeak4.6-13700 (one of the alpha releases) into the  
> >> 4.10.2-2614 VM on my Raspberry Pi, and then saved it out.
> >> 
> >> 2) `ckformat` verifies that the original image was is a 6505 format,  
> >> and the image I saved out is a 6504 format.
> >> 
> >> 3) Transferred it over to my G4, and it very much runs!  This  
> >> particular VM was built with VMMaker 4.4.12.
> >> 
> >> Amazing!  What an effective solution :)   Stepping stone-by-stone into  
> >> the future...
> >> 
> > 
> > By way of a belated follow up - The first version of VMMaker that provided
> > support for loading 6505 images in a classic interpreter VM was VMMaker-dtl.190
> > (VMMaker versionString 4.3.4) from October 6, 2010. There were later
> > changes related to refactoring, but anything from 4.3.4 onwards should
> > successfully load and run V3 images saved from Cog.
> > 
> > Prior to your efforts, this had never been tested on a big-endian
> > machine, so I could not guarantee that it worked. But from your note
> > above, it sounds like it did work when you tried it (good!).
> > 
> > To summarize - the basic logic is that if the image file being loaded is
> > 6505 and if the currently running VM is on a little-endian machine, then
> > swap words in all Float objects before entering the interpreter (i.e.
> > while loading the 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.
> >> 
> >> Very interesting.
> >> 
> >> Are there any Cog/Spur VMs for big-endian platforms?
> >> 
> > 
> > As far as I know, there are no big-ending Cog/Spur VMs. If somebody
> > creates one, we would very likely need to update the word-swapping
> > logic that I described above, because it would be saving the Float
> > data in native order, which would not be big-endian. Something for
> > future consideration I guess. The Cog/Spur VM would also need to
> > handle word swapping if platform endianness changed.
> 
> I???ve not removed any of the load-time byte swapping logic.  What???s missing is correct handling of big-end is ness in Spur and the JIT.  The ones I noticed as I wrote code are makes self flag: #endianness.  There are a few crucial ones to deal with.
> 

Indeed, I understand that doing the JIT for big-endian is not a trivial
thing, especially if there is no realistic market for it.

> Boris will likely have encountered these as he???s working on the POC code generator, unless, sensibly he decides to use it in little-endian mode while developing the code generator.
> 
> The issues are not hard to fix.  The issue is best how to select the right code, use cppIf: or ifTrue: or endian-specific subclasses.
>

With respect to the Float order issue we were discussing, I think that
the only thing that needs to be addressed is to look at the endianness of
the saved image, and do the word swap if endianness is different in the
current VM. It's a small bit of logic, and it would be very similar to
the method that I put into interpreter VM, except that there is no need
to be concerned about converting back to 6504 format, just do the word
swap if current endianness is different.

All image formats after 6504 use native float ordering, so that logic
would apply everywhere, and it just needs to be done during image load.
The word swapping is fast, although I can't say I have ever actually
measured it. But even if it was slow it would be a very rare use case,
so nothing to worry about.

Dave