[MLton-devel] Fwd: C back end for MLton

[Stephen Weeks]

> The -m... switches are machine-specific; now that align operatives are
> supported on different architectures, these have been changed to -f...
> directives.  If the -f... versions work on gcc-2.95 (and later), I suggest
> you just change them.  I'm not worried about the warnings myself.

Thanks.  We have changed to -f.

> > I tried changing line 6 of quot.c to
> > 
> > 	register int eax asm("eax");
> > 
> > and recompiled with gcc 2.96 without complaints.  Maybe that would be
> > enough to make gcc 3.3 happy?  Can you try it out and let us know?
> 
> I'll try it; did the previous version bomb on 2.96?

No.

> At some point (3.* ?) gcc became much more careful about inline asms.
> Perhaps you want to build gcc-3.2 (the latest release) and try it.

I just built gcc 3.2 on my machine and used it to recompile the MLton
runtime system without any warnings or errors.  Is it plausible that
something has changed between 3.2 and 3.3 to introduce the error
message?

> The Scheme code has a correctness check in it that the ML code
> doesn't have.  I'm not suggesting the ML code is incorrect, but I
> did not intend to send those benchmark results to this mail list
> until I had verified things.  Perhaps you want to add the same
> correctness check to the ML code just to make us more comfortable.

That would be good.  Could you please mail the scheme code you are
comparing with?  Thanks.

Actually, it occurs to me that it is easier for a quick comparison for
you to delete code than for me to add it.

> Yeah, well on the Alpha, Gambit kicks MLton's butt ;-).  Also, gcc
> optimizations haven't been standing still for the last two years, either.

I completely agree that it would be great to use the C codegen to get
MLton running on more archs.  It's all a question of the project's
priorities.  Hearing your mail is certainly making me think about
that.

As to gcc optimization -- sure, it may have improved.  But, there are
some fundamental limitations to compiling to C and using gcc that will
always make it harder to do as well as a well-written native backend.
On example is the much better aliasing information that our native
backend has.

Getting back to priorities, I would rate it as *much* more important
to port the C codegen to other archs than to squeeze another 10% out
(via command-line switches, computed gotos, whatever ...).  It looks
like we're in agreement there.

> I'd like to know how to play with the options passed to gcc.  

THe easiest way is to edit the bin/mlton script.  The hard way is to
edit mlton/main/main.sml and rebuild the compiler.

> > Suresh also mentioned that you might be interested in running MLton on
> > Alpha's and PowerPCs.  One of our users, Alain Deutsch, has ported the
> > C codegen to run on Sparcs.  I assume it would be comparable amount of
> > effort to port the C codegen to Alpha or PowerPC.  Unfortunately,
> > Alain's work hasn't made been merged in with our CVS due to lack of
> > resources.  If you're interested in pursuing a port, we can get
> > whatever he did to you.
> 
> I'd be interested in this.  Unfortunately, I'd have to learn ML to
> be effective at all.  (I'm a Schemer, I was trying to keep my experiments
> in ML quiet. ;-)

Ve half spice efryver.

Seriously, we can help you out in understanding the compiler sources.
But as of right now, I don't see any of us with the time/funding to
produce a port to Alpha or PowerPC.  I hope that will change someday.


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel