This is C-compiler in view mode; [Up]
Date: Sun 19-May-1990 23:31:41 From: jnicolas@athena.mit.edu (Julien J Nicolas) Subject: C compiler Hi everyone! As an experiment, I compiled the following program:
Date: Sun 20-May-1990 08:31:53 From: dstaas@polyslo.CalPoly.EDU ((That's two a's)) Subject: Re: C compiler jnicolas@athena.mit.edu (Julien J Nicolas) politely asks: >main() >{ > double val; > > printf("Enter value "); scanf("%lf", &val); > printf("val=%f\n", val); >} > >The size of the binary is 59523 bytes (!). I compiled the same piece >of code on a VaxStation 3100 with a High C compiler. The size of the >binary is 11264 bytes. Any one have an explanation for such a >difference? > > -JJN- Actually, if you compile main() {}, it comes out to 59111. Applying strip takes it down to about 49k, but that's it. File this one under "memory's cheap." -- Dave
Date: Sun 20-May-1990 08:31:53 From: dstaas@polyslo.CalPoly.EDU ((That's two a's)) Subject: Re: C compiler jnicolas@athena.mit.edu (Julien J Nicolas) politely asks: >main() >{ > double val; > > printf("Enter value "); scanf("%lf", &val); > printf("val=%f\n", val); >} > >The size of the binary is 59523 bytes (!). I compiled the same piece >of code on a VaxStation 3100 with a High C compiler. The size of the >binary is 11264 bytes. Any one have an explanation for such a >difference? > > -JJN- Actually, if you compile main() {}, it comes out to 59111. Applying strip takes it down to about 49k, but that's it. File this one under "memory's cheap." -- Dave
Date: Sun 20-May-1990 20:39:03 From: kellogg@prodigal.psych.rochester.edu (Lars Kellogg-Stedman) Subject: Re: C compiler In article 6086, jnicolas@athena.mit.edu (Julien J Nicolas) said, in part... > >The size of the binary is 59523 bytes (!). I compiled the same piece >of code on a VaxStation 3100 with a High C compiler. The size of the >binary is 11264 bytes. Any one have an explanation for such a >difference? Well, this is just a guess (I've never used a NeXT, but I'm familiar with other graphic-based machines)... Is the VaxStation 3100 character based? The NeXT definately isn't which means that it has to transalate your standard C calls into calls that give the printf statements somewehere to send their output to, draw the characters on screen, and deal with the newline character. Of course, it also has to deal with the scanf statement... Anybody else? > > -JJN- ~ ~ | Lars Kellogg-Stedman | "Software rots if not used" O-O | kellogg@prodigal.psych.rochester.edu | - The Tao of Programming | +--------------------------------------+----------------------------------+ -=- | I'm rarely responsible for what I say, do you think anybody else is?
Date: Sun 21-May-1990 15:06:10 From: flynn@surya.uucp (Patrick J. Flynn) Subject: Re: C compiler In article <blahdeblah> dstaas@polyslo.CalPoly.EDU politely replies: >jnicolas@athena.mit.edu (Julien J Nicolas) politely asks: >>main() >>{ >> double val; >> >> printf("Enter value "); scanf("%lf", &val); >> printf("val=%f\n", val); >>} >> >>The size of the binary is 59523 bytes (!). I compiled the same piece >>of code on a VaxStation 3100 with a High C compiler. The size of the >>binary is 11264 bytes. Any one have an explanation for such a >>difference? > >Actually, if you compile main() {}, it comes out to 59111. Applying strip >takes it down to about 49k, but that's it. File this one under "memory's >cheap." Use shared libraries and strip. That gets it down to 16K: Script started on Mon May 21 11:03:13 1990 1csh> cat x.c main() { double val; printf("Enter value "); scanf("%lf", &val); printf("val=%f\n", val); } 2csh>cc -o x x.c; ls -l x -rwxr-xr-x 1 flynn 59520 May 21 10:56 x* 3csh>strip x; ls -l x -rwxr-xr-x 1 flynn 49152 May 21 10:56 x* 4csh>cc -o x x.c -lsys_s; ls -l x -rwxr-xr-x 1 flynn 30030 May 21 10:56 x* 5csh>strip x; ls -l x -rwxr-xr-x 1 flynn 16384 May 21 10:56 x* 6csh> script done on Mon May 21 11:04:17 1990 TTFN - Pat
Date: Sun 21-May-1990 15:38:33 From: lane@sumex-aim.stanford.edu (Christopher Lane) Subject: Re: C compiler In <265655f9.1f27@petunia.CalPoly.EDU>, dstaas@polyslo.calpoly.edu writes: > >Actually, if you compile main() {}, it comes out to 59111. Applying strip >takes it down to about 49k, but that's it. File this one under "memory's >cheap." If you compile 'main() {}' with the -lsys_s shared library option then the executable is 29K and then if you strip it, 16K -- as small as NeXT 'C' executables get since the compiler allocates a Mach page (8192 bytes) to the TEXT segment and another page to the DATA segment. Do an 'ls -l' on /bin (or /usr/bin, etc) to convince yourself of this. - Christopher -------
Date: Sun 21-May-1990 19:06:59 From: aozer@next.com (Ali Ozer) Subject: Re: C compiler In article <265655f9.1f27@petunia.CalPoly.EDU> dstaas@polyslo.CalPoly.EDU writes: >Actually, if you compile main() {}, it comes out to 59111. Applying strip >takes it down to about 49k, but that's it. File this one under "memory's >cheap." You must not be linking with the shared library: cc main.c -lsys_s Generates a 29K executable, which strip brings down to 16K. The libsys_s shared library contains the c library and various other low-level libraries (Mach, sound, streams, objc...). Some of the executables in /NextDeveloper/Demos are actually in the 50-60K range, so 59K just for main() just didn't sound right. Ali (Ali_Ozer@NeXT.com)
Date: Sun 22-May-1990 06:19:13 From: edwardj@microsoft.UUCP (Edward JUNG) Subject: Re: C compiler In article <265655f9.1f27@petunia.CalPoly.EDU> dstaas@polyslo.CalPoly.EDU ((That's two a's)) writes: > >Actually, if you compile main() {}, it comes out to 59111. Applying strip >takes it down to about 49k, but that's it. File this one under "memory's >cheap." > >-- Dave >-- >DaveStaas:dstaas@polyslo.calpoly.edu:OfficialObjectiveCProgrammer'sSignature NeXT's Mach-O object executable in-memory format has three required is 8192 bytes, the minimum size of these segments in the Mach-O runtime is also 8192 bytes. Hence the minimum size of an application is 24k in memory. If the application uses objective-C features, another segment of 8k is added, the __OBJC segment. In the filesystem, the __PAGEZERO is zero-length (it is just a page allocated without access permissions and mapped to address 0x0000 at run-time; it exists as VM, but not in the file), but the two other pages have associated file segments. Thus the minimum executable file size is 16k. Object files in the Mach-O format (e.g. not executables) can pack their segments. Executables pad them out to the page size to facilitate loading. The large size of the compile noted by the original poster was due to the use of non-shared libraries. "cc -O test.c -lsys_s -o test" should result in a smaller executable file. If I do this I have a file of 30033 bytes, compared to the 59523 bytes without the shared library. If I strip the file, I end up with a file of 16384 bytes, the minimum size.
Date: Sun 23-May-1990 09:09:06 From: hannum@schubert.psu.edu (Charles Hannum) Subject: Re: C compiler In article <7531@ur-cc.UUCP> kellogg@prodigal.psych.rochester.edu (Lars Kellogg-Stedman) writes: In article 6086, jnicolas@athena.mit.edu (Julien J Nicolas) said, in part... > >The size of the binary is 59523 bytes (!). I compiled the same piece >of code on a VaxStation 3100 with a High C compiler. The size of the >binary is 11264 bytes. Any one have an explanation for such a >difference? Well, this is just a guess (I've never used a NeXT, but I'm familiar with other graphic-based machines)... Is the VaxStation 3100 character based? The NeXT definately isn't which means that it has to transalate your standard C calls into calls that give the printf statements somewehere to send their output to, draw the characters on screen, and deal with the newline character. Of course, it also has to deal with the scanf statement... Anybody else? You are not using the shared libraries on the NeXT. Put "-lsys_s" on the end of your link command (typically "gcc -o a.out [blah, blah]"). This will use the shared library and make your executable much smaller.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.