Re: C++ for Embedded Systems.
peter koch larsen wrote:
kanze skrev:
peter koch larsen wrote:
[concerning EC++...]
I believe I would recommend regular C++ in all but the
tightest environments.
I think most people would. I think that the alterative,
however, is more often C, and not regular C++. Whatever its
flaws, I suspect that EC++ has permitted a lot of applications
to use classes, etc., which otherwise would have been written in
C.
That might well be true. However embedded systems grow all the
time, and I know of systems with several megabytes of memory
(e.g. mobile phones). There it should be reasonable to use C++
which does not have to use that much more memory than C
(especially if you remove iostreams).
Embedded systems can mean many different things. I've worked on
some where the processor was a full fledged Sun Sparc, complete
with disk, and a Meg of main memory, and others where it was an
8059, with only 64 bytes of RAM, and 2K of ROM. Obviously, you
don't need EC++ for the first. You almost certainly won't need
it for a portable phone, either---I think most portable phones
use Symbian as the OS, and that's written in more or less
standard C++.
[snip]
What I'm seeking guidance on is the usage of C++ / STL that
"optimizes for ram/rom size" rather than speed. Sort of like
-Os for STL usage guidelines.
The other common requirement in embedded systems is
determinancy. We need to know, even more than in desktop /
server apps, at design time the worst case behaviour. (Which
to me is an argument for using STL in embedded systems.)
However, a standard C++ gotcha is the time to process an
exception. A style guideline for embedded programmers should
probably highlight that in the appropriate context.
These are the sort of C++ vs Embedded gotchas and guidelines
I'm seeking.
This requires detailed study/analysis of the given compiler.
It depends on the level of detail you want. How to implement
exception handling is generally known, and it has a large cost
in code space. It's also generally accepted that raising an
exception and catching it are fairly expensive operations; if
you're writing a critical hard real-time function that has an
upper limit of 100us execution time, its something you don't
want to do.
Are you sure? 100 us is an awful lot of time today.
Exception handling generally does an awful lot. And embedded
processors aren't necessarily as fast as the machine you have on
your desktop.
I would not expect an exception to take anything approaching
one tenth of that unless there is a huge stack depth.
You've still got a table lookup for each frame. Using linear
search, possibly, because the way the table is built doesn't
allow sorting it for binary search.
Assuming not to many rewinds (destructors to run) I can't see
a problem. But there are (at least) two ways of handling
exceptions (as you can read in the performance report). They
have different performance metrics so far as I understand.
I've not read the report, but I can think of at least three ways
of handling them. With decidedly different time/space
trade-offs each time. One of which will almost certainly result
in less than 100 usec to take the exception, at least on my
machine, BUT which increases the size and execution time for
every function call.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]