This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC 3.0 Open Issues List feedback


On Apr  8, 2001, dewar@gnat.com wrote:

> <<'bounded performance' in this context implies that no destructors need
> to be called, which is vanishingly rare in C++ code; I don't know about
> Ada.
>>> 

> Certainly not vanishingly rare in realtime code where remember that it is
> often a rule that there is no dynamic allocation at runtime in any case.

> And as a programmer you know exactly what will need to be destructed, so
> this can be taken into account when worrying about critical deadline paths
> in a real time program.

Err...  In hard real-time systems, you generally have to know more
about the call graph than in non-real-time systems.  I.e., you should
generally know which functions call other functions, so you could, in
principle, tell how long it would take to find all registers that have
to be restored in a throw.  But I agree it could be harder to compute
the maximum time required for this computation, than to simply account
for the time of a longjmp.  But then, you have to take into account
the extra time of all setjmp()s, and this is far from being
negligible.  As deadlines get stricter, you'd probably be better off
using a lower-overall-overhead exception handling mechanism.  On
machines with lots of call-saved registers, the performance of
setjmp/longjmp EH is awful, and so is its stack usage.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]