avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Tinyos-devel] RE: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-


From: Eric Weddington
Subject: RE: [Tinyos-devel] RE: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4
Date: Tue, 16 Oct 2007 14:38:42 -0600


> -----Original Message-----
> From: Philip Levis [mailto:address@hidden
> Sent: Monday, October 15, 2007 4:12 PM
> To: John Regehr
> Cc: Eric Weddington; 'David Gay'; 'Eric Gnoske'; 'Avr List
> Server'; 'TinyOS Development'; address@hidden
> Subject: Re: [Tinyos-devel] RE: [avr-gcc-list] Fwd:
> [Tinyos-help] TinyOs avr-gcc-4
>
>
> Right -- nesC is a superset of C. If people wanted to, they
> can write
> a huge application as a bunch of C files which are #included into a
> single nesC component, and add some shims for downcalls/upcalls.
> People mostly don't, though, for a bunch of good reasons...

... And they are? Do you have links?

> IIRC, the reason we haven't moved to avr-gcc v4 has to do with its
> interpretation of optimization parameters. Kevin looked a bit into
> this and found that -Os leads to huge code bloat, but that -O3 leads
> to similar results as is observed with -Os in 3.2/3.4. There was
> definitely talk of moving to avr-gcc 4 for the 2.1 release. But
> making this change requires more than compiling and seeing if code
> size is different; as far as we know, there might be weird compiler
> bug edge cases that nesC tends to tickle. So it would require a lot
> of testing.

Fair enough and agreed.

> But I think that now might be a good time to get
> our feet
> wet. New Atmega MCUs are going to push this more and more as time
> moves forward.

I can guarantee it.

> Eric -- with respect to why it's not just a matter of changing to C,
> I suggest you take a look at the chapter of the TinyOS programming
> manual entitled "Namespaces." It's only about 10 pages of double-
> spaced text, so isn't a long read. It explains the fundamental
> limitations of C and why its namespace model fundamentally makes
> efficient composition difficult. TinyOS is, in part, an exploration
> of how modern (read, post-1970s) language and OS techniques can
> improve the robustness, maintenance, extensibility, and performance
> of embedded codes.

I find it difficult to believe that namespaces alone is an issue. We're
talking about applications that fit roughly onto an ATmega128 (128K code
space). We have customers who have C applications that fit into 256K of code
space with no problems. There are not tens of thousands of functions, with
thousands of modules, in these types of applications where having namespaces
is a requirement to get the job done. For that matter, if namespaces are
such a big deal, then AVR GCC has a C++ compiler available, and it's a
standardized language that many working programmers know.

If one is interested in improving the robustness, maintenance, and
extensibility then I would also suggest looking into the AVR GCC Ada
compiler, again a standardized language.

I just fail to see how anyone intends to capture engineering mindshare for
the NesC language beyond academic interest. Which means that TinyOS will
always be relegated to such a sphere as well.

Eric Weddington






reply via email to

[Prev in Thread] Current Thread [Next in Thread]