Re: exception handling poll

Re: exception handling poll

[meissner]

| 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.

No, it is not a problem on the PPC at all.  The PPC ships different versions of
the libraries, based on endianess, whether floating point is done in hardware
or emulated, and whether you use the old sort-of AIX based calling sequence or
the newer eabi.  So, if you use the gcc driver, and add the -msoft-float option
when linking, you will get libraries that do not use the floating point
instructions.  This is true of many of our ports.

Re: exception handling poll

[Joel Sherrill]

On Fri, 17 Oct 1997 meissner@cygnus.com wrote:

> | 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.
> 
> No, it is not a problem on the PPC at all.  The PPC ships different versions of
> the libraries, based on endianess, whether floating point is done in hardware
> or emulated, and whether you use the old sort-of AIX based calling sequence or
> the newer eabi.  So, if you use the gcc driver, and add the -msoft-float option
> when linking, you will get libraries that do not use the floating point
> instructions.  This is true of many of our ports.

This would work if NONE of the application used floating point.  But this
is a case where there are multiple tasks/threads running and you want to
specify on an individual basis whether a particular thread uses FP.  The
application must be linked with the HW FP math library. 

Does the distinction make sense?  

--joel

Re: exception handling poll

[David Edelsohn]

>>>>> Joel Sherrill writes:

Joel> This would work if NONE of the application used floating point.  But this
Joel> is a case where there are multiple tasks/threads running and you want to
Joel> specify on an individual basis whether a particular thread uses FP.  The
Joel> application must be linked with the HW FP math library. 

Joel> Does the distinction make sense?  

	I guess that I do not understand why you cannot have two versions
of the libraries and link with the appropriate library whether you want to
utilize hardware FP or not.  If you link with the appropriate HW FP math
library, why cannot all libraries be treated similarly?

David

Re: exception handling poll

[Joel Sherrill]

On Fri, 17 Oct 1997, David Edelsohn wrote:

> >>>>> Joel Sherrill writes:
> 
> Joel> This would work if NONE of the application used floating point.  But this
> Joel> is a case where there are multiple tasks/threads running and you want to
> Joel> specify on an individual basis whether a particular thread uses FP.  The
> Joel> application must be linked with the HW FP math library. 
> 
> Joel> Does the distinction make sense?  
> 
> 	I guess that I do not understand why you cannot have two versions
> of the libraries and link with the appropriate library whether you want to
> utilize hardware FP or not.  If you link with the appropriate HW FP math
> library, why cannot all libraries be treated similarly?

Because for tasks which specify that they do not use the FPU, we would
like to be able to disable the FP via the MSR.  This insures that a task
which does not have a FP context never touches the FPU.  If it uses the
FPU, then a fault is generated.  This scheme actually works well on the
sparc. 

The entire application is a single linked image. There is no virtual
memory or separate address spaces.  You either have the HW or software FP
routines in the application -- not both.

This type of thing is common in embedded RTOS' since it is an obvious way
to speed context switch time.

--joel

Re: exception handling poll

[Richard Henderson]

On Fri, Oct 17, 1997 at 12:43:32PM -0500, Joel Sherrill wrote:
> > | 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.

Seems to me the way to handle this is to call out to another function
to do the actual fp i/o.  Since we're talking about vfprintf, an interface
as simple as

  void do_fp_printf(FILE *f, int width, int prec, char fmt, va_list *arg)

should cover all the cases.  It is also now easy to ifdef it out, which
could be nice for the embedded folks.


r~

Re: exception handling poll

[Joel Sherrill]

On Fri, 17 Oct 1997, Richard Henderson wrote:

> On Fri, Oct 17, 1997 at 12:43:32PM -0500, Joel Sherrill wrote:
> > > | 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.
> 
> Seems to me the way to handle this is to call out to another function
> to do the actual fp i/o.  Since we're talking about vfprintf, an interface
> as simple as
> 
>   void do_fp_printf(FILE *f, int width, int prec, char fmt, va_list *arg)
> 
> should cover all the cases.  It is also now easy to ifdef it out, which
> could be nice for the embedded folks.

I looked into reorganizing the vfprintf implementation in newlib to do
just this and did not have enough success quickly enough to keep working
on it.  This is the best solution I think.  I guess I need to revisit it
in the future.

There is no fundamental surprise with the PPC code generation like the
PA's use of the FPU for integer multiply/divide.

--joel

Re: exception handling poll

[Christian Iseli]

> Some of the GCC ports I've done, even 2% is unacceptable (when you only have
> 32k or whatever, it does become critical not to have extra overhead).

My feeling, exactly.
					Christian

Re: exception handling poll

[meissner]

| On Sat, 18 Oct 1997 meissner@cygnus.com wrote:
| 
| > Also, if you are using a newlib based printf, note there are the functions:
| > 
| > 	iprintf
| > 	fiprintf
| > 	siprintf
| > 	viprintf
| > 	vfiprintf
| > 	vsiprintf
| > 
| > that do not include any floating point support (which also cuts down on the
| > size).
| 
| I have resisted using the integer versions since they are non-standard.  I
| suppose that there is actually justification for using them in this case
| though.  RTEMS is pretty much in bed with newlib these days. :)

You could always do it via #defines (#define printf iprintf), either via the
Makefile, or in a header file.  You should make sure they get definitions,
including the format attribute, since some ABI's use a different calling
sequence for ... functions.

Re: exception handling poll

[meissner]

| On Fri, Oct 17, 1997 at 12:43:32PM -0500, Joel Sherrill wrote:
| > > | 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.
| 
| Seems to me the way to handle this is to call out to another function
| to do the actual fp i/o.  Since we're talking about vfprintf, an interface
| as simple as
| 
|   void do_fp_printf(FILE *f, int width, int prec, char fmt, va_list *arg)
| 
| should cover all the cases.  It is also now easy to ifdef it out, which
| could be nice for the embedded folks.

Also, if you are using a newlib based printf, note there are the functions:

	iprintf
	fiprintf
	siprintf
	viprintf
	vfiprintf
	vsiprintf

that do not include any floating point support (which also cuts down on the
size).

Re: exception handling poll

[Joel Sherrill]

On Sat, 18 Oct 1997 meissner@cygnus.com wrote:

> Also, if you are using a newlib based printf, note there are the functions:
> 
> 	iprintf
> 	fiprintf
> 	siprintf
> 	viprintf
> 	vfiprintf
> 	vsiprintf
> 
> that do not include any floating point support (which also cuts down on the
> size).

I have resisted using the integer versions since they are non-standard.  I
suppose that there is actually justification for using them in this case
though.  RTEMS is pretty much in bed with newlib these days. :)

--joel

Re: exception handling poll

[meissner]

| If the .eh_frame section does not get paged into memory, then I think 10% is
| acceptable (remember that the in-memory penalty is essentially zero).  For
| kernels or embedded code where there is no paging, the acceptable figure
| is smaller, and I suspect that folks would use -fno-exceptions no matter
| how small the penalty is (unless it is 2% or less).

Some of the GCC ports I've done, even 2% is unacceptable (when you only have
32k or whatever, it does become critical not to have extra overhead).

Re: exception handling poll

[Robin Kirkham]

On Thu, 16 Oct 1997, meissner@cygnus.com wrote:

> | If the .eh_frame section does not get paged into memory, then I think 10% is
> | acceptable (remember that the in-memory penalty is essentially zero).  For
> | kernels or embedded code where there is no paging, the acceptable figure
> | is smaller, and I suspect that folks would use -fno-exceptions no matter
> | how small the penalty is (unless it is 2% or less).
> 
> Some of the GCC ports I've done, even 2% is unacceptable (when you only have
> 32k or whatever, it does become critical not to have extra overhead).

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).

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.

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.

Robin Kirkham			CSIRO Manufacturing Science and Technology
Project Engineer		Locked Bag 9, Preston 3072, Australia
robin.kirkham@mlb.dmt.csiro.au	Phone: +61 3 9662-7756  Fax: +61 3 9662-7851

Re: exception handling poll

[Joel Sherrill]

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

Re: exception handling poll

[Joe Buck]

> Some of the GCC ports I've done, even 2% is unacceptable (when you only have
> 32k or whatever, it does become critical not to have extra overhead).

I fully understand.  I've gone through the experience myself of trying
to fit a too-large program into ROM for an embedded system and I was
counting each word.  But are you and the other embedded systems folks
being consistent here?

That is, have you verified that no other egcs change results in a 2%
increase in code size for little or no gain?  It's true that .eh_frame
is special in that it's clear the wasted space is just that, wasted.
But have we been carefully comparing space performance on old benchmarks?
If so, I haven't seen that much discussion.

Re: exception handling poll

[Robin Kirkham]

On Fri, 17 Oct 1997, Joe Buck wrote:
> > Some of the GCC ports I've done, even 2% is unacceptable (when you only have
> > 32k or whatever, it does become critical not to have extra overhead).
> 
> I fully understand.  I've gone through the experience myself of trying
> to fit a too-large program into ROM for an embedded system and I was
> counting each word.  But are you and the other embedded systems folks
> being consistent here?
> 
> That is, have you verified that no other egcs change results in a 2%
> increase in code size for little or no gain?  It's true that .eh_frame
> is special in that it's clear the wasted space is just that, wasted.
> But have we been carefully comparing space performance on old benchmarks?
> If so, I haven't seen that much discussion.

I am not using egcs seriously for embedded code (yet) but I tried a little
comparison between gcc 2.7.2.2 and egcs 971016, both built as m68k 
cross-compilers. The C code was the same in both cases, as were the compiler
switches (-m68020 -m68881 -O2 -g). The following table compares the text and
data sizes (as reported by m68k-size):


	2.7.2	971016		2.7.2	971016
	text	text		data	data	filename

	2212   	2212	0%	0      	880	tree.o (ex libframe-1.a)
	994    	998	+0.4%	0      	692	frame.o (ex libframe-1.a)
	698    	690	+0.3%	8      	466	screen.o (ex libframe-1.a)
	416    	416	0%	0      	426	system.o (ex libframe-1.a)
	744    	744	0%	12     	446	tile.o (ex libframe-1.a)
	1460   	1460	0%	0      	1942	subtract.o (ex libframe-1.a)
	1268   	1258	-0.8%	0      	872	retile.o (ex libframe-1.a)
	206    	206	0%	0      	142	minder.o (ex libframe-1.a)
	552    	560	+1.4%	0      	410	fill.o (ex libframe-1.a)
	238    	240	+3.3%	0      	156	writec.o (ex libframe-1.a)
	716    	716	0%	0      	506	writes.o (ex libframe-1.a)
	106    	106	0%	0      	184	writef.o (ex libframe-1.a)
	158    	158	0%	0      	152	blank.o (ex libframe-1.a)
	766    	798	+4.1%	16     	686	box.o (ex libframe-1.a)
	2062   	2064	+0.1%	0      	1252	term.o (ex libframe-1.a)
	990    	986	-0.4%	0      	642	list.o (ex libframe-1.a)
	210    	216	+2.9%	0      	208	clock.o (ex libframe-1.a)
	318    	318	0%	4      	356	stdio.o (ex libframe-1.a)

	11924	11952	+0.23%	40	9556	a.out (m68k-ld -r *.o)

In other words, for this code (which is typical of the embedded system stuff I
write), there is about a +0.2% code size increase, made up of some increases
and some decreases in individual modules. The big change in data size is
accounted for by .eh_frame, .stabs, etc stuff which the final link would
(currenly) discard.

If you compile with exceptions turned off (-fno-exceptions) the text and
data sizes are *exactly* as they were for gcc 2.7.2.2.

Now this for m68k, which I don't think has seen much change in egcs, so perhaps
this is not too suprising. However the 68k is the classic 32-bit embedded
system micro nowadays, so it is significant. More interesting results might
be obtained for other architectures (e.g. ppc's and arms are finding their
way into small embedded systems).

Robin Kirkham			CSIRO Manufacturing Science and Technology
Project Engineer		Locked Bag 9, Preston 3072, Australia
robin.kirkham@mlb.dmt.csiro.au	Phone: +61 3 9662-7756  Fax: +61 3 9662-7851

Re: exception handling poll

[meissner]

| A little poll for those that have been complaining about 
| exception handling frame unwind info being included for C:
| 
|   Assuming the .eh_frame section is completely read-only, at what
|   eh/text ratio would you find it acceptible that that information
|   is always there?
| 
| Can you live with 10%?  8?  5?  3?

For many embedded users, the answer is 0.

Re: exception handling poll

[Richard Henderson]

On Thu, Oct 16, 1997 at 04:23:24PM -0400, meissner@cygnus.com wrote:
> | Can you live with 10%?  8?  5?  3?
> 
> For many embedded users, the answer is 0.

That's begging the question.  Embedded users and the kernel live in
a completely separate world than paged user-mode applications.


r~

Re: exception handling poll

[Horst von Brand]

meissner@cygnus.com said:
> [Sorry, attribution lost]:
> | A little poll for those that have been complaining about 
> | exception handling frame unwind info being included for C:

> |   Assuming the .eh_frame section is completely read-only, at what
> |   eh/text ratio would you find it acceptible that that information
> |   is always there?

> | Can you live with 10%?  8?  5?  3?

> For many embedded users, the answer is 0.

Seconded.

And for other applications too.  Disk space is _not_ infinite either.  Also
remember C is mostly used as portable assembly, with the intention of "no
fat whatsoever". Sadly, C++ is wandering off into PL/I land...

BTW, as has been said several times before: You _can't_ ever trow through C
code, unless that C code is _very_ *very* carefully written (I'd suspect
C++ must be written with the same care, or thereabouts, as far as things
stand now ;-). So C++ exception handling support in C is not only a waste
(can't be used in C) but even extremely dangerous. Just leave that stuff to
C++, and compile your "C" to be used with C++ with a C++ compiler, or add
it in with an explicit enabling flag for C, so clueless people don't try to
do it by mistake. If libc or whatever functions need overriding for C++
with C++-safe versions, do that in libc++ or whatever.  You'll have to do
that anyway, as you will never be able to trust the native libraries.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: exception handling poll

[Joe Buck]

> BTW, as has been said several times before: You _can't_ ever trow through C
> code, unless that C code is _very_ *very* carefully written

Why do you believe that?  Throws through C code work just fine.
It looks to the C code much like a longjmp call, and people have
been using longjmp for a long time.

Re: exception handling poll

[Richard Henderson]

On Fri, Oct 17, 1997 at 10:28:40AM -0300, Horst von Brand wrote:
> BTW, as has been said several times before: You _can't_ ever trow through C
> code, unless that C code is _very_ *very* carefully written...

Not exactly.  What you mean is that you can't throw through arbitrary
C code and expect to be able to continue on as if nothing happened, and
eventually call back down into the same library.

But without frame unwind info in C code -- libraries in particular -- 
you can't even gracefully shut down an application.



r~

Re: exception handling poll

[Horst von Brand]

Richard Henderson <rth@cygnus.com> said:
> On Fri, Oct 17, 1997 at 10:28:40AM -0300, Horst von Brand wrote:
> > BTW, as has been said several times before: You _can't_ ever trow through C
> > code, unless that C code is _very_ *very* carefully written...

> Not exactly.  What you mean is that you can't throw through arbitrary
> C code and expect to be able to continue on as if nothing happened, and
> eventually call back down into the same library.

Thats what I said: Unless the C is carefully written, if you throw through
it, things break. So, it is completely useless to pretend you're doing the
"right thing" when you aren't.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: exception handling poll

[meissner]

| That's begging the question.  Embedded users and the kernel live in
| a completely separate world than paged user-mode applications.

I'm trying to point out that they are a class of users and shouldn't be
ignored.

exception handling poll

[Richard Henderson]

A little poll for those that have been complaining about 
exception handling frame unwind info being included for C:

  Assuming the .eh_frame section is completely read-only, at what
  eh/text ratio would you find it acceptible that that information
  is always there?

Can you live with 10%?  8?  5?  3?


----------------------------

I was having a look at a "random" nice large program this evening,
f771, and trying to work out how big the frame info would be
assuming ideal generation.

Some basic numbers: 1533276 bytes text, 4210 functions.

The dwarf2 frame info requires 16 bytes/function static overhead for
eh info length, cie address, function address, and function length. 
For f771, that brings us up to a few more than 67k, or 4.4% even before
adding any actual information.

Depending on how the initial_information insn bits in the CIE is
interpreted, this could potentially encode all the information for 
all x86 with 3 CIEs.  Which means about 60 more bytes.  It would 
seem then, that somewhere around 4.5% is the best we could possibly
do on f771 with dwarf2 frame info. 

(I suppose some more large program data points would be good.  Anyone
have x86 glibc handy compiled with eh info?)

Now, with the current adv4/cfa_ofs/adv4/cfa_reg sequence on x86 to set
up the frame pointer, this eats up another 60204 bytes, 43366 of which
is in the adv4's.  Assuming we knew we could reduce these to adv, we'd
reduce that 43k to 8673 for a total of 25511.  Relaxing rigour for a
moment, changing to def_cfa would total 12630.  Adding these to our
base totals, we get 6.0% and 5.2% respectively.

Recording one saved register is adv/ofs for 1+2 bytes; recording two
or three (there are only 3 saved regs not including bp), takes 4.  Add
this in to our running total and we get 6.04% min and 7.16% max.

This 7.2% number is interesting because I think it is about as good as
can theoretically be done without linker help; assistance from within
the assembler doesn't help.  What would be required to get here is exact
length attributes on the insns in the i386.md file.  

With an inexact but bounding length attribute, we could minimize the
current lossage above this number from 4*3 to 1*3 bytes/FDE.  This would
make for about 8.0% on the running total.

So.  Given the number I posted last night at 12.5%, a patch I put 
together this evening that yields about 11% on x86, a rock-bottom
minimum somewhere between 4.5 and 6% (depending on other constraints)
and the fact that the sparc port is already down at 5.4%:

  Is it worth spending the effort required to get that last 5%,
  possibly by requiring a new version of gnu ld?  Or would I just
  be wasting my time since the overhead would still be considered 
  unacceptible?
  


r~

Re: exception handling poll

[Joe Buck]

> A little poll for those that have been complaining about 
> exception handling frame unwind info being included for C:
> 
>   Assuming the .eh_frame section is completely read-only, at what
>   eh/text ratio would you find it acceptible that that information
>   is always there?
> 
> Can you live with 10%?  8?  5?  3?

If the .eh_frame section does not get paged into memory, then I think 10% is
acceptable (remember that the in-memory penalty is essentially zero).  For
kernels or embedded code where there is no paging, the acceptable figure
is smaller, and I suspect that folks would use -fno-exceptions no matter
how small the penalty is (unless it is 2% or less).

Re: exception handling poll

[Joern Rennecke]

> So.  Given the number I posted last night at 12.5%, a patch I put 
> together this evening that yields about 11% on x86, a rock-bottom
> minimum somewhere between 4.5 and 6% (depending on other constraints)
> and the fact that the sparc port is already down at 5.4%:
> 
>   Is it worth spending the effort required to get that last 5%,
>   possibly by requiring a new version of gnu ld?  Or would I just
>   be wasting my time since the overhead would still be considered 
>   unacceptible?

Why don't you implement first a scheme that makes the linker strip all EH
info if there is no user of EH info?  That looks like a greater saving to
me.

Of course, a low-overhead EH scheme is still important if you need EH
info in shared libraries.

Re: exception handling poll

[Richard Henderson]

On Thu, Oct 16, 1997 at 09:22:42PM +0100, Joern Rennecke wrote:
> Of course, a low-overhead EH scheme is still important if you need EH
> info in shared libraries.

Yes, we do.

Having the linker strip out the section when it can determine that
it is not used is a good option, but am also trying to figure out
what can be done without requiring gnu ld, and a new version at that.


r~

Re: exception handling poll

[Oleg Krivosheev]

On Thu, 16 Oct 1997, Richard Henderson wrote:

> A little poll for those that have been complaining about 
> exception handling frame unwind info being included for C:
> 
>   Assuming the .eh_frame section is completely read-only, at what
>   eh/text ratio would you find it acceptible that that information
>   is always there?
> 
> Can you live with 10%?  8?  5?  3?

i'd like 8%.

no, i don't have any rational thoughts
but being less than 10% would be nice

thanks

OK

Re: exception handling poll

[Stephen Williams]

On Thu, 16 Oct 1997, Richard Henderson wrote:

> A little poll for those that have been complaining about 
> exception handling frame unwind info being included for C:
> 
>   Assuming the .eh_frame section is completely read-only, at what
>   eh/text ratio would you find it acceptible that that information
>   is always there?
> 
> Can you live with 10%?  8?  5?  3?

I can no longer contain myself:

0%. (Well, maybe a tiny bit more then that.)

I use g++ for embedded targets, and I have spent much effort getting
executable sizes down. Exception handling would be really nice, but
x% costs real hardware, and real money. And prices are not linear, either.

Don't forget us embedded people, please:-)

-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: exception handling poll

[Oleg Krivosheev]

hi,

On Fri, 17 Oct 1997, Stephen Williams wrote:

> On Thu, 16 Oct 1997, Richard Henderson wrote:
> 
> > A little poll for those that have been complaining about 
> > exception handling frame unwind info being included for C:
> > 
> >   Assuming the .eh_frame section is completely read-only, at what
> >   eh/text ratio would you find it acceptible that that information
> >   is always there?
> > 
> > Can you live with 10%?  8?  5?  3?
> 
> I can no longer contain myself:
> 
> 0%. (Well, maybe a tiny bit more then that.)
> 
> I use g++ for embedded targets, and I have spent much effort getting
> executable sizes down. Exception handling would be really nice, but
> x% costs real hardware, and real money. And prices are not linear, either.
> 
> Don't forget us embedded people, please:-)

hmm...

can be EH exposed into C? Something like MS
__try, __catch etc ? Maybe after this embedded
people will be happy having added value for few %
bloat?

just a thought

OK

Re: exception handling poll

[John Carr]

>   Assuming the .eh_frame section is completely read-only, at what
>   eh/text ratio would you find it acceptible that that information
>   is always there?
> 
> Can you live with 10%?  8?  5?  3?

Probably 3%.

For the first egcs release we should:

1. Default C -fexceptions off on all targets.  Not one extra bit for
exception handling.

2. Get the overhead for code not using exceptions, but compiled with
exceptions enabled, under 8% (for "typical" code, whatever that is).
If that means setjmp exceptions on x86, then we do that.

3. Document and warn that the next egcs release will be binary
incompatible if exceptions are used.

Then we have a few months to fix exceptions and we can look at making
them better, smaller, faster, or compatible with the system compiler
without delaying a release.

Re: exception handling poll

[Joe Buck]

> 2. Get the overhead for code not using exceptions, but compiled with
> exceptions enabled, under 8% (for "typical" code, whatever that is).
> If that means setjmp exceptions on x86, then we do that.

Um, are you sure?  setjmp exceptions put extra code in the text section,
which must be paged in.  .eh_frame, on the other hand, is not paged
in normally (or at least, not once it is completely read-only), the
extra space is on disk.  Switching to setjmp exceptions means that you
pay more RAM and CPU (since there is overhead even when exceptions are
not thrown).  You only save disk space.  Is that really a good tradeoff?

> 3. Document and warn that the next egcs release will be binary
> incompatible if exceptions are used.

Well, I think we're going to break compatibility for C++ soon.  We
pretty much have to to support namespaces and templated iostreams.
And we'll pretty much want to to get more efficient mangling of
template functions.  Just for fun, try looking at the mangled symbols
generated for the methods of map<string,string> .

Re: exception handling poll

[Richard Henderson]

On Fri, Oct 17, 1997 at 10:22:16AM -0700, Joe Buck wrote:
> And we'll pretty much want to to get more efficient mangling of
> template functions.  Just for fun, try looking at the mangled symbols
> generated for the methods of map<string,string> .

Aiee.  Tell me about it.  I recently fixed a reported problem in the
assembler with ECOFF debugging that bombed because the stab for the
class exceeded 4k, primarily due to a 336 character class name.


r~

Re: exception handling poll

[John Carr]

> > If that means setjmp exceptions on x86, then we do that.
> 
> Um, are you sure?  setjmp exceptions put extra code in the text section,
> which must be paged in.

No, I'm not sure.  I guess we just can't win if exceptions are enabled
with the current architecture, and that's why I want the binary
incompatibility warning.

> Well, I think we're going to break compatibility for C++ soon.  We
> pretty much have to to support namespaces and templated iostreams.
> And we'll pretty much want to to get more efficient mangling of
> template functions.  Just for fun, try looking at the mangled symbols
> generated for the methods of map<string,string> .

Someone should keep a list of changes that would help gcc but break
compatibility so we can do them all at once.

Re: exception handling poll

[Per Bothner]

Joe Buck <jbuck@synopsys.com> writes:
> Um, are you sure?  setjmp exceptions put extra code in the text section,
> which must be paged in.

I'm wondering if you and John Carr might be mis-understanding one other.
I understood John to mean that using setjmp would satisfy the
requirement of no cost in code that does not *contain a handler",
while still allowing exceptions to pass through such code.

Joe's point seems to be that having setjmp code in the text segment
is worse than having eh ranges in an eh section which is normally
not pages in.  That is true - the problem is that we would still
need some eh info for functions with no handlers, if they can
be thrown through, but that is not the case (I think) for a
setjmp-based solution, though it is otherwise more expensive.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: exception handling poll

[John Carr]

> I understood John to mean that using setjmp would satisfy the
> requirement of no cost in code that does not *contain a handler",
> while still allowing exceptions to pass through such code.

When I sent my mail I forgot that local variables with destructors
require exception handlers to run those destructors so most C++ code
is not handler-free and setjmp will introduce significant code
expansion.

Re: exception handling poll

[Jeffrey A Law]

  In message < 199710171340.JAA23714@contents-vnder-pressvre.MIT.EDU >
  John Carr wrote:

  > Probably 3%.
  > 
  > For the first egcs release we should:
  > 
  > 1. Default C -fexceptions off on all targets.  Not one extra bit for
  > exception handling.
I think that's the direction we're heading.  I guess now is as good a time
as any to tell everyone :-)

Basically, we're going to be temporarily turning off -fexceptions for C
(hopefully starting with the next snapshot).  The basic idea is to turn
it off so the C folks won't pay the EH penalty until such time as we can
get the overhead down to something acceptable to most C programmers.

jeff