Summer of Code ideas

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Summer of Code ideas

Charles Davis-3
Hi,

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.

Chip
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Summer of Code ideas

John Regehr
> 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.

John Regehr
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Summer of Code ideas

Charles Davis-3
On 3/22/10 6:46 PM, John Regehr wrote:
>> 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.

Chip

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Summer of Code ideas

John Regehr
> Maybe. Only one problem. I don't have any AVR chips to test with, only
> some MSP430s.

If you were to work on this I would happily send you a pile of AVR-based
TinyOS nodes.

But really, an AVR simulator would be a lot easier to start with and there
are several good free ones.

> Maybe I should work on the MSP430 backend instead.

Anton Korobeynikov is the author of this backend, and is its main hacker.
This search will give you a good idea of the current status:

http://llvm.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&content=msp430&product=&query_format=specific&order=bug_id&query_based_on=

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.

John
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Summer of Code ideas

John Myers
In reply to this post by Charles Davis-3

> 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.

Their are a few of us working on an AVR backend. So you wouldn't have to start from scratch
and we could definitely use the help.

http://sourceforge.net/projects/avr-llvm/ 


~~John


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Summer of Code ideas

John Regehr
> Their are a few of us working on an AVR backend. So you wouldn't have to
> start from scratch
> and we could definitely use the help.
>
> http://sourceforge.net/projects/avr-llvm/

Cool!  I somehow had missed this.

One of my students is helping Anton shake out some MSP430 problems and
could help with AVR as well.  Let me know and I'll put you in contact with
him.

John Regehr
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev