info-vax@ucbvax.ARPA (03/16/85)
From: stew%lhasa@harvard.ARPA
I wonder if anyone has seen and can explain this. I have been working on
a multi-source-file C program (porting C-Kermit to VMS) and some of the
object modules (3 out of maybe a dozen) are huge, maybe 400 blocks from
a 30 block source file. This is not related to the #include files, since
other modules which #include the same header files are appropriately
sized. These huge object modules contain linker commands which form
large tables at the beginning of the $CODE segment for the corresponding
file. The result is about 80K * 3 files = 240K of inexplicable data
in my EXE file.
Ideas anyone?
Stew
rubenstein@harvard.arpa
{ihnp4,seismo,ut-sally}!harvard!rubensteininfo-vax@ucbvax.ARPA (03/16/85)
From: stew%lhasa@harvard.ARPA
Well, thanx to Tony Li <TLI@USC-ECLB> for providing the pointer to
the answer to my question. Should figgered this one out myself.
The offending code was something like:
switch(speed) {
case 300: return(TT$C_BAUD_300);
case 1200: return(TT$C_BAUD_1200);
...
case 19200:return(TT$C_BAUD_19200);
}
You guessed it, Vax-11 C allocated a 19200-entry jump table. I find
this hard to believe. Maybe this fixed in version 2.0. Anyone with
a beta-test version care to comment? Changing one switch statement
in each of the three source files to a multiple if {} else if {}...
reduced them from 406, 595 and 586 blocks to 11, 66 and 63, reduced
the EXE from 646 to 236, and the link time from 100 secs to 24.
Stewrcb@rti-sel.UUCP (Random) (03/19/85)
This is due to switch statements. If the case labels have a large range, there is a large branch table generated for them. This is quite bad when the range is very sparse. Random Research Triangle Institute ...!mcnc!rti-sel!rcb