[MLton] [iI]sBigEndian necessary?

[Wesley W. Terpstra]

I've been looking at all the places where [iI]sBigEndian shows up.
I've been finding occurances with:
find -type f -print0 | xargs -0 grep sBigEndian | less

The only time this ever appears to affect the control flow is:
./basis-library/integer/pack-word32.sml:   if isBigEndian = Primitive.MLton.Platform.Arch.isBigEndian
./basis-library/real/pack-real.sml:   if isBigEndian = Primitive.MLton.Platform.Arch.isBigEndian
./mlton/backend/rssa.fun:   if not (Control.targetIsBigEndian ())

All the other occurances are binding it and/or rebinding it to names also
matched by my regexp.

The first two comparisons make no sense to me at all.
The thing on the right hand side is a function, but the left is a bool.

The second test is in a function called Rssa.byteOffset which is used by
./mlton/backend/packed-representation.fun in exactly one place.

Is this knowledge of the endian-ness really required?
It's a bit complicated for mips where it can be either big or little.

I might be being a bit niave, but as long as there's no native code
generator, why should endian ever matter? Unless you're planning on doing
	int x = 4;
	char* c = (char*)&x;
	char d = *c;
... in which case you will burn in hell anyways.

If you want access to bit offsets in an 'uint32 x' or whatever in the C
codegen, doesn't 'x >> 5' work no matter what the endian?

The other issue, alignment, makes me scratch my head.

In C, we have 'offsetof' in stddef.h which can be used to portably detect
a 'good' alignment for a given type (except for function pointers):
#define ALIGNOF(type) offsetof (struct { char c; type member; }, member)
So much for gc.{ch} -- they can use this.

However, scattered throughout the mlton compiler code are references to
alignment and I get lost here. Since alignment depends on the object stored,
how is it that a single constant align := Align4/Align8 works?

For instance, on i386 alignment = 4 is wrong for SSE2 values (must be 16).
On amd64, alignment = 4/8 would be way overkill for a short.

I'm having trouble deciding what I should fill in to mlton/main/main.fun.

-- 
Wesley W. Terpstra