[m-dev.] question about 32 bit machines

[Zoltan Somogyi]

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.

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.

> 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.

Zoltan.