ferris@eniac.seas.upenn.edu (Richard T. Ferris) (01/07/90)
I am interested in learning how to reduce the size of my TurboC programs. The .exe files are 13K even for very simple programs. Could someone send me some suggested references? Thanks. RF Richard T. Ferris ferris@eniac.seas.upenn.edu University of Pennsylvania
darcy@druid.uucp (D'Arcy J.M. Cain) (01/08/90)
In article <18731@netnews.upenn.edu> ferris@eniac.seas.upenn.edu.UUCP (Richard T. Ferris) writes: >I am interested in learning how to reduce the size of my TurboC >programs. The .exe files are 13K even for very simple programs. >Could someone send me some suggested references? Thanks. > I have the following flags (among others that don't have to do with code optimization) in my TURBOC.CFG file: -v- Source level debugging off -Z Optimize register usage -r register variables I'm not sure what you mean by very simple but here are two test programs: PROGRAM 1: (Include standard I/O) #include <stdio.h> main() { printf("Hello, world\n"); } PROGRAM 2: (Ultra minimal) main() { int x = 1; } The executables come out to 6544 for (1) and 2310 for (2). This tells us what we knew all along, that code size is often affected by what is pulled in by the standard libraries, especially standard I/O. You might also try the above flags (especially -v-) to save a few bytes. Note that this assumes that you are compiling with TCC, not the environment. I usually develop code in the environment and the delete all the objects and re-compile with TCC. You can do similiar things in the programming environment. -- D'Arcy J.M. Cain (darcy@druid) | Thank goodness we don't get all D'Arcy Cain Consulting | the government we pay for. West Hill, Ontario, Canada | No disclaimers. I agree with me |
grimlok@hubcap.clemson.edu (Mike Percy) (01/09/90)
From article <1990Jan7.161841.6470@druid.uucp>, by darcy@druid.uucp (D'Arcy J.M. Cain): > In article <18731@netnews.upenn.edu> ferris@eniac.seas.upenn.edu.UUCP (Richard T. Ferris) writes: >>I am interested in learning how to reduce the size of my TurboC >>programs. The .exe files are 13K even for very simple programs. >>Could someone send me some suggested references? Thanks. >> > > I have the following flags (among others that don't have to do with code > optimization) in my TURBOC.CFG file: > > -v- Source level debugging off > -Z Optimize register usage > -r register variables > If you can avoid using printf, do so. Printf drags in a large routine. Many times you can use puts rather than printf. In my experience, puts is not only smaller than printf, but faster. Another thing in TurboC to avoid if possible is dragging in the floating point libraries when you don't need them. If you have no floats or doubles, you don't have to include the floating point emulator. If you do have floats, and don't have an 80x87, you are stuck with the emulator. Turn off floating point with -f-. Be careful when using the -Z flag, as it can cause _very_ difficult-to-track-down bugs. You might also try -O (optimize for size). Make sure that you haven't set -v and -y. The keep executables small, use -v- and -y-. -- 'I just couldn't convince the voters that Dukakis was Greek for "Bubba".' -- Lloyd Benson explaining why the Democrats didn't carry Texas
Lynn.Lively@p4694.f506.n106.z1.fidonet.org (Lynn Lively) (01/09/90)
In an article of <7 Jan 90 04:13:07 GMT>, ferris@eniac.seas.upenn.edu (Richard T. Ferris) writes:
RT>From: ferris@eniac.seas.upenn.edu (Richard T. Ferris)
RT>Date: 7 Jan 90 04:13:07 GMT
RT>Organization: University of Pennsylvania
RT>Message-ID: <18731@netnews.upenn.edu>
RT>Newsgroups: comp.lang.c
RT>
RT>I am interested in learning how to reduce the size of my TurboC
RT>programs. The .exe files are 13K even for very simple programs.
RT>Could someone send me some suggested references? Thanks.
Richard,
Are you using the integrated environment? If so, the default is to have
Debugging turned on. If you are using the command line check your
configuration file. You may have -v specified in it which will give you
Debugging each time you compile. The Debugging option burns up alot of space.
Your Servant,
Lynn
bright@Data-IO.COM (Walter Bright) (01/09/90)
In article <18731@netnews.upenn.edu> ferris@eniac.seas.upenn.edu.UUCP (Richard T. Ferris) writes:
<I am interested in learning how to reduce the size of my TurboC
<programs. The .exe files are 13K even for very simple programs.
<Could someone send me some suggested references? Thanks.
Start by looking at the .MAP file to see what was linked in and how big
each component is. Then you can try to substitute simpler routines, as in:
If your only call to printf is:
printf("Hello world\n");
replace with:
fputs("Hello world\n",stdout);scott@bbxsda.UUCP (Scott Amspoker) (01/09/90)
In article <7600@hubcap.clemson.edu> grimlok@hubcap.clemson.edu (Mike Percy) writes: >If you can avoid using printf, do so. Printf drags in a large routine. >Many times you can use puts rather than printf. In my experience, puts >is not only smaller than printf, but faster. > >Another thing in TurboC to avoid if possible is dragging in the floating >point libraries when you don't need them. This is probably the main reason a small program would create a large .EXE file. Using printf() will cause the floatingpoint library to be linked in unless you tell Turbo C not to bother (I can't remember the switch off hand). Without the floatingpoint library, printf() is not very large. Also, I agree that using puts() whenever possible is a good idea even if you are also using printf() just for speed. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
ferris@eniac.seas.upenn.edu (Richard T. Ferris) (01/10/90)
Here is my original question and the replies I received. Thanks to all for their assistance. >I am interested in learning how to reduce the size of my TurboC >programs. The .exe files are 13K even for very simple programs. >Could someone send me some suggested references? Thanks. > >RF >Richard T. Ferris >ferris@eniac.seas.upenn.edu >University of Pennsylvania *From: josephc@tybalt.caltech.edu (Joseph Chiu) Well, 13K is about the best size you will get for most situations. You can start reducing code size, first of all, but not including the floating-point library (switch off the [O]ptions-[C]ompiler-[C]ode-[F]loat). Also, by setting the compile switches to optimize for size, and to not include debugging information, and to not to a stack overrun check, you can eliminate some more. If you don't need the printf statements, and can settle with just puts or putc, I suspect you can reduce your .EXE size even more... What you might want to do is to find out what library functions are linked into your program and to see how much space they take up. Maybe you can find alternatives to some of the functions. *From: jb@altair.csustan.edu Use of printf scanf and their cousins sprintf, fprintf, vprintf ... drag in the floating point lib. Use of any of the stdio file operations drag in the _IOB structures for stdin sdtout etc. I realized approximately 6 k reduction on code size for a Microsoft C program by eliminating references to these. *From: Mark Streich <boulder!streich@boulder.Colorado.EDU> Have you turned off all of the debugging switches? Have you told the compiler to optimize for Size? If you're doing Floating Pt. math, you may be including the Fl. Pt. emulator which is used if you don't have a 80x87 chip. *From: Steve Resnick <stever@Octopus.COM> It depends on the memory model you are using and what library routines get called. Turbo C will, in small model, reserve space for the stack in the .EXE (I think) A lot of library routines are BIG (printf, scanf, etc.) The larger mem models C,M,H tend to be smaller in .EXE size and runtime size because of the way they allocate stack and heap space. (I have a 7K .EXE which is in large model and was 200 linees of code...) *From: mnetor!lethe!tvcent!andrew@uunet.uu.net One thing you could try is compiling in the tiny memory model (I don't think that you can use small - chexk the manuals), Then convert it to a .COM file with the DOS program EXE2BIN. (I also seem to recall that there is an option to tlink that generates .COM files when requested in tiny automatically. This may be another compiler?) *From: Tom Wilson <wilson@uhccux.uhcc.Hawaii.Edu> One way to cut down .EXE size: if your program can get by without printf and its relatives, in MSC I can save about 5K. Thus, if your program is a utility that can read/write using low-level (read/write/seek) i/o, and write to the screen with the DOS calls (INT 21H, fns 2/6/7 etc.) then you can cut out some. But to save programming time, I wouldn't do a lot a recoding just to save 4-5K. After all: min size in MS Pascal is approx. 26K, MS Fortran 40K, and Clipper is 160K for "hello, world". If you are writing a bunch of similar utilities, you can save space more easily by combining them and using command line switches. 13K may be the min, but you can cram a lot of code into 20K. Also, disable all checking once the program is debugged: stack overflow, etc. *From: bobc@attctc.Dallas.TX.US (Bob Calbridge) Well, something close to what I've discovered lately. The first thing I've ever done, when using the Tiny (and possibly the Small) memory models is to use the exe2bin utility to convert it to a .com file. However, if you are using the environment to develop your program you might do three different things if they aren't already. The first is to turn off the OBJ debugging information through the Options/Compile/Code_generation option. While there also turn off the Line generation option. Finally, under the Debug menu selection change Source_debugging to Off. Using all of these has chopped a considerable amount of K off a rather large program. I suspect that the amount of savings is based on the size of the program in general and may also relate to the arrangement of the source code. By this I mean that if you have a single statement that has been broken down into two lines like if (such_n_such == TRUE) do_something_stupid(); the executable is generated with information that lets you perform breakpoints for each line. BTW, the program I'm working on is about 67K with debugging information but is reduced to about 52K with all of this turned off. The savings can be substantial. Also, don't forget that some of the standard library functions such as printf() and its relatives (cprintf(), fprintf(), sprintf()) are large by necessity. If you can avoid these by using lesser functions like puts() or by writting your own functions that strip out the unnecessary formatting you can save some space (by unnecessary I mean that printf() also has to account for formattting floating point and double in addition to variable length strings. Even if a program doesn't need to print any floating point value, these options are still part of the printf() function). *From: mdfreed@contact.uucp (large Turbo C executables) Sounds like you're including the debugging information in the executable. This is the default setup in the IDE ... not sure about the command line compiler. If you have Turbo C Professional (includes TASM and TDEBUG), it includes TDSTRIP, a utility to remove the extra data. Otherwise, set the options to eliminate line numbers and debugging info. If you're trying to minimize size, using the individual conversion functions and fputs() instead of fprintf() saves a bit of space. Borland includes an example which uses DOS and BIOS calls, and avoids the library completely. This approach produces the smallest and least portable program (one might say that it isn't really C). Richard T. Ferris ferris@eniac.seas.upenn.edu University of Pennsylvania