Re: exception handling poll

[Joel Sherrill <joel at OARcorp dot com>]

On Fri, 17 Oct 1997, Robin Kirkham wrote:

> I'll second that: sometimes it is 0. On-chip memory size on embedded micros
> doesn't seem to be growing at the same relative rate as workstations. And
> since the parts count matters so much these days, engineers are reluctant
> to give you any off-chip memory, especially if it is because of the compiler
> tools you are using! (And they will serve you with that apocryphal tale about
> the object-oriented toaster, again).

I'll second this.  Even though I tend to work on higher end applications
embedded applications, it is still not uncommon to have only 1 Mb RAM.
This is a serious issue for the GNU tools in general -- not just gcc.

> This is, of course, a wider issue than just the compiler, and applies to the
> libraries as well. For instance, many people write one C++ class definition
> per source file, so the linker is forced to load object code for the entire
> class, even if you only use--implictly or explicitly--a couple of methods.
> Convenient for the class writer, but not for the poor sod who must go through
> and split it up into smaller modules, just so she of he can fit it in the
> target hardware.

There is a lot of programmer effort required to solve this problem by
splitting files.  Right now, RTEMS even suffers from having "classes" in
the same file.  We know about this and recognize that by splitting the
files we could reduce the footprint of applications.  However, it is a
serious investment in time to do this.  It has not made the top of the
list.

Similarly every application in every GNU language suffers from the same
problem.  

The best solution to this long term is for ld to be smart enough to leave
out unreferenced functions.  If the work is invested there, then instantly
EVERY application and library would benefit in size.  

> My point is that while executable speed performance and programming features
> like exception handling are obviously important to egcs and the libraries,
> don't forget the folks in the less glamourous, embedded end of town.

Another issue is stack space usage.  I have not mentioned this example in
a long time but in glibc 1.0[89], there was a floating point print routine
which used 40K of stack space!!!  This is OK on a workstation but totally
inappropriate in an embedded system.

Similarly, it is a nice optimization to be able to have certain tasks in a
multitasking system be integer only.  This avoids saving restoring the FP
context when the application designer knows that a particular task does
not use the FPU.  Since many CPUs let you disable the FPU in the status
registers, the OS can enforce this.  But the rub is that you must link
against libraries which use FP.  I have run into 2 CPU families so far
where it is possible to do this optimization but in practice you can't --
the PA and the PPC.

The PA uses the FPU to do integer division or multiply (I can't rememebr
the exact scenario).  So even though the applicaiton never explicitly does
FP operations, you still may be doing them.

The PPC problem is probably more difficult to address.  The code generate
for vfprintf saves an FP regsiter in the prolog because of the path for FP
numbers.  So even if you do not print an FP number, you still end up
touching the FPU.

Just some more embedded systems issues to think about. :)

--joel