Re: C++ for Embedded Systems.
{ in the heat of an argument please don't forget quoting guidelines,
like not quoting the signatures or parts irrelevant to your reply.
thanks. -mod }
kanze skrev:
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++.
Right. I believe multi-megabyte embedded processors are quite common in
embedded system - if they control something more advanced than a
toaster.
[snip]
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.
Somewhere from the back of my head (not that far back looking at the
date!) came some stuff regarding exceptionhandling in a kernel. A quick
google gave http://netlab.ru.is/exception/LinuxCXX.shtml
Quoting:
The implementation of the C++ ABI is based on the implementation
provided with the source of the GNU g++ compiler. We modified it to run
in kernel space, and performed optimizations that reduces the cost of
exceptions and dynamic cast considerably. Our paper contains thorough
explanations of these optimizations. The cost of throwing an exception
one level on a 990 MHz Intel Pentium is around 12-13 micro seconds in
the plain GNU g++ implementation, which we reduced to 2.1 micro seconds
by modifying the runtime library, including unwinding the stack in one
phase, and caching information on exception paths. In contrast the cost
of a trivial printk operation -- printk("Error\n") -- is 18 micro
seconds.
(end quote)
So 10 us is realistic - but only just.
/Peter
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! ]