[Top][All Lists]

[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: Philip Levis
Subject: Re: [Tinyos-devel] RE: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4
Date: Tue, 16 Oct 2007 16:54:30 -0700

On Oct 16, 2007, at 1:38 PM, Eric Weddington wrote:

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.

Come on, Eric, you could at least read the few pages before sounding off. The point of the chapter isn't that nesC provides namespaces in the C++ sense (it doesn't). Rather, by separating the naming scopes of callers and callees, it allows callbacks to be statically defined without requiring either side to know about the relationship. This prevents the need for function pointers, reduces RAM use, improves robustness, and allows cross-call optimization. It also makes system composition easier. Furthermore, compile-time functions enable precise RAM provisioning and full state encapsulation through function parameters nesC can insert at compile-time. Finally, nesC automatically detects data races by explicitly understanding the difference between main() and interrupt contexts.

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.

I'm happy to learn why switching to C, C++, or Ada might not have the limitations I think it does. All I'd ask before starting such a discussion, though, is that you actually take a close look at nesC so you understand the benefits it provides and why people might choose to use it.


reply via email to

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