[MLton-devel] Re: [MLton-user] Some numbers on SML/NJ & MLton runs and also a few questions

[Stephen Weeks]

> I'm trying to get some MLton runs on a SPARC, and deal with this
> problem relating to the illegal -mno-epilogue flag.
> 
> Your suggestions were:
>     > 1. Recompile MLton, taking out the bad switch.  It should be easy to
>     > find in main.sml.
...
> I started down path #1. But having read up on cross-compilation, it looks
> pretty hairy, in that I have to install a mess of gcc cross-comp tools, 
> with which I have no experience.

Yeah, cross compilation is hairy.  You don't absolutely need it in
this case though.  You could do a self compile on SPARC using the
existing buggy 20030716 -- tweak the line in main.sml, compile with
-stop g, and then make the calls to gcc by hand.  But that's getting
messy too.

> Could I ask one of you guys to build a SPARC rpm or tgz or just executable
> with the bogus flag excised? This would be a fine thing to put on your web
> page for people other than myself, as well...

Sure.  I will put one up later this week.  In the meantime, there is a
simple workaround.  Since you can choose the C compiler that MLton
calls by editing the /usr/local/bin/mlton script, you can replace gcc
with a wrapper that eliminates the -mno-epilogue and then calls gcc.
Here's an ML script that does what's needed.

----------------------------------------------------------------------
(* wrap-gcc.sml *)
val name = "gcc"
val args = List.filter (fn s => s <> "-mno-epilogue") (CommandLine.arguments ())
val _ = Posix.Process.execp (name, name :: args)
----------------------------------------------------------------------

Of course, since you don't have a working ML compiler for SPARC, you
need the executable as well.  I put it at
http://www.mlton.org/experimental/wrap-gcc.  Or you could write
wrap-gcc in another language.

Anyways, if you put wrap-gcc somewhere in your path and change line 8
of /usr/local/bin/mlton to

	gcc='wrap-gcc'

Then hopefully you can run OK with MLton 20030716.

> BTW, an update on my code measurements. The reason the side-effecting sort
> timings were so fast (1000x) is that I had a bug in the timer code for
> those runs.

Makes sense.  I thought the 1000x was a bit large, and had been
meaning to run some tests of my own to see what was up.



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel