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

[Tim Johnson]

Hi Eliot,

I had a decent draft of this response, and my mail client pooped out  
when I hit send.  Trying again.  If this comes across as terse (I  
doubt it ;) ), please forgive.

On Jul 5, 2020, at 3:00 PM, Eliot Miranda wrote:

>> But I'm just hoping to verify here that the Float changes in image  
>> format 6505 could have fatal implications for a big-endian platform  
>> like PowerPC (the formerly-native format for the Floats ;) ) on a  
>> "vintage" stack/interpreter VM, and that perhaps that would have  
>> been /expected/ to be the last straw for it.  (A further question  
>> might be:  how big would the lift have been to keep it going?  Or  
>> was that work done and just would require some extra attention?)
>
> I designed the scheme so that it would *not* have fatal implications  
> on any platform :-)

This is a good point.  It helps me to improve my question:

Q: Could my build environment (platform support code, non-oscog  
VMMaker sources, Squeak 4.5 hosted-VMMaker) be missing something  
necessary for the scheme to work as designed?

(This question & others summarized below.)

> First let’s understand the representation.  A Float is a double- 
> precision 64-bit ieee float represented as a two element word array.
>
> Before the changes floats were always stored in the heap in big- 
> endian format which meant:
>
> - aFloat at: 1 accessed the most significant word of the float on  
> both big & little median platforms
> - on little endian platforms the vm therefore has to word reverse  
> Float objects, perform arithmetic to obtain a new 64-big float, and  
> word reverse it to store it back into a new Float
>
> This unfairly penalizes little endian platforms.

Yes -- no doubt this was an important move.

>
> My simple change was three-fold:
> 1. A bit in the image header specifies whether floats in the image  
> are in big-endian format (bit unset) or in platform format (eg big  
> endian on PPC, little endian on x86).
>
> 2. on load if required all Floats would be word reversed to ensure  
> they are in platform order

^^ this is something I'm hoping to instrument or measure;  more on  
that below.

>
> 3. Float at: was modified so that on little endian platforms Float  
> at: 1 answered the most significant word, just as it does on big  
> endian platforms, hence hiding from the image the change in layout  
> on little endian platforms and avoiding having to do any word  
> reversal in arithmetic on any platforms
>
>
> So what I did leveled the playing field.  How does this have fatal  
> consequences for big endian platforms?

Well, I mean, that's so similar to the question I was trying to get  
across:  could it?  And, if so, under which conditions?

I definitely didn't mean to sound conclusive or be finger-pointy, and  
I'm sorry if it read that way.

After getting the 6505 format image to load & the world to (mostly)  
display, it felt like a small victory.  But then seeing Float-related  
errors in SqueakDebug.log after force-quitting made me think this  
conversion process could be related, and I hoped to gather more info.

> Note that the word reversal on Float at: is for free because the  
> primitive only takes 1&2 as valid indices, so the implementation is  
> really cheap.  So in fact what I did was ensure that fp was as fast  
> as possible on both platforms and (consciously) didn’t penalize  
> either platform.
>
> Does this explanation make the scheme seem more sensible now?

I really appreciate this explanation.  All I could find previously on  
this subject  was that thread I linked in my prior message, which  
didn't indicate which path was actually chosen.  This helps make it  
clear.

 From my easy chair, your scheme looks brilliant and thorough.  I  
never meant to suggest otherwise, and am also totally underprepared  
and underqualified to do so.  The only thing not sensible here is that  
I'm trying to build & update a ten-year-old snapshot of the code for  
the Mac VM on an antiquated machine based on a niche architecture.  :)

Your & Dave's responses have helped me to hone my question(s):

Q:  Did this Float scheme for 6505 require a change to the VM in order  
to function properly?  If so, (similar to what I asked above) is it  
possible that the VM I am building is missing some part of that  
change?  (Whether that is something that exists in VMMaker-oscog but  
didn't make it to VMMaker, or whether it's some platform support code,  
or a changed version of a primitive...)  If not, I am probably barking  
up the wrong tree.

Q:  How long might I expect the Float conversion at load (#2 above) to  
take, on a slower image running on a slower computer?  Milliseconds,  
seconds, minutes, or longer?  If I wanted to log it, trace it, or  
debug it, how could I find it?  (Dave helped with this, thanks:   
ContextInterpreter>>normalizeFloatOrderingInImage )

Q:  If I spend the time to figure this out and do something about it,  
is there any way it could benefit anyone other than myself?  That is  
the crux of my previous blathering about any hypothetical big-endian  
platforms of the future.

I hope I haven't wasted your time or energy, Eliot.  Thanks a lot for  
your explanation.

Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200705/a221c419/attachment.html>