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

Tim Johnson digit at sonic.net
Mon Jul 6 05:54:14 UTC 2020


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


> - 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?

Thanks a lot,
Tim



More information about the Vm-dev mailing list