[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