[Tinyos-devel] ti msp430 cc

[David Gay]

2008/11/12 Razvan Musaloiu-E. <razvanm at cs.jhu.edu>:
> Hi!
>
> On Tue, 11 Nov 2008, Geoffrey Werner-Allen wrote:
>
>> Hi Martin, Steve:
>>
>> We had heard at Sensys'08 that someone had written a script to strip the
>> GCC-specific stuff out of the nesc output C code so that it could be fed
>> through another compiler.
>
> The only thing that I'm aware of that does this it the mangleAppC.pl from
> the tinyos-2.x for 8051. The script can be retrieve using the following svn
> checkout command:
>        svn co
> svn://svn.tinyos8051wg.net/repos/tinyos-2.x-contrib/trunk/diku/mcs51/support/make/mcs51
> Note: in the same directory there are two big .exe file, one of 2MB and
> another one of 6MB, so the download will take a little time.
>
> Martin Leopold can say more about how feasible is to use this for MSP430.
> From my point of view this is a wrong direction. The right one would be to
> do change nesc to generate ANSI C code. :-)

To the best of my knowledge, it does generate ISO C99 code. AFAIK,
there's five issues with non-gcc compilers (the $ doesn't count any
more, just use -fnesc-separator=__):
- Does the compiler support inline? If it doesn't, then you'll have
performance problems (this is an issue for the 8051 compilers)
- Do you want to use it for tossm with a compiler that doesn't follow
ISO C99? (the initializers for module variables with tossim use the
new '(type) { initializers }' syntax)
  [inline and these initializers are the only uses of non-ANSI/ISO C90
features in actual code generation]
- Do you want ncc/nescc to behave like gcc and convert options to your
compiler's driver, or do you want a ncc/nescc replacement that behaves
more like your compiler's driver? (both require a little but not that
much work)
- Is TinyOS using some C syntax your compiler doesn't support? (this
is an issue for TinyOS, AFAIK it''s not a major problem)
- Does your C compiler come with its own C extensions that you need
nesC to support? (this can be necessary because of header files or
because you need those extensions in the code you want to write - this
was the major issue for 8051 compilers which have lots of C extensions
to deal with the 8051 architecture)

So, figure out the answers to those questions, and give it a try...
And if you want to make any changes to nesC to address any of these
I'm happy to incorporate patches, or even better have you maintain the
other compiler's nesC support (to be frank, this was always the major
issue with 8051 support)

David