[m-dev.] question about 32 bit machines

[Zoltan Somogyi]

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.

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

Any opinions?

Zoltan.