On May 28, 2008, at 9:48 AM, Vitaliy wrote:
>> he rhetoric here is that it can be very easy in C++ to use a  
>> construct that has a very high performance impact without it being  
>> at all obvious
>
> Bill, do you have experience with C++ on PICs? It seems to me that  
> the dsPICs and the new PIC32s have enough umph to make the tradeoff  
> worthwhile...

Actually, this is the rhetoric used to try (not entirely  
successfully) to keep C++ code out of cisco's IOS operating system  
running on high-end MIPS, PPC, and 68K CPUs, and I'm generally on the  
"no C++" side of the argument.

I was going to say that those have quite a bit more umph than even a  
PIC32, but I'm not so sure.  (Yeah, the clock rate is probably 10 to  
20x the PIC32, but there are a lot of threads SHARING that, and some  
of the worry is that the unnoticed impact will be especially bad in  
that shared environment.)

On the third hand, I think I'd argue that part of what makes a  
program "embedded" is that it's not a good idea to have resource  
consumption hidden by ANY languages, OS, or whatever...  (for  
instance, Arduino has a serial library that uses the HW uart, but it  
STILL takes 1ms/byte for transmit (at 9600bps) since there's no  
buffering on the transmit side.  I've seen that bite a couple of  
people now.)

I've almost convinced myself that I understand the value of C++ and  
similar languages in high-end GUI OS environments; they do a much  
better job of hiding data structure internals than traditional  
languages.  I'm still not sure I understand the point of C++ in small  
embedded systems (although I sorta like function overloading.)

BillW

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist