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

[David T. Lewis]

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.

Dave