C vs C++ in Embedded Systems?

"Mayank Kaushik" <prehistorictoad2k@yahoo.com> wrote in message
news:1106971631.452027.91840@z14g2000cwz.googlegroups.com...
>
> Bob wrote:
> >Is it just me, or does the email address
> >"prehistoric toad 2k" sound like a troll?
> >
> > Bob
>
> Troll yourself, mister :-X
>

It was just a question. I guess it *is* just me...

Many others in the ng seem willing to take you on face value:
1) you were an undergrad (in august 04) asking about what courses to take to
prepare for MS in embedded.
2) you flirted with a 89c51 in december
3) you are now porting linux to a custom (not 3rd party or eval) PCB with a
very powerfull processor (AT91RM9200 200 MIPS ARM with "16K-byte instruction
and 16K-byte data cache memories, 16K bytes of SRAM, 128K bytes of ROM,
External Bus Interface featuring SDRAM, Burst Flash and Static Memory
Controllers, USB Device and Host Interfaces, Ethernet 10/100 Base T MAC,
Power Management Controller...") that only comes in  256 BGA or a 208 PQFP
packages.

I find this sequence a bit difficult to believe, that's all. I'm impressed,
if it's true. How much support are you getting from Dehli College of
Engineering? Is the school making the prototype PCB for you (including the
reflow)?

Bob

On Sat, 29 Jan 2005 18:12:10 GMT, Ed Beroset <beroset@mindspring.com>
wrote:

[...]
>
>int numerator = 35323;
>int denominator = 1038;
>int answer = numerator / denominator;
>
>On an 8-bit micro with no native divide instruction, this can generate 
>quite a bit of code even though there was no obvious library call. 

As well as the wrong answer.  Or at least, not the answer that was
probably intended...

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

"Mayank Kaushik" <prehistorictoad2k@yahoo.com> wrote in message
news:1106972357.942219.68660@c13g2000cwb.googlegroups.com...
> Hi everyone,
>
> Well, i suppose all that everyone said about C++ stands from an
> "application development" point of view...but what benefits would C++
> deliver if used for something more hardware-oriented, like, say, device
> drivers?
>
> And wheres the guy who talked about trolls :-O
>
> regards
> Mayank
>

I apologize. I shouldn't have implied that you were trolling.

Bob

Steve at fivetrees wrote:
> "Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> wrote in message
> news:41fd8809$1_1@news.bluewin.ch...
[snip]
>>> I see this justification a lot, and in conventional sequential code
>>> it makes sense. However, anytime I run into these issues I wrap the
>>> throw scope in a state machine, and put the error check in *one*
>>> obvious place.
>>
>> Do you mean that it makes no sense to throw exceptions in state
>> machines? If so, why?
>
> I mean that if the error source and the error handler can be tightly
> bound (for instance by turning a sequence into a loop decoding a
> state machine), then there simply is no need to use exceptions.

I don't see what this has to do with the argument whether exceptions 
make sense in state machines or not. I guess I don't understand what you 
say here.

The need for exceptions arises from the fact that most non-trivial 
functions do their "work" by calling other functions what typically 
results in deeply nested call trees. Moreover, the function that wants 
to report a problem is very often separated by several levels from the 
function that actually has a chance to remedy the problem.

>>> The overhead of "explicit error checks everywhere"
>>> doesn't apply. I don' need no steenking exceptions ;).
>>
>> Why are state machines different? An action could very well make a
>> deeply nested call, or could it not? So, it makes sense to use
>> exceptions there.
>
> Same answer, really. If the deeply-nested call can return a failure
> code to the state machine, again there's no need for exceptions. (I

*If* it can, but why should it? If a call in an action results in lets 
say 10 other calls, as follows:

A transition action calls a(), a() calls b(), b() calls c(), c() calls 
d(), ... j() calls k()

and k() wants to report a problem that can only be remedied by a()'s 
caller then why should one not use exceptions?

> generally find I have to do this anyway, since the state machine
> needs to know what to do next...)

As an aside, if the error cannot even be handled inside the transition 
action then the transition action would want to report the problem to 
the state machine. With almost all the FSM frameworks I know one would 
need to do that by posting an error event and then returniung normally 
from the action. I find this rather cumbersome because the state machine 
could easily automate this. But that's really beside the point, what 
matters is that exceptions help you to propagate errors from k() to the 
transition action.

Regards,

-- 
Andreas Huber

When replying by private email, please remove the words spam and trap
from the address shown in the header. 

Jonathan Kirwan wrote:
> 
> Actually, it is Jonath(a)n

Ah. Sorry about that. The eyes aren't what they used to be, and the 
fingers run ahead of the brain from time to time.

> I like to test myself and see if I can produce, by hand, the same assembly code
> from a small function I write.  In C, I can almost always do that for any CPU
> I'm familiar with and for any C compiler I'm faced with, within a reasonable
> range of "closeness."  I'm quite facile with that ability and can translate, for
> example, a great range of C functions into x86 assembly as fast as I can write
> it without missing a beat.  When I taught university level computer architecture
> and assembly programming classes, I'd often demonstrate this facility in front
> of the class, letting them pick the C code (which they learned in an earlier
> year there) and having me move to the 2nd chalk board and write it out as the
> Microsoft C compiler would produce it.  I would do this as fast as I could
> write.  And I hit it exactly.  Made a nice demonstration.

I've had occasion to do something similar, although not in a teaching 
context - just in helping a co-worker develop and debug a code generator 
for a compiler.

> It was in trying to do this for C++ that I ran into serious trouble regarding my
> own abilities here.  I quickly learned just how many seemingly innocuous
> snippets of C++ code would trip me up.  As I learned to deal with those, I kept
> finding still new ones.  And so it went.  I soon learned just how much more
> difficult it was and, in that realization, I learned some very great respect for
> C++ and probably some very great dread and fear, as well.
> 
> To use C++ well and wisely in the kind of embedded systems I discussed then, one
> must have a kind of trembling respect for it and to spend time studying it and
> understanding it before putting one's hand out to actually work with it.  C++ is
> much like a tiger, in that way.  If you are ignorant, you could as quickly lose
> your hand as keep it.

I may have a little too much fear of C++ ... most of what I've done in 
the past several years has been in various assembly languages or in a 
proprietary BASIC, with some C thrown into the mix. It's hard not to 
feel the fear, though, when you run across this sort of quote:

If you think C++ is not overly complicated, just what is a protected 
abstract virtual base pure virtual private destructor, and when was the 
last time you needed one?
                 -- Tom Cargil, C++ Journal.

All those words are English, but the way they're strung together gives 
me pause. I'm not certain I've EVER needed one of whatever those are.

-- 
wheels

On Mon, 31 Jan 2005 13:31:41 -0700, "Steven R. Wheeler"
<swheeler843@earthlink.net> wrote:

>> It was in trying to do this for C++ that I ran into serious trouble regarding my
>> own abilities here.  I quickly learned just how many seemingly innocuous
>> snippets of C++ code would trip me up.  As I learned to deal with those, I kept
>> finding still new ones.  And so it went.  I soon learned just how much more
>> difficult it was and, in that realization, I learned some very great respect for
>> C++ and probably some very great dread and fear, as well.
>> 
>> To use C++ well and wisely in the kind of embedded systems I discussed then, one
>> must have a kind of trembling respect for it and to spend time studying it and
>> understanding it before putting one's hand out to actually work with it.  C++ is
>> much like a tiger, in that way.  If you are ignorant, you could as quickly lose
>> your hand as keep it.
>
>I may have a little too much fear of C++ ... most of what I've done in 
>the past several years has been in various assembly languages or in a 
>proprietary BASIC, with some C thrown into the mix. It's hard not to 
>feel the fear, though, when you run across this sort of quote:
>
>  If you think C++ is not overly complicated, just what is a protected 
>  abstract virtual base pure virtual private destructor, and when was
>  the last time you needed one?
>                 -- Tom Cargil, C++ Journal.
>
>All those words are English, but the way they're strung together gives 
>me pause. I'm not certain I've EVER needed one of whatever those are.

Hehe.  Actually, it's not all that complex.  But I can see the point.

I can make a similar one for C, expressed this way.  What exactly does this
denote, in C?

  char* (*f (char*(*p)(const char *, char *)))(const char *, char *);

It's dead simple, in concept.  But the syntax takes a little 'getting used to.'
Which is the point.  I think you'd get to know what Tom meant, as you became
very familiar with C++.  And the underlying concept isn't nearly so hard, once
you get past the syntax used to describe it.

Despite all this, though.  There are real reasons and good justifications for
treating C++ in embedded systems with a great deal of respect and perhaps some
trepidation.  I think using it well imposes a higher standard of expertise on
the programmer.  It's a language for the more skilled among us.

Jon

Steven R. Wheeler wrote:

>I may have a little too much fear of C++ ... most of what I've done in 
>the past several years has been in various assembly languages or in a 
>proprietary BASIC, with some C thrown into the mix. It's hard not to 
>feel the fear, though, when you run across this sort of quote:
>
>If you think C++ is not overly complicated, just what is a protected 
>abstract virtual base pure virtual private destructor, and when was the 
>last time you needed one?
>                 -- Tom Cargil, C++ Journal.
>
>All those words are English, but the way they're strung together gives 
>me pause. I'm not certain I've EVER needed one of whatever those are.

When is the last time you had a memory leak in BASIC?  <grin>


 "C++'s much greater abstraction capabilities permit 
 the programmer to hide grungy details.  Like where
 the bugs are."                        -Dave Hansen

On 2005-01-31, Jonathan Kirwan <jkirwan@easystreet.com> wrote:

> Despite all this, though.  There are real reasons and good
> justifications for treating C++ in embedded systems with a
> great deal of respect and perhaps some trepidation.  I think
> using it well imposes a higher standard of expertise on the
> programmer.  It's a language for the more skilled among us.

Which seems to me to illustrate a the fundamental problem with
C++.  The higher level the language, the _less_ skill and
expertise should be required of the programmer.  Writing
Assembly code should require less expertise than writing
machine code. Writing C code should require less expertise than
Assembly.  Writing in an higher level language (OO or not)
should require _less_ expertise than C, not more.  I think
that's true for most high level languages: Modula-3, Ada,
Scheme, Python, Smalltalk, etc.  

The fact that writing C++ is more difficult and requires more
expertise than writing in a lower level language means
something went seriously wrong in the design of C++.  The
purpose of a language is to make it easier to program, not more
difficult.

-- 
Grant Edwards                   grante             Yow!  I'm working under
                                  at               the direct orders of WAYNE
                               visi.com            NEWTON to deport consenting
                                                   adults!

On Mon, 31 Jan 2005 21:04:57 +1100, Andrew Reilly
<andrew-newspost@areilly.bpc-users.org> wrote:


>> In order to be able to move the dynamic objects, the object can not be
>> accessed directly through pointers. Each object must be accessed with
>> a handle, that is used to index a pointer table to get the final
>> address. 
>
>No, that's much too strong a requirement.  The real requirement is that
>the garbage collection system be able to find every pointer that it needs
>to relocate, so that it can be changed to follow the allocation.  Double
>indirection through handles is one obvious way to do that, but simply
>ensuring that all pointer variables actually point to allocated memory. 
>That's a natural consequence of the "safe" languages that I mentioned, and
>so those languages get to use normal, one-way pointers, even to memory
>objects that can be moved when needed. It's a requirement that can't be
>ensured with C or C++.

Unfortunately, you seem to have missed my point. I was not discussing
the problem of garbage collection (if a programmer does not know when
to delete an object, that programmer should not be hired), but rather
the problem of dynamic memory squeezing to allow a sufficient amount
of contiguous memory.
 
Using some ad-hoc method in which the code is disassembled to find out
all memory references would not be acceptable due to the memory size
and CPU power limitation, not to mention some rare cases, in which
there might be some innocent looking bit patterns that could be
misinterpreted. In an ad-hoc system, you might be able to achieve
99.999 % reliability,  but in many systems, this is simply not enough.
I have written several assemblers, linkers and disassemblers and
relying on heuristics and other ad-hoc methods will sooner or later
cause a catastrophe. You must have a formally sound method to describe
the environment. 

Paul

On 31 Jan 2005 21:35:18 GMT, Grant Edwards <grante@visi.com> wrote:

>On 2005-01-31, Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>
>> Despite all this, though.  There are real reasons and good
>> justifications for treating C++ in embedded systems with a
>> great deal of respect and perhaps some trepidation.  I think
>> using it well imposes a higher standard of expertise on the
>> programmer.  It's a language for the more skilled among us.
>
>Which seems to me to illustrate a the fundamental problem with
>C++.  The higher level the language, the _less_ skill and
>expertise should be required of the programmer.  Writing
>Assembly code should require less expertise than writing
>machine code. Writing C code should require less expertise than
>Assembly.  Writing in an higher level language (OO or not)
>should require _less_ expertise than C, not more.  I think
>that's true for most high level languages: Modula-3, Ada,
>Scheme, Python, Smalltalk, etc.  
>
>The fact that writing C++ is more difficult and requires more
>expertise than writing in a lower level language means
>something went seriously wrong in the design of C++.  The
>purpose of a language is to make it easier to program, not more
>difficult.

I meant my comments, though, in the very narrow situation of using C++ for
critical embedded applications of the nature I mentioned in my earlier post,
years back.

In the case of less critical systems, a great many programmers can use
Microsoft's MFC, for example, in order to handle window messaging and use the
supplied simplifying tools to modify the directing structures without really
understanding the details.  It's blindly done, I suppose.  But if one stays in
the mainstream, most problems can still be avoided, even by relatively ignorant
programmers.

Same thing is true for VB or Delphi, I suppose.  Excellent tools for quick
prototyping, for example (not meant to exclude other meaningful uses.)  There's
a lot that can be done with well-vetted higher level support.  But then, I'd not
be trying to use these tools for the kind of critical embedded applications to
which I meant my comments to be directed.

...

However, between C++ and VB/Delphi, C++ still requires a fair degree of skill.
I kind of imagine C++ as a emeritus programmer's programming language.  Often, a
very dangerous tool in neophyte hands and, yet, an incredibly powerful tool for
those nearer the pinnacle of the profession.  One needs to have learned from
experience what works well over time and how to rule themselves with a
disciplinary iron fist.  And that just takes time.

Jon