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

"Ian Bell" <ianbell> escribió en el mensaje

Quoted text here. Click to load it


I am sure I could implement it with a simple loop.

;-)

Josep



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

Ian


Site Timeline