[MLton-devel] teaching a compiler course using MLton
Suresh Jagannathan
suresh@cs.purdue.edu
Thu, 19 Sep 2002 14:51:27 -0500
This is a first-year graduate course. I suspect this will be the
first significant compiler class for most students. I like your
idea for (1); maybe a reasonable compromise would be to use
the functional variant of Appel's Tiger as the source language.
Students would have access to code for lexing and parsing such
a language, and could refer to the book for ideas on compiling its
various constructs.
It would require writing some translation passes from a simplified IL to
MLton's, and figuring out how to merge MLton's implementation with
the description given in the book. The fact that Fun-Tiger is fairly
close to ML helps in the first case; I don't have a good sense of how
to explain MLton's compiler strategy in the context of a text like
Appel's; maybe we just don't and treat MLton as tool rather than as
an open compiler students examine.
On Thursday 19 September 2002 12:29 pm, Stephen Weeks wrote:
> > I'd rather not have students directly mimic MLton's compilation
> > strategy since I think it's sufficiently different/complex to make
> > it infeasible for a first-year grad. course. Instead, I've been
> > thinking of a project along more classical lines:
> >
> > -- convert source to CPS (A-normal form)
> > -- implement 0CFA
> > -- flow-directed inlining, uncurrying
> > -- closure conversion
> > -- simple first-order optimizations -- loop-invariance, common
> > subexpression, useless argument, ...
> > -- code generation
>
> It looks to me like the major difference from MLton's strategy is that
> you put flow-directed inlining before closure conversion. I suspect
> that is harder than putting it after (as MLton does).
>
> > The idea here is that we use the MLton backend for code generation;
>
> I think it would be cooler to have MLton more tightly integrated than
> just as a backend. Here are a couple of ways I see to do this.
>
> 1. At the end of each pass, have the students target one of MLton's
> ILs, or some suitably sanitized version that you write a translator
> for. This way they can test correctess and real performance impact at
> each pass.
>
> 2. Focus on adding a language feature (e.g. laziness) and pushing it
> all the way through the real compiler. This way, students can see a
> lot, and what they do will have immediate, realistic impact. Then
> look at how various SSA optimizations affect performance. They can
> write a real optimization that affects real programs.
>
> My worry is that if you just do what you propose, there is a lot of
> overhead for the students in learning how to work with MLton without a
> lot of payoff.
>
> Will most of the students already have had one compiler course? If
> not, then (1) seems better. If so, then (2) seems better -- there is
> no need to have the students implement all the steps of compilation in
> detail. It would probably be more instructive and fun to work on a
> real compiler.
>
> Note, I am not saying that (2) should have any research component at
> all.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> MLton-devel mailing list
> MLton-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlton-devel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel