Alastair Reid writes:

One way of tackling it would be to change ghc so that compilation doesn't produce .o files containing machine code but, rather, files containing a concise encoding of STG code.

Yes, one could indeed do that. We've discussed various schemes like this in the past, and the bottom line is usually that it's a good idea but hasn't so far been compelling enough to warrant the effort it would take to implement. I will comment on one particular thing though:

This case ought to be easier because STG code has already had a very powerful optimizer applied to it so all that's left is doing a good job with register allocation and pipelining.

There's a lot more to do to get from STG code to fast machine code than just register allocation and pipelining. Even if we consider generating machine code from the intermediate C to be "just register allocation and pipelining", GHC does an awful lot of work to get from STG to C. The bytecode generator does a much more simplistic transformation from STG to bytecodes, but it loses many opportunities for optimisation in the process. So if one were to do something like this, the crucial decision is at what level to target the intermediate code. Something that can be directly interpreted *and* compiled to fast machine code (JITted?) would seem to be a good idea (Julian Seward was very keen on this). That would be at a level somewhat lower than STG, though. Cheers, Simon