[m-dev.] question about 32 bit machines

[Peter Wang]

On Tue, 13 Mar 2018 05:49:02 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> At the moment, an argument in a memory cell representing a term
> will occupy two words in exactly one case:
> 
> - a 32 bit machine
> - with 64 bit floats (i.e. floats are not single precision)
> - in a non-pregen grade
> - and a function symbol argument whose type is explicitly given as float.
> 
> On 32 bit machines,
> 
> - we box all 64 bit entities (both floats and int64/uint64s) *everywhere*
>   in pregen grades;
> - we box all 64 bit entities *everywhere* where the statically known type
>   is a type variable; and
> - we box all int64s and uint64s everywhere regardless of anything else.
> 
> The only exception from boxing is the one given above.
> 
> The different treatment of int64/uint64s from floats is just because
> we haven't implemented their unpacked representation yet. However, I have
> a question: should we have unpacked 64 bit arguments on 32 bit systems at all?
> Given the relative rarity of 32 bit systems *and* the relative rarity of code
> that not only uses floats, int64s or uint64s but also spends a significant fraction
> of its runtime on operations on them, I am wondering whether a policy of
> "always box 64 bit primitive values into 32 bit words on 32 bit systems when
> putting them into a structure" would be good enough. It would certainly
> simplify the relevant parts of the compiler.
> 

I think we can do without unpacked int64/uint64s.

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

Mercury (and Prince) were previously confirmed working on 32-bit SPARC
after resolving bug #299 in commit 1094f42cc.

Peter