[Tinyos-devel] ti msp430 cc

[Stephen Dawson-Haggerty]

I assume the things you mentioned go for pretty much any compiler; does
anyone have an idea of how much we're leaving on the table by using
msp430-gcc and avr-gcc, in terms of code size?  For a couple percent it
might not be worth the effort right now, but 10% or so starts to sound
pretty good.

Thanks,
Steve

On Thu, Nov 13, 2008 at 10:07 AM, David Gay <dgay42 at gmail.com> wrote:

> On Thu, Nov 13, 2008 at 9:48 AM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
> wrote:
> >> 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)
> >
> > Let's say that my main target would be SDCC for 8051. What things should
> I
> > change in nesc to get a app.c that compiles correctly? :-)
>
> Support for SDCC's C extensions in nesC. You would need to look those
> up to figure out more in detail how to handle them... Options
> essentially include:
>
> - avoiding the extensions
> - using the preprocessor to remap them to something nesC understands,
> then unremapping them as a post-pass (a variation avoids the first
> remap step, and just has you writing something nesC understands and
> mapping that to the extension after nesc1 runs)
> - extending nesC's C frontend-part to at least parse, preserve and
> unparse the extension (you get extra credit for checking that it's
> used correctly...)
> - in the last two cases, if you want the extension to work in modules
> (and generic modules) you need to make sure that renaming symbols
> doesn't cause problems with how you handled the extension...
> - anything involving #pragma is likely to be a pain... (not so much
> understanding it, but putting it somewhere rational in the C code
> generated by nesC)
>
> And, FWIW, the more hacky the handling, the less likely I am to
> include it in the nesC distribution itself (though that's also a
> function of how cleanly separated the hacks are - a hacky script is
> fine, some hacky changes to C type checking probably aren't)
>
> David
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20081113/2ad22f1c/attachment-0001.htm