[MLton] Operton AMD64

Stephen Weeks MLton@mlton.org
Sun, 2 Jan 2005 21:53:04 -0800


> I ran into the hardcoded -lgmp stuff in main.fun

That's all gone in the CVS.  As discussed, on Linux we now just pass
-lgmp and take whatever that gives us.

> The other problem that stopped me from proceeding onwards to get the
> native compile working was having to get into main.fun to 
...
> 2) adding the ability to pass options to the linker when using native
> compile from what I say was not available.  (you can passed args to gcc
> when C compiling and linking just fine via the compile-mlton script.)

Ah.  Now I understand your question from last week (and why my answer
was inadequate).  I think we used to pass along the -cc-opt stuff to
the gcc-as-assembler calls, but obviously we don't any more.  I guess
we need to add -as-opt.  You should be able to pattern match to add
it.

> The reason I stopped was because there was a lot of action going on
> about then with the 64 sparc hppa stuff and I saw some emails
> regarding cleaning up the gmp stuff.  So I figured to hold off a bit
> till the CVS check dust settled and you guys could get most of the
> work done for me :).

A fine move.  I hope to get back to the C99 stuff this week.

> [ray@gaffer ~]$ uname -a
> Linux gaffer 2.6.9-1.681_FC3smp #1 SMP Thu Nov 18 15:30:11 EST 2004
> x86_64 x86_64 x86_64 GNU/Linux
> [ray@gaffer ~]$ /usr/local/bin/mlton
> MLton MLTONVERSION (built Sun Jan 02 23:29:44 2005 on gaffer)

Great.

> One question is how you would like the developer to specify whether
> they want to do a 32 or 64 bit build to the Makefile(s)?  Symbol
> suggestions?  x86_64-32 vs x86_64-64

Seems fine to me.  I'm open.

> Right now of course the MLton build system determines everything it
> needs by querying host and OS.  However it needs some way to determine
> the 32 vs 64 wishes of the user.  I suppose even after you guys get full
> 64 going, for awhile after that you'll still want the option to create
> 32 bit versions of the compiler.

Probably for quite a while.  64-bit pointers cost a lot of space.  The
plan is to have several different pointer strategies including several
32-bit variants -- see the mail I sent last October.

	http://mlton.org/pipermail/mlton/2004-October/016605.html

The default will almost certainly be one of the 32-bits-with-shifting
variants (machines with more than 8G or 16G will be quite rare).

> P.S Did you know that MLton compiling itself using -codegen c creates
> 208 c files??  Well I suppose you do... 

:-).  There are only 101 assembly files with -codegen native.