|
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 aresuch 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 willalways 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.
Phil
[Prev in Thread] | Current Thread | [Next in Thread] |