Hi all,
I'm sorry for this late reply - I have been traveling.
Tommy> The GRIN Project: A Highly Optimising Back End for Lazy
Tommy> Functional Languages
I think John Hughes' summary of my work on GRIN was quite accurate,
except for one thing; he was a bit overly optimistic on how large
programs I had compiled. My implementation could handle programs up to
around a thousand lines of Haskell. After that it ran out of memory
doing register allocation (one of the most important parts of GRIN was
to do interprocedural register allocation, and in the initial version
program-wide graph colouring, hence the dependence on program size).
There were two main reasons for the register allocator to fail. First,
I implemented graph coloring in a purely functional way, in Haskell,
and that turned out to be extremely inefficient. Second, I never got
around to implement the chapter of my thesis that deals with how the
register allocation should be done on really large programs, basically
going from program-wide graph coloring to coloring regions of the
program based on the procedure call graph. Both of these should be
possible to fix.
The whole-program analysis (a kind of points-to analysis) that we used
was no problem at all when it came to running times, it seems to
scale really well to larger programs.
And, as John said, I got some really impressive speedups compared to
hbc/ghc, so I definitely believe that this way of compiling Haskell
would be worth pursuing further.
However, even if you fixed the register allocator it would be a lot of
hard and tedious work to turn my implementation into something that
could be practically useful. For one thing, it is only a compiler
back-end, so you would need to connect it to some Haskell front-end. I
used an experimental Haskell front-end by Lennart Augustsson, but there
were some problems with that. Using ghc as a front-end might be a
better choice today.
Tommy> 2) is the software available?
If you're still interested given the above just contact me privately. :-)
Regards,
-- Urban
