[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] recommendation for coding convention on state variables

[Joe Polastre]

Oh, and just so you know, these are the changes that had to be made
for Code Composer, and even after this we still had to hand-tweak the
app.c to get it to compile in CC:

_asm doesn't work for Code Composer.   Affects all TOSH_*_PIN()
macros.  Use CC asm instead.

remove all lines starting with #

long long is non standard (change to just 'long')

remove all register definitions

replace all '__atributed ((packed))'

remove debug enums

change all enums to #define

replace all $ with ___

remove all 'static' keywords

remove all 'inline' keywords

remove 'volatile' keywords

On 10/13/05, Joe Polastre <joe at polastre.com> wrote:
> > - use __attribute__((packed)). Our code now becomes gcc-specific (ok,
> > we could use a macro and #ifdef to avoid that, but see next solution
> > too)
> > - use -fshort-enums when compiling. The RAM savings are now
> > gcc-specific. There's also a potential problem when linking with
> > libraries using enums inside structs, but I doubt we have any of
> > those.
>
> These two are a moot point, because if you've ever tried compiling
> TinyOS code on another compiler, you'll find it is hacky and
> practically impossible.
>
> Case in point, take an app.c and try to compile it with TI's Code
> Composer.  The amount of "gcc-isms" in the TinyOS code totally kills
> you.  Although it would be really nice to use Code Composer since it
> produces more compact code than gcc and includes Eclipse plugins...
>
> It does bring up a good point though--how committed are we to allowing
> other compilers other than gcc?  I'm sure the folks working on 8051
> and the CC2430 would be interested in the answer to this...
>
> -Joe
>

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg