I intend to participate in Google's Summer of Code this year, so I'd
like to bounce some ideas around to see what you guys think. Here they
are, in no particular order:
1. Implement nesC support. nesC (which stands for "Networked Embedded
Systems C") is a dialect of the C language. It is used heavily in the
embedded operating system TinyOS. The problem is that the current nesC
compiler is just a wrapper around gcc, operating similarly to Cfront for
C++ by turning nesC code into C code that gcc can compile. With Clang,
we have an opportunity to do better. I don't know if you want me to
integrate this, but I'm throwing this out there anyway. If you don't,
I'll probably pursue this as a separate project, writing wrappers around
Clang's libraries.
2. Modularize C++ ABI support. This is something that I think we need to
do eventually--especially if we want to support other C++ ABIs, like the
Microsoft ABI (which is the de facto standard on Windows; and I can
envision uses for Wine... :). Right now, though, Clang (like GCC) is
hardcoded to generate code for the Itanium/GNU ABI. I won't actually
implement a second ABI; I'll just abstract the current Itanium ABI away
into its own class(es); then later we can have other C++ ABIs.
1. Implement nesC support. nesC (which stands for "Networked Embedded
Systems C") is a dialect of the C language.
The problem is that one of the main TinyOS targets, AVR, has no LLVM backend. The other main target, MSP430, has a backend that is slowly becoming useful but doesn't quite work yet.
Maybe an AVR backend would be a better project?
Also, I'm not convinced that compiling via C is a problem for nesC. For some languages, there is substantial lost efficiency, but most of nesC is syntactically and semantically identical to C so there's little or no impedance mismatch.
1. Implement nesC support. nesC (which stands for "Networked Embedded
Systems C") is a dialect of the C language.
The problem is that one of the main TinyOS targets, AVR, has no LLVM
backend. The other main target, MSP430, has a backend that is slowly
becoming useful but doesn't quite work yet.
Maybe an AVR backend would be a better project?
Maybe. Only one problem. I don't have any AVR chips to test with, only
some MSP430s.
Maybe I should work on the MSP430 backend instead.
Also, I'm not convinced that compiling via C is a problem for nesC. For
some languages, there is substantial lost efficiency, but most of nesC
is syntactically and semantically identical to C so there's little or no
impedance mismatch.
Yes, but we still have to invoke two processes for every nesC program:
one to compile nesC -> C and one to compile C -> machine code. (I admit,
it's not as bad with nesC because all the sources in the program are
always taken together.)
Also, there are other tools like mig (not to be confused with a tool by
the same name needed to build the XNU kernel) and nesdoc that operate on
nesC code. It might be worthwhile to rewrite them, too, to be clang-based.
Once this backend is functionally correct (enough), there will be a lot of tweaking and tuning to do. This would be a lot of fun, I think. I'm convinced that with not too much added work, LLVM can be as a good an embedded compiler as the solid commercial ones such as IAR.
Also, there are other tools like mig (not to be confused with a tool by
the same name needed to build the XNU kernel) and nesdoc that operate on
nesC code. It might be worthwhile to rewrite them, too, to be clang-based.
Just MHO, but this sounds like a lot of work for minimal benefit.