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

[Philip Levis]

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.

Phil