toma@tekgvs.GVS.TEK.COM (Tom Almy) (01/26/89)
In article <13872@cup.portal.com> David_Yoshio_Macias@cup.portal.com writes: >> 4)[...] reports that TC2.0 generated code is >> 10%-20% larger than TC1.5 generated code. Hmmmmm.... > >There might be a simple explanation for these reports. When you >compile from the integrated environment, [...] Not that simple. I noticed the increase in size, and I always use the command line compiler. So I keep 1.5 around for "production" use, and for its nicer licensing requirements. Tom Almy toma@tekgvs.tek.com Standard Disclaimers Apply
bobmon@iuvax.cs.indiana.edu (RAMontante) (01/27/89)
<4547@tekgvs.GVS.TEK.COM> toma@tekgvs.GVS.TEK.COM (Tom Almy): > >>> 4)[...] reports that TC2.0 generated code is >>> 10%-20% larger than TC1.5 generated code. Hmmmmm.... > >Not that simple. I noticed the increase in size, and I always use the >command line compiler. So I keep 1.5 around for "production" use, and >for its nicer licensing requirements. I believe that the command-line compiler, tcc, also includes the debugger information by default. I recently played around with this, and found that a program that was around 62K under TCv1.5 was 78K under both tc and tcc (in v2.0), unless I turned off the debugger options. Turn 'em off, and the executable was 61K -- smaller than under v1.5. The relevant command-line option for tcc is "-v-". This turns off some stuff that is included for the stand-alone debugger (not the integrated debugger), and although the default isn't indicated, it appears to be "ON".
schanck@puffer.cis.ohio-state.edu (Christopher Schanck) (01/27/89)
In article <4547@tekgvs.GVS.TEK.COM> toma@tekgvs.GVS.TEK.COM (Tom Almy) writes: >command line compiler. So I keep 1.5 around for "production" use, and >for its nicer licensing requirements. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ could somebody elaborate on this? For all the e-mail responses I got concerning pros/cons, nobody said boo about this. > >Tom Almy >toma@tekgvs.tek.com >Standard Disclaimers Apply -=- "I do not THINK in regular expressions, and I am not NP-complete!" --- Christopher Schanck, occasional human being. schanck@.cis.ohio-state.edu
alexande@drivax.DRI (Mark Alexander) (01/28/89)
Are you folks really sure that Turbo C 2.0 generates larger objects? Comparing the file size is almost (but not quite) meaningless, because there's a lot more in a .OBJ file than raw code: debugging information, for example. You need to find out the actual size of the code segment in a .OBJ file to make accurate comparisons of compilers. I have a program that reads object files and prints this sort of information, if anybody is interested. -- Mark Alexander (amdahl!drivax!alexande)
schanck@harmonica.cis.ohio-state.edu (Christopher Schanck) (01/29/89)
In article <4197@drivax.DRI> alexande@drivax.UUCP (Mark Alexander) writes: > >Are you folks really sure that Turbo C 2.0 generates larger objects? >Comparing the file size is almost (but not quite) meaningless, because >there's a lot more in a .OBJ file than raw code: debugging information, >for example. > >You need to find out the actual size of the code segment in a .OBJ >file to make accurate comparisons of compilers. I have a program that >reads object files and prints this sort of information, if anybody >is interested. I would disagree with this. If you set the compiler switches so it will put no unnecessary info in, the bottom line is .EXE size. It does depend on what you consider necessary, for instance, I always test for stack overflow, but the bottom line for compilers is the .EXE size with equivalent info. >Mark Alexander (amdahl!drivax!alexande) Chris -=- "I do not THINK in regular expressions, and I am not NP-complete!" --- Christopher Schanck, occasional human being. schanck@.cis.ohio-state.edu
alexande@drivax.DRI (Mark Alexander) (01/29/89)
In article <32925@tut.cis.ohio-state.edu> Christopher Schanck <schanck@cis.ohio-state.edu> writes: >... the bottom line for compilers is the .EXE size... But even this is not always true. Some compilers (MetaWare High C, for example) will generate a 20K executable for "hello world" programs, if you don't use some little tricks at link time, while Turbo and Datalight produce much smaller EXE files. Yet High C produces smaller code, on the average, than either of the latter. The reason for this is that the EXE file includes all sorts of code from the runtime library. The size of this code is highly dependent upon how clever and industrious the writers of the library were. MetaWare is great on code generation, but their runtime library bites the wax tadpole. EXE files also may differ in size depending on whether the particular compiler used supports the idea of a BSS or UDATA segment to store uninitialized variables. Both Turbo and Datalight zero the BSS section at runtime, so it doesn't take up any room in the EXE file. But MetaWare doesn't. So if you declare an 30K byte static array in your program, your EXE file will be 30K larger with MetaWare than with Turbo. That 30K array appears in the EXE file as a bunch of zeroes. Microsoft gets around this problem with their EXEPACK utility. Yet another item that increases EXE file size is debugging information used by CodeView (I don't know about Turbo Debugger). The bottom line when comparing code size is the size of the code segment in an individual OBJ file. -- Mark Alexander (amdahl!drivax!alexande)
schanck@harmonica.cis.ohio-state.edu (Christopher Schanck) (01/30/89)
In article <4205@drivax.DRI> alexande@drivax.UUCP (Mark Alexander) writes: >In article <32925@tut.cis.ohio-state.edu> Christopher Schanck <schanck@cis.ohio-state.edu> writes: >>... the bottom line for compilers is the .EXE size... > >But even this is not always true. Some compilers (MetaWare High C, >for example) will generate a 20K executable for "hello world" >programs, if you don't use some little tricks at link time, while >Turbo and Datalight produce much smaller EXE files. Yet High C >produces smaller code, on the average, than either of the latter. But I *said* to compare .exe sizes, you *had* to use all the little tricks at your disposal in order to be fair. From an enduser's standpoint, which is what matter's wrt commercial programs, file size is the cat's meow. >The reason for this is that the EXE file includes all sorts of code >from the runtime library. The size of this code is highly dependent >upon how clever and industrious the writers of the library were. >MetaWare is great on code generation, but their runtime library bites >the wax tadpole. Again, I would say poor libraries are a reflection on the whole compiler package. Since most of us don't have the luxury of multiple libraries, the quality of a compiler's libraries are important aspect of the compiler. > [ BSS and UDATA discussion ] See point 1. >Yet another item that increases EXE file size is debugging information >used by CodeView (I don't know about Turbo Debugger). This has been covered before. >The bottom line when comparing code size is the size of the code >segment in an individual OBJ file. Well, so we argue. I think this discussion has really run its course; this is obviously a fairly personal issue. Next we will be discussing pros/cons of various looping structures! >Mark Alexander (amdahl!drivax!alexande) -=- "I do not THINK in regular expressions, and I am not NP-complete!" --- Christopher Schanck, occasional human being. schanck@.cis.ohio-state.edu
toma@tekgvs.GVS.TEK.COM (Tom Almy) (01/30/89)
In article <4197@drivax.DRI> alexande@drivax.UUCP (Mark Alexander) writes: > >Are you folks really sure that Turbo C 2.0 generates larger objects? >Comparing the file size is almost (but not quite) meaningless, because >there's a lot more in a .OBJ file than raw code: debugging information, >for example. [...] In my case, I noticed the .EXE files were larger, then I compared the code sizes reported in the .MAP files to verify. You can't compare the OBJ or EXE sizes and be sure, since even the EXE files contain relocation information that is not part of the objects, and the way the stack and data areas are set up can also effect the size. Tom Almy toma@tekgvs.TEK.COM