From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Kirkham To: Joe Buck Cc: meissner@cygnus.com, rth@cygnus.com, egcs@cygnus.com Subject: Re: exception handling poll Date: Sun, 26 Oct 1997 19:34:00 -0000 Message-id: <19971027033303.740.qmail@ragnarok.mlb.dmt.csiro.au> References: <199710171713.KAA07771@atrus.synopsys.com> X-SW-Source: 1997-10/msg01111.html 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