[m-dev.] question about 32 bit machines

[Peter Wang]

On Wed, 14 Mar 2018 06:06:32 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Tue, 13 Mar 2018 10:23:17 +1100, Peter Wang <novalazy at gmail.com> wrote:
> > I think we can do without unpacked int64/uint64s.
> 
> Actually, I think it is simpler to treat 64 bit integers the same as
> 64 bit floats on all platforms, including 32 bit ones.
> 
> > > There is another issue here. The existing support for unpacked 64 bit floats
> > > on 32 bit machines has always allocated the next two available words for
> > > any such arguments. This guaranteed that the float field's address would be
> > > a multiple of 4, but did not guarantee that it would be a multiple of 8.
> > > (Cells allocated by boehm are always at an address that is a multiple of 8.)
> > > This works on x86s, but it does NOT work on any of the RISC instruction sets,
> > > which always required primitive type values whose size is 8 bytes to have
> > > an address that is a multiple of 8. (The x86 and x86/64 are almost uniquely lax
> > > in their alignment requirements.)
> > 
> > We don't operate on the float fields directly but extract them into
> > temporary variables with MR_float_from_dword.
> 
> Yes, I know. However, accessing a known-to-be-properly aligned float
> without copying it would be faster.

Right, though I assumed that copying into float registers / the FPU
register stack would be necessary either way, and (somehow) it would all
be equivalent to the C compiler in the end. It seems not, or not always.

> 
> The downside would be that aligning 64 bit floats (and ints and uints)
> on 64 bit boundaries on 32 bit machines may require the compiler
> to insert 32 bits of padding.
> 
> *If* you control the definition of a type whose functors have float arguments,
> and *if* you know about this issue, then you can choose to order the
> arguments of such functors in a way that avoids such padding.
> 
> I see three possible approaches here.
> 
> 1: the status quo. Never insert any padding before 64 bit entities,
> and always refer to them via MR_float_from_word and related macros.
> 
> 2: the speed demon approach: always align 64 bit entities on 64 bit
> boundaries, and refer to them directly, without going through MR_float_from_word.
> 
> 3: the compromise approach: never insert any padding before
> 64 bit entities, but refer to them directly, without MR_float_from_word,
> whenever they *happen* to start on a 64 bit boundary.
> 
> Approach 3 is clearly superior to approach 1, but 2 is simpler to implement,
> though I don't know by how much. I will try to implement 3.
> 

I think approach 3 is fine. Once (if) we have argument reordering
we can make all 64 bit entities aligned to 64 bit boundaries
(unless there is some constraint that I'm not aware of).

> > Mercury (and Prince) were previously confirmed working on 32-bit SPARC
> > after resolving bug #299 in commit 1094f42cc.
> 
> How long ago was that?
> 
> That Mercury has worked on 32 bit SPARC in the past is *far* from surprising,
> given that Mercury *first bootstrapped* on a 32-bit SPARC machine :-),
> after starting development on a 32-bit MIPS machine.

This was AFTER the introduction of double word floats.
git log 1094f42cc says Mon Oct 7 15:03:16 2013

Peter