Re: [C--] C-- development

On 03/15/2013 01:30 AM, Simon Peyton-Jones wrote:
> |  > We don't use qc--; rather there's a Cmm -> native code compiler in GHC.  And,
> |  in fact a Cmm -> LLVM generator that then uses LLVM as a back end.
> |  Will GHC benefit from separating Cmm -> LLVM/native code generator out
> |  as a standalone backend?
> |
> |  The Cmm backend can be built and tested independently from GHC
> |  front-end, and it can also be used by other functional languages.
>
> It'd be possible.  Indeed GHC as-is can and does compile .cmm files. It needs to do so to compile parts of the runtime system.  But (a) as earlier discussed, this s GHC's variant of C--, and really is more biased to compiling for the spineless tagless G-machine.   (b) we have not invested a lot of love in the .cmm -> native code path, so the error messages are probably bad, the type checker (GHC's Cmm is typed) is likely not great.  Etc.
>
> It would be an interesting, but non-trivial, task to make it more generally useful.   I'd be happy if someone wanted to take it on.
It cannot compete with LLVM for generality anyway.  I don't see there is 
a need to make it more general.  I'm now a believer of Haskell, if it 
can help Haskell to be more successful, it's worth to give it a try.

But the way, I haven't actually looked at Cmm code.  Without much 
knowledge about the code and what the existing problems are, I can only 
speculate the standalone backend will make the following improvements:

- easier to test and maintain
- easier to upgrade LLVM
- attract more functional language front-ends, like JHC, or other 
haskell like languages

I would love to hear if the standalone backend can make other improvements.

Ning



_______________________________________________
Cminusminus mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/cminusminus