inside the GHC code generator

[Jean-Philippe Bernardy]

Hello Bulat,

>From my (limited) knowledge of GHC backend, the difficult part of your
plan is that STG is not suited to compilation to native C at all. You
might need to do quite advanced translation from STG to another
intemediate language, (as GRIN for example), and then some more
advanced analysis/optimization before C can be generated.

iirc, the tricky part is the handling of lazyness. At any point you
may end up with a thunk (closure), which ghc handles easily by
"evaluating" it: it's always a function pointer. (That's the tagless
part) When in WHNF, it just calls a very simple function that fills
registers with the evaluated data. Otherwise, the function call
performs the reduction to WHNF.

If you want to use the same trick, you'll end up with the same
problems (bad C). So, you'll want to eliminate thunks statically,
finally requiring a 'high level' analysis as I suggested above.

Also, allocation + garbage collection is extremely efficient in
current GHC... C/C++ alloc doesn't even come close. It's entirely
possible that with even a very fast backend, the better ghc allocator
will be enough to swing the balance. (see jhc)
It might be possible to re-use most of it however.

I certainly don't want to discourage you (we all want faster code :),
but there is no easy path to climb the mountain ;)

Cheers,
JP.