[MLton-devel] RE: opus

[Stephen Weeks]

Hey all.  Suresh and I started a discussion about the opus off of the
list, but are now moving it here.  To update you, here were the
previous mails.

> From: "Jagannathan, Suresh" <Suresh.Jagannathan@storagenetworks.com>
> To: <sweeks@acm.org>
> Subject: opus
> Date: Fri, 31 May 2002 13:47:04 -0400
> 
> Hi Steve --
> 
> Now that I'm moving back to academia, I've started thinking
> much more seriously about the opus.  Do you have anything new
> that you'd like to add to the notes (currently in cvs); if not,
> I'll start taking a stab at writing the intro. and putting
> together an outline.
> 
> -- sj


> From: Stephen Weeks <sweeks@sweeks.com>
> To: "Jagannathan, Suresh" <Suresh.Jagannathan@storagenetworks.com>
> Subject: opus
> Date: Fri, 31 May 2002 11:01:33 -0700
> 
> 
> > Now that I'm moving back to academia, I've started thinking
> > much more seriously about the opus.  Do you have anything new
> > that you'd like to add to the notes (currently in cvs); if not,
> > I'll start taking a stab at writing the intro. and putting
> > together an outline.
> 
> Check the CVS.  I made some progress on the intro.  The outline that I
> had in mind was something like
> 
> Intro
> Costs of other compilers (separate compilation, boxing, etc)
> Performance of MLton vs other compilers
> Overview of MLton's passses
> Passes that get to SSA (defunc, mono, closure convert, ...)
> SSA
> SSA optimizations
> Machine IL and backend
> C codegen
> Native codegen
> Runtime
> History
> Conclusion

> From: "Jagannathan, Suresh" <Suresh.Jagannathan@storagenetworks.com>
> To: "Stephen Weeks" <sweeks@sweeks.com>
> Subject: RE: opus
> Date: Fri, 31 May 2002 15:31:57 -0400
> 
> I've updated the opus directory, and will work on reviewing the
> intro.  What examples did you have in mind in explaining the 
> costs section?  I'm not sure having a separate section highlighting
> the problems with other compilers is necessarily useful, although
> a section that describes a couple of ways of writing a program and
> having the same output produced would be nice; this is what Richard
> did in presenting his transformational compiler work in POPL.  Do you
> want to move this discussion to MLton?
> 
> -- sj

And here's the continuation of the discussion.

> What examples did you have in mind in explaining the costs section?

I want to make very clear and convincing proof of the claims that I
made in the intro about the costs of traditional SML compilation
techniques.  Examples that show the costs of boxing, loss of control
flow info, separate compilation, moving code across module
boundaries.  I don't think most people understand how costly other
compilers are.

> I'm not sure having a separate section highlighting the problems
> with other compilers is necessarily useful,

I disagree.  Maybe you will see my point once you see how I wrote the
intro. 

> although a section that describes a couple of ways of writing a
> program and having the same output produced would be nice; this is
> what Richard did in presenting his transformational compiler work in
> POPL.

Agreed.  That's what I think we can do in the section right after the
intro.  We can show how other compilers make you pay depending on the
style, but MLton generates identical code.

> Do you want to move this discussion to MLton?

Yes.

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel