C++ in embedded systems

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi.

I have followed some discussions about C++ deployment in embedded
systems and I learned there are several criticism on C++ itself and
its deployment in such systems. Someone mentioned he designs using OOD
but implements in C and Assembly, which would be my approach as well
(maybe because I started as hardware designer and tend to consider
hardware limitations when designing software :-) ). I work with people
that have software engineering formation though and they tend to use
every resource of C++ without concerns with performance in the
embedded realm, leaving eventual optimizations to the end of the
design which we know it's much more difficult and neither practical
nore echonomicaly wise. I don't think these folks would go back to C
even using OOD techniques so I'd like to get the best possible from
C++ advantages and avoid its drawbacks. I would appreciate if you
could comment on this and give hints on what to avoid when programming
for embedded systems in C++. Suggestions of books and links will be
very much appreciated as well.

Thank you in advance for your help.

Elder.

Re: C++ in embedded systems
Quoted text here. Click to load it

My personal (and possibly controversial) view is that OOD is a complete
waste of time in general and absolutely useless for embedded systems.
there a many reasons why I hold this view but some of them are:

1.  Objects bear no relationship to actual objects
2.  Information hiding and the other OO so called 'attributes' are
counterproductive to embedded development where the intimate connection
between the hardware and the software must never be diluted.

Ian


Re: C++ in embedded systems
Hi,

I don't want to polemicate here, but saying that OOD is a complete waste of
time is false.

Bad or misunderstanding of OO drive project to the wall.  Ok.
Good and well implemented OO Design save time, and let your project be very
very more maintenable.

But you have to master it...

Bye.

StepH.

"Ian Bell" <ianbell> wrote in message
Quoted text here. Click to load it



Re: C++ in embedded systems
*** Evil topposting fixed ***

Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Kindly do not toppost.

All absolute statements are false.  What is polemicate?  Maybe
something to do with polecats?  Something Dubya said?  

There may be a language barrier, and if so I apologize for any
unintended offense.  The phrase just struck me as amusing.  All
versions of polemic, (polemics, polemist) known to me are nouns,
not verbs.

After which I shall waffle and emphatically state the ambiguous
polemic that OO in embedded systems is _usually_ a waste of time.
In PICs, certainty appears.  Otherwise cavil.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems


Quoted text here. Click to load it

In the sense that it is saying something controversial, it causes a
stink...  So yes, it has to do with polecats.


--
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems
Quoted text here. Click to load it

Of course I seriously mis-spoke in the above.  The problem is not
OO, but the implementations, such as C++ or Java.  The OO metaphor
itself can be gainfully applied to any language, including
assembly and PICs.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems
snip

Quoted text here. Click to load it

This is the crux of the matter and the key word is gainfully.  My view
is that the OO metaphor/paradigm (PYO buzzword) does not of itself
provide any gains in the development of embedded systems.  It is not
proven that it is better in this context than other design methodology.

Ian



Re: C++ in embedded systems

<about hashlib module>
: However there are the equivalent of constructors and destructors,
: both for complete hash tables and for items to be stored, and
: operations to be performed on them.  But there is no C++ bloat (it
: is written in C) and no known re-entrancy problems.

What C++ bloat?

An implementation with the same features done with
C++ is likely to be smaller and faster than a C implementation,
because 'void *' is not used which causes aliasing problem and prevents
some optimizations. C99 has the 'restrict' keyword these days though..:
http://www.lysator.liu.se/c/restrict.html

Also inlining hashing and especially equality comparasion code in C++
implementation likely increases performance and even might reduce size.
We'll see what happens..

I'm in the process of writing an implementation using interfaces and
inheritance for hash- and equality comparaision function pointers
instead. Comparing C implementation  template-based implementation
isn't probably fair, but that would make even more difference.

The difference between C++ and C implementation isn't going to be very
high with a reasoable hash function since it probably dominates,
but I guess the difference could be tested by a hash function that runs
in a short constant time. Although in C++ implementation returning 0 as
a hash value results in the compiler probably detecting it and
elimination of few statements, so that's not a very good comparasion
either.. I'll try to figure something out.

I'll compile your code and my code using gcc 3.3.1 cross compilers for
AVR and H8. Any preference which models?

This will probably take few days since it has been a while I have been
programming C++, and I have to make myself more familiar with your test
code of hashlib.c so that I can verify my implementation.

Re: C++ in embedded systems
Quoted text here. Click to load it

The hash function is external in hashlib.  It belongs to the data
itself, since what is a good function depends on the data makeup.
Similarly the equivalent of constructors and destructors for the
items to be stored.  The provided string hashing functions are
purely for convenience, because strings are probably the most
prevalent data keys.

Quoted text here. Click to load it

It should all compile out of the box.  Supposedly it is in pure
portable standard C.  The tests depend on the Mersenne Twister
(for portable repeatability) which in turn is not guaranteed
without a 32 bit unsigned long.  hashlib.h has a __cplusplus
guard, so it should link to a C++ system immediately.

"splint -weak hashlib.c" generates no warnings.  I consider the
warnings without -weak spurious, but they might be significant for
anyone modifying the code.

Under this system the hashlib module is less than 0x700 bytes of
code.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems

: The hash function is external in hashlib.  It belongs to the data
: itself, since what is a good function depends on the data makeup.

Naturally. Using function ptr for hashing and cmp'ing two elements
is the probably the way of creating a data structure that doesn't
care what data is stored there (void *).

BTW the C++ implementation done by using your code was at
least smaller on H8 and AVR, performance I couldn't test:

C++:

h8300-hms-gcc -Os -fomit-frame-pointer -ms -c ClosedHash.cpp
h8300-hms-objdump --disassemble ClosedHash.o tells there's 0x55a bytes
of code

C:
 
h8300-hms-gcc -Os -fomit-frame-pointer -ms -c hashlib.c
h8300-hms-objdump --disassemble hashlib.o tells there's 0x5b0 bytes of
code

The difference isn't that large though (C version is ~6% larger).
So much for the 'bloat' - care to explain what did you mean with it?

Looking at the source, one might be able to squeeze few bytes out by
some refactoring of the code.

I'll make a 'report' with more details and make it and the
sources available, when I have some time and I have tested
my implementation (we'll, yours) against the test suite.

Re: C++ in embedded systems

: However there are the equivalent of constructors and destructors,
: both for complete hash tables and for items to be stored, and
: operations to be performed on them.  But there is no C++ bloat (it
: is written in C) and no known re-entrancy problems.

What do you mean by 'C++ bloat'?

It is not impossible that a C++ implementation of the same interface and
algorithm might be less object code and/or faster. I'll report the
results when done.. basically I'm using your implementation, but using
the tools that C++ provides.

I'll report when done.. I was thinking of using gcc 3.3.1 and AVR and H8
targets.



Re: C++ in embedded systems

: However there are the equivalent of constructors and destructors,
: both for complete hash tables and for items to be stored, and
: operations to be performed on them.  But there is no C++ bloat (it
: is written in C) and no known re-entrancy problems.

What do you mean by 'C++ bloat'?

It is not impossible that a C++ implementation of the same interface and
algorithm might be less object code and/or faster. Basically I'm using y
our implementation, but using the tools that C++ provides.

I'll report when done.. I was thinking of using gcc 3.3.1 and AVR and H8
targets.



Re: C++ in embedded systems
Quoted text here. Click to load it

You may well be right.  A C++ implementation would effectively
eliminate the 'master' parameter to all the methods, and
auto-supply it via 'this'.  It would still need the hshdupefn and
hshfreefn constructor/destructors passed in, or some form of
reference to the actual data type to be managed.  Once you do this
I suspect that item access would involve further constructions
(dupes) etc., except for the hshdelete operation (which removes
the item from management, and returns it to the control of the
user).

In C I have a fine control over all this.  It will be interesting
to see what C++ can do. Unless it has significant extra security
or efficiency I see no point to it, since C++ can use the module
directly.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Possibly because I am MUCH less facile in C++ than in C.  It seems
easy to generate ungodly amounts of convoluted code with very few
lines in C++.

The hashlib tests exposed the failings of free in several systems,
which used O(n) time where n is the number of memory blocks in
play.  Some of the tests exercise this by eliminating the final
hshkill call.  This induced me to write a malloc package with O(1)
free performance, which is DJGPP specific, but will probably port
to many Linux systems under GCC.  Also available on my site.  How,
if at all, this will bite on C++ systems I do not know.  I suspect
it will.  The problems will appear when something upward of 50k
items have been stored, and will be obvious sooner on slow
machines.  The end effect is that hashkill is O(N*N) where N is
the count of items stored, and becomes O(N) with my nmalloc
package.

I would be interested to know if runtests (on Linux/Unix) or
runtests.bat (on Windoze/DJGPP) function on your system.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems

Quoted text here. Click to load it

Including that one?

Ian


Re: C++ in embedded systems
Quoted text here. Click to load it

Yes.  No absolute statements are true.

:-)

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems
Quoted text here. Click to load it

We seem to have rediscovered recursion.

Ian


Re: C++ in embedded systems

Quoted text here. Click to load it

Hehe.  No, it just means that absolute claims are meaningless,
not false or true.

Jon


Re: C++ in embedded systems
Quoted text here. Click to load it
You are entitled to your opinion as am I.

Ian


Re: C++ in embedded systems
Quoted text here. Click to load it

In embedded systems, pretty nearly any view is controversial, because
the field covers such a wide variety of needs and capabilities.

I'll give you two instances in a current 32-bit project of mine where
OOD is useful:

1. Network interfaces. When I was working on the first version of this
project, our hardware had one wired Ethernet interface. I chose to
implement the network functions and variables as a set of "methods"
and variables encapsulated in a network I/F "class". Soon after
release, we started to work on units with dual Ethernet, and units
with a mix of 1,2 or 4 Ethernet ports and 0, 1 or 2 wireless Ethernet
ports.

There are two places where this has saved me effort:

a) Startup code. Instead of having to call disparate functions to
bring up the interfaces and load configurations, I simply call the
load-config and bring-up methods of each object.

b) UI code. I wrote a single piece of UI code to edit network
interface configuration. It's easier for me to call the same function
with different config pointers than it is to craft slightly different
functions for the same net result.

2. GUI
The GUI is encapsulated in a "GDI" object, which contains methods to
identify if the environment is compatible with the GDI's code, and
various display parameters, as well as primitives for line draw,
flood-fill, various simple shapes, image scaling and rotation, text
rendering, and other functionality. So far, we've written two
substantially different GDIs optimized for different types of
framebuffers. I'm looking at a third GDI that will use OpenGL.

In both cases, I believe that the thought and planning that went into
encapsulating the relevant data and functions were an enormous help in
keeping platform-specific code isolated from platform-dependent code.
We're looking at porting down to an ARM or XScale design (from x86) in
the near future, and in this world every day of development time
counts. I don't believe there is any significant overhead; one extra
32-bit pointer on the stack is about it.

At its simplest, OO implementation can just be deciding to put
everything in a struct and passing a pointer to that struct to every
function that needs it (equivalent of C++'s "this") rather than
declaring a bevy of global variables.

Site Timeline