[m-dev.] 32-bit sources on 64-bit target

[Peter Wang]

Hi,

The pregenerated compiler sources are made for a 32-bit target but could
be used on a 64-bit system because, even though each word is twice as big,
the representation of a functor would be equivalent on 32- and 64-bit
systems, in that the slot number of each argument would be the same,
and the total cell size would be the same number of words.  Of course,
we force --num-tag-bits=2 and --no-unboxed-float on 64-bit.

Last year, I made two changes which broke this (that I am aware of):

  - storing double-precision `float' constructor arguments across two
    words on 32-bit

  - packing as many consecutive enum arguments as will fit into a single
    word

The pregenerated C sources for the standard library will contain code
assuming those 32-bit data representations.  However, the user program
on a 64-bit system would lay out the same data structures differently:

  - double-precision `float' constructor arguments can fit in a single
    64-bit word

  - a long string of enum arguments might require fewer words on 64-bit
    than 32-bit

So there will be problems whenever a data structure with those
characteristics crosses the standard library/user program boundary.

I think I can fix the first by allocating two words to a `float'
constructor argument whenever --no-unboxed-float is used, even when it
is unnecessary on 64-bit.

The second, I'm guessing, does not actually occur in the standard
library.  A solution would be to restrict enum packing to using at
most 32 bits of a word, with an option like --max-arg-packing-bits=32.

If you can think of other issues then please let me know.

Peter

PS. I'd still like to see generated C sources for 64-bit...