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