[m-dev.] 32-bit sources on 64-bit target
novalazy at gmail.com
Thu Mar 7 12:17:20 AEDT 2013
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
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
- a long string of enum arguments might require fewer words on 64-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.
PS. I'd still like to see generated C sources for 64-bit...
More information about the developers