[MLton] x86_64 port status

[Matthew Fluet]

> On Tue, 2006-05-09 at 16:31 -0700, Stephen Weeks wrote:
>>> Perhaps a better approach would be to define the following:
>>>
>>>    struct PointerAux { unsigned char[4]; } __attribute__ ((aligned (4));
>>>    typedef struct PointerAux* Pointer;
>>
>> I tried this out and it worked well.  To be clear, I used
>>
>>   struct PointerAux { unsigned char z[4]; } __attribute__ ((aligned (4)));
>
> But this only works for gcc! Please use a union to align
> data, it's portable to all compilers and architectures.

I ask again: Union with what?

You asked in your reply to Vesa: what is purpose of 'Pointer'?
It's purpose is to denote pointers to ML objects in the ML heap, which 
were allocated by the MLton codegen.  We can't guarante anything more than 
what the codegens guarantee: namely that the pointed-to object is 4-byte 
aligned (no more and no less).

I don't believe that you can express this constraint without requiring 
compiler specific annotations.  (And, we're well wedded to gcc in any 
case.)  Something like:

union X {
         unsigned long i;
         unsigned char a[
                 sizeof long> sizeof(void*)?
                 sizeof long :
                 sizeof (void*)
         ];
         void *p;
};

doesn't work.  As everyone is quick to point out, C doesn't guarantee 
anything about the alignment of long or void*, other than that it is 
dictated by the underlying architecture. So, this might well guarantee 
that the union aligns for long and void*, but says absolutely nothing 
about whether or not it is 4-byte aligned.  (On an x86, it is 1-byte 
aligned.  Given the warnings that Stephen saw, I suspect that it is 4-byte 
aligned on a sparc in 32-bit mode.  I could easily imagine that on a 
64-bit platform, that void* is 8-byte aligned.)