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

Eliot Miranda eliot.miranda at gmail.com
Tue Jul 7 18:59:57 UTC 2020


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.

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.

> Dave


_,,,^..^,,,_ (phone)


More information about the Vm-dev mailing list