C for embedded controllers

Bruce Bowling bowling at cebaf.gov
Mon Dec 11 17:08:21 GMT 1995


~ 
~ >Virtual functions appear to be an additional layer
~ >to debug through, since addresses are determined at runtime and
~ >can change depending on the inheritance of an object.
~ 
~ 
~ As to the "additional layer", it's largely invisible during debugging.
~ If I step a machine instruction at a time across a call to a virtual function,
~ watching the current high-level source line, the debugger makes a brief detour
~ to the last line in the file (I assume this indicates a point in the code
~ for which the compiler indicated no valid source line), then goes to the
~ first line of the virtual function.  It's effortless.
~ 
~ 
~ If I may be so bold, I see this belief as a relic from K & R.  I feel
~ that the weak typing of (non-ANSI) C is nice for the ((new || old) &&
~ (sloppy || lazy)) programmer who wants to pass an argument when it's too
~ bothersome to figure out how to properly typecast it. I have never been
~ prevented by C++ from doing anything I wanted to do.  Explicitness makes
~ for fewer misunderstandings over time.
~ 

I guess I got "bad blood" from using C++, mainly because of the requirements
of the project.  My bad experience came from using C++ on a non-embedded
project, one that should not have been (in my mind) so difficult, but
caused endless grief until I realized what was going on...

The "project" was an electron accelerator simulation which consisted of several
processes (running on a HP workstation under HPUX) which communicated
using shared-memory.  The idea was to create the objects (which were
several thousand 2-dimensional matrices with associated virtual
functions - each matrix+functions a separate object) in shared memory and
let each concurrent process use the functions.  However, it turns out
that the first process who created the shared-memory objects initialized
the virtual function pointers to its "space" of execution and the other
processes who accessed the virtual functions were trying to access
an address outside of its scope.  This caused me loads of pain on
a project which was already behind because of my learning curve with
C++.

HPUX does not have thread capabilities (the OS version I was using), and
other communication methods like pipes, sockets, etc, were inefficient
with the size of the data (over 70 meg).  The solution to the problem
was to make the objects in shared-memory a sub-class to new objects
which contained the virtual functions (taking them out of the shared-
memory classes) and pointers to the object in shared-memory.  This
worked, but I lost the benefits of encapsulation of data/functions
in one single object.  Each processes has to set up the pointers
to shared-memory themselves, and data accesses are via. the pointers
to shared memory which killed performance slightly.  The program 
also had to worry about shared-memory/object alignment to prevent
access errors.

I guess the point here is that I had to know what the compiler/OS
was doing with the code, and find a work-around, so the whole
notion of just writing code and letting the compiler worry
about the details can lead to trouble.  Hence the "lazy" or
"inexperienced" reference I stated before.

This is a unique problem, which probably would not show up on
an embedded system where one has access to the entire scope
of memory.  However, the experience has reinforced in my mind that
one should use the proper tools for the job.  I was required
to use C++ on this project to make the simulation more
"high-tech"/"state-of-the-art"/etc......


- Bruce

--
-----------------------------------------------------
<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------------------------------------------------
               Bruce A. Bowling
  Staff Scientist - Instrumentation and Controls
 The Continuous Electron Beam Accelerator Facility
    12000 Jefferson Ave - Newport News, VA 23602
                 (804) 249-7240
                bowling at cebaf.gov  
        http://devserve.cebaf.gov/~bowling
-----------------------------------------------------
<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------------------------------------------------



More information about the Diy_efi mailing list