[Vm-dev] Probably pointless endianness question re: Float changes circa 4.6
eliot.miranda at gmail.com
Tue Jul 7 18:59:57 UTC 2020
> 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.
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.
More information about the Vm-dev