[MLton] Porting MLton... C99?

Wesley W. Terpstra terpstra@gkec.tu-darmstadt.de
Fri, 10 Dec 2004 03:49:34 +0100


So... porting MLton to other archs.
Instead of ppc, I've been aiming for ia64 because the build is faster. ;)

There's a couple things I've run into.

First, all of the float-stuff like rounding mode and class are included
portably in C99. It seems to me reasonable to make MLton C99 and use the
portable C99 methods. That's what I did for ia64 and it seems good.
(man fpclassify, fesetround, fegetround)

The main problem is ... gc.{ch}.
This stuff just doesn't work on a 64bit machine.
Here, pointers = 64 bit, long = 64 bit, long long = 64 bit, int = 32 bit.
The secret gcc _uint128 also exists, but we won't be using that. ;)

Why did you guys put pointers in ints?
And why did you define unsigned long as W32?

To bring you up to speed on a few things about 'portable' C casts: never
cast a pointer to an int. long will fit a pointer on every platform I know.
Most 64bit platforms have 32bit int and 64bit pointers.

Anyways, if we use C99, there's the wonderful header stdint.h which defines
uint32_t, uint64_t, etc. Also provided is intptr_t -- the smallest/fastest
int which fits a pointer, and ptrdiff_t for (a-b) pointer expressions.

All those printf("%08x", (uint)ptr); lines scattered everywhere are also a
problem. The best way to do this is to change it to printf("%08lx",
(ulong)z), no matter what type z is. When using uintX_t you have no idea
what that corresponds to in a format string so upgrading to the largest
portable formatted type is the best approach.

... anyways, I have modified so much of gc.{ch} at this point that I'm sure
I've broken it and I should start with CVS (I was working against 20041109).
So, I am going to start over, use <stdint.h>, and upgrade everything to C99.
Then I will systematicly walk through gc.{ch} and change the types one at a
time. Once I have it working again on linux+i386 with corrected types and
portable float methods, I'll try ia64 again.

Is there any reason NOT to use C99?
gcc supports it quite well, and gcc is much more portable than MLton. ;)
This would eliminate all the arch-dependent runtime code I have run into.

If we used these C99 methods, MLton would probably 'just work' on all the
architectures where gcc works. The operating system dependent calls would
still need special casing, but we'd get all the linux archs at a minimum.

Another C99 bonus is the 'restrict' keyword, which, in my experience, can
radically improve array accesses. This might mean faster GC. Oh, 'inline' 
is a proper keyword in C99 too.

-- 
Wesley W. Terpstra