Related articles |
---|
Dead code elimination whatis@ucsd.edu (Steve Boswell) (1991-10-26) |
Re: Dead code elimination henry@zoo.toronto.edu (1991-10-29) |
Re: Dead code elimination clyde@hitech.com.au (1991-11-01) |
Re: Dead code elimination henry@zoo.toronto.edu (1991-11-05) |
Re: Dead code elimination schwartz@roke.cs.psu.edu (1991-11-05) |
Re: Dead code elimination dd@mips.com (1991-11-05) |
Re: Dead code elimination eggert@twinsun.com (1991-11-06) |
Re: Dead Code Elimination preston@dawn.cs.rice.edu (1991-11-07) |
dead code elimination preston@dawn.cs.rice.edu (1991-11-26) |
dead code elimination preston@tera.com (1995-03-23) |
Newsgroups: | comp.compilers |
From: | eggert@twinsun.com (Paul Eggert) |
Keywords: | C, linker |
Organization: | Twin Sun, Inc |
References: | 91-10-106 91-11-007 |
Date: | Wed, 6 Nov 1991 04:40:34 GMT |
clyde@hitech.com.au (Clyde Smith-Stubbs) writes:
>I'd still like to know why a simple printf("Hello world\n"); when compiled
>with cc -n on my Sun produces a 94K program!
But it's only 86K stripped (:-). Aside from alignment and header overhead,
the easiest way to answer your question is to type `nm -s a.out'. You'll
get some interesting results, e.g. 37K devoted to powers of two and ten.
Most of the overhead is floating point conversion routines, which typically
can be accurate, fast, or small, or any two out the three, but not all three
simultaneously. If you look carefully, you'll find other minor
inefficiencies, but the main culprit is floating point.
To put some perspective on this, I'd guess 86K of main memory now costs less
than what 86 bytes cost back when Unix was designed (in constant dollars).
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.