On Sun, 12 Sep 2004 00:02:58 GMT, llewelly wrote:
> fpilhofe@mc.com (Frank Pilhofer) writes:
> > One figure that was quoted was that gcc-compiled code was three times
> > as big when exceptions were enabled.

I think it's important to note that this figure likely referred to the size
of the executable, which means that not just code size was being measured,
but also the size of the static data included with that code.

> For some platforms, they did. gcc has two different exception
>     handling implementations - one is called setjmp-longjmp, and the
>     other is called dwarf2-eh or table-driven. setjmp-longjmp has the
>     advantage of being much easier to port to new platforms, but the
>     disadvantage of substantial performance and code size
>     penalties. The alternative dwarf2-eh has almost no performance or
>     code-size penalties, and only light data size penalties.

What can you tell me about the data size penalty?  I'm glad you mentioned
it, because my experience has been that most people who discuss the cost of
the table approach assume that the size of the tables isn't a
consideration.  For hosted systems, this is probably true.  For embedded
systems, it is probably true less frequently.

> The trouble is that the truth is somewhere in the middle - the
>     technology for implementing exceptions cheaply has been known for
>     almost a decade (if not longer), but it is more difficult to
>     implement, and switching to it breaks backwards compatibility(0). So
>     the technology is out there, but it isn't implemented
>     everywhere. There are widely used compilers - such as MS VC++
>     2003, I believe - which have quite expensive implementations of
>     exception-handling, and others which have quite cheap
>     implementations.

Cheap by what measure?  Code size?  Static data size?  Runtime speed in the
unexceptional case?  Runtime speed in the exceptional case?  I don't know
of any approach that is "cheap" by all these measures.  Also, does anybody
have a sense for how big the code for manipulating the shadow stack
compares to the size of the code for manipulating the tables?  I have no
idea, but I'm curious.

Scott


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]