Article 35830 of comp.sys.amiga.programmer: Newsgroups: comp.sys.amiga.games,comp.sys.amiga.programmer Path: news.csos.orst.edu!gaia.ucs.orst.edu!umn.edu!news-feed-1.peachnet.edu!concert!sas!mozart.unx.sas.com!jamie From: jamie@cdevil.unx.sas.com (James Cooper) Subject: Re: Ridiculous code size (was: Re: ALIEN BREED Author(s) Read This) Originator: jamie@cdevil.unx.sas.com Sender: news@unx.sas.com (Noter of Newsworthy Events) Message-ID: Date: Thu, 12 Aug 1993 13:43:43 GMT References: <1993Aug11.181410.7607@csc.canberra.edu.au> <24cdov$6d5@wraith.cs.uow.edu.au> Nntp-Posting-Host: cdevil.unx.sas.com Organization: SAS Institute Inc. Lines: 56 Xref: news.csos.orst.edu comp.sys.amiga.games:37659 comp.sys.amiga.programmer:35830 In article <24cdov$6d5@wraith.cs.uow.edu.au>, u9147063@wraith.cs.uow.edu.au (Richard Barry Ling) writes: >u934132@student.canberra.edu.au (Ogawa / Taro Stephen (ISE)) writes: > >> >I had a program that was compiled under Borland C++ 3.1 and it used 150k for >> >the executable. The same program compiled under SAS C 5.1 took 60k! > >> I wrote a mickey mouse program in assembler - it took about 60 Bytes. I >> then wrote the program in ADA, and it took 28 KiloBytes. I think that sums >> up ADA nicely. > >Try compiling this with your favourite C compiler - you should get a laugh. > >main() >{ >} > >Came to around 5-6 Kbytes using SAS/C. That should be a capital offence >IMHO... OK, OK, I know its silly to even *attempt* to defend against something as silly as this, but I'd hate a tide of misinformation to start. First, you don't say which version of SAS/C you tried this with. With the latest version of the compiler (V6.3), with no command line switches used, this comes out to 3488 bytes. Since you aren't declaring any local variables, or doing a lot of function calls, or anything else that you need a lot of stack for, you can use the NOSTACKCHECK switch, which drops the code to 3232 bytes. Since you aren't doing any I/O, you could use the NOSTDIO switch, which drops the code to 1200 bytes. Since you aren't doing anything that needs the startup code (i.e., no command line stuff, no UNIX stuff, etc.), you could use the NOSTARTUP switch, which drops the code to 40 bytes. Now, since 40 bytes is the smallest possible executable filesize on the Amiga, I think the compiler did pretty well... of course, though, your example is BAD, in that it declares a function that returns an INT, but then it doesn't actually return anything. Just add a "return 0;" inside the curly braces, and it is a perfectly valid, properly functioning program. The compiler still only generates 40 bytes, though... :-) sc NOSTACKCHECK NOSTARTUP LINK test.c -- --------------- Jim Cooper (jamie@unx.sas.com) bix: jcooper Any opinions expressed herein are mine (Mine, all mine! Ha, ha, ha!), and not necessarily those of my employer. Article 35841 of comp.sys.amiga.programmer: Newsgroups: comp.sys.amiga.games,comp.sys.amiga.programmer Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!news-feed-1.peachnet.edu!concert!sas!mozart.unx.sas.com!walker From: walker@twix.unx.sas.com (Doug Walker) Subject: Re: Ridiculous code size (was: Re: ALIEN BREED Author(s) Read This) Originator: walker@twix.unx.sas.com Sender: news@unx.sas.com (Noter of Newsworthy Events) Message-ID: Date: Thu, 12 Aug 1993 17:20:26 GMT References: <1993Aug11.181410.7607@csc.canberra.edu.au> <24cdov$6d5@wraith.cs.uow.edu.au> Nntp-Posting-Host: twix.unx.sas.com Organization: SAS Institute Inc. Lines: 92 Xref: news.csos.orst.edu comp.sys.amiga.games:37671 comp.sys.amiga.programmer:35841 In article <24cdov$6d5@wraith.cs.uow.edu.au>, u9147063@wraith.cs.uow.edu.au (Richard Barry Ling) writes: |> Try compiling this with your favourite C compiler - you should get a laugh. |> |> main() |> { |> } |> |> Came to around 5-6 Kbytes using SAS/C. That should be a capital offence |> IMHO... Why don't you try comparing apples and oranges? There's an awful lot of work done behind the scenes in a standard C program before your first line of code starts. Try getting rid of that overhead before comparing C's output. I compiled your example with SAS/C V6.3: SC test.c LINK ==> 3488 bytes This includes code to 1) parse comman-line arguments 2) handle WorkBench invocations 3) set up stdin/stdout/stderr 4) check for stack overflow on invocation of main(). and put up a requester if it occurs SC test.c LINK NOSTACKCHECK ==> 3232 bytes This gets rid of #4 above. SC test.c LINK NOSTACKCHECK NOSTDIO ==> 1200 bytes This gets rid of #3 above. SC test.c LINK NOSTACKCHECK NOSTARTUP ==> 40 bytes This gets rid of all 4 of the ones above. Note that I used only command-line options on the compiler, I didn't have to modify the code. I also didn't bother running the optimizer since the code generator is good enough to make this a plain RTS without it. Also note that an assembly version of the same program also takes 40 bytes: section text,code RTS end What conclusion do I draw? Adding functionality to a program from a link library or startup code actually increases the size of my program. By gosh, that's amazing! Frankly, a 3232-byte program that provides a standard, ANSI-compliant hosted C environment that runs from either WorkBench or the Shell is outstanding. If you don't want the environment, fine, ditch it and remove the overhead. We make it easy to do. As an added bonus, here's a 124-byte "Hello, World" program that we ship as an example with SAS/C Version 6: Compile with SC NOSTACKCHECK STRINGMERGE OPTIMIZE LINK NOSTARTUP #include #include #include #define MSG "Hello, World!\n" void hello(void) { struct DosLibrary *DOSBase = (struct DosLibrary *)OpenLibrary("dos.library", 0L); Write(Output(), MSG, sizeof(MSG)-1); CloseLibrary((struct Library *)DOSBase); } -- ***** / walker@unx.sas.com *|_o_o|\\ Doug Walker< BIX, Portal: djwalker *|. o.| || \ CompuServe: 71165,2274 | o |// ====== Any opinions expressed are mine, not those of SAS Institute, Inc. Article 35921 of comp.sys.amiga.programmer: Newsgroups: comp.sys.amiga.games,comp.sys.amiga.programmer Path: news.csos.orst.edu!gaia.ucs.orst.edu!umn.edu!news-feed-1.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!world!cosell From: cosell@world.std.com (Bernie Cosell) Subject: Re: Ridiculous code size (was: Re: ALIEN BREED Author(s) Read This) Message-ID: Sender: cosell@world.std.com (Bernie Cosell) Reply-To: cosell@world.std.com Organization: Fantasy Farm Fibers X-Newsreader: Arn V1.03 References: <1993Aug11.181410.7607@csc..canberra.edu.au> <24cdov$6d5@wraith.cs.uow.edu.au> <24epsa$mdn@wraith.cs.uow.edu.au> Date: Sat, 14 Aug 1993 03:34:35 GMT Lines: 55 Xref: news.csos.orst.edu comp.sys.amiga.games:37764 comp.sys.amiga.programmer:35921 In article <24epsa$mdn@wraith.cs.uow.edu.au>, Richard Barry Ling writes: } jamie@cdevil.unx.sas.com (James Cooper) writes: } } > u9147063@wraith.cs.uow.edu.au (Richard Barry Ling) writes: } > } > >Try compiling this with your favourite C compiler - you should get a laugh. } > > } > >main() } > >{ } > >} } > > } > >Came to around 5-6 Kbytes using SAS/C. That should be a capital offence } > >IMHO... } } > OK, OK, I know its silly to even *attempt* to defend against something } > as silly as this, but I'd hate a tide of misinformation to start. } } It's a pity to see such a barrage of replies to my offhand statement. We } were talking about inefficiency of code sizes and redundant code. I wasn't } trying to degrade SAS or its product, just pointing out how much more } efficient assembly programming is than C. Maybe I should have said "using } one particular Amiga compiler". No, the problem is your implciationthat a large executable has anything to say about "inefficiency of code sizes", nor if there is a single *byte* of "redundant code" in the image. } Using a C compiler on UN*X I was unable to get a code size less than 24k, } even for the program above. I managed to strip this to 16k, but I would be } very interested to know what lives in all that space... On both Unix and on the Amiga, none of this should be a mystery. Just get a linker-map and see what has been loaded [*surely* you don't think that they padded 10 or 20 K of blank space onto your program?]. I did this once for Unix, years and years ago, and it was pretty simple: exit [called implicitly out of main when it returns] calls fflush and then closes each open file descriptor. As it turns out, there was some error condition possible for fflush, so it had a call to fprintf(stderr,...) in it. But fprintf includes a dispatch to handle %f, so that sucked in the floating arithmetic routines, and that in turn pulled in the floating emulation routines [no chip on the particular machine I was doing this on]. Nothing redundant, and nothing out of the ordinary. You could do the same for your compiler and report back what it *did* load. In the above, we didn't have the sources for the various routines, but you CAN get theinfor about which routines have which 'undefined globals' [using 'nm' in the Unix world] and so we could piece together the above chain of events/calls. Kind of fun, actually. /Bernie\ -- Bernie Cosell cosell@world.std.com Fantasy Farm Fibers, Pearisburg, VA (703) 921-2358