Mail Archives: djgpp-workers/2001/09/19/04:02:46
> Date: Tue, 18 Sep 2001 16:15:37 +0300 (WET)
> From: Andris Pavenis <pavenis AT lanet DOT lv>
>
> > > Date: Tue, 18 Sep 2001 11:24:42 +0300 (WET)
> > > From: Andris Pavenis <pavenis AT lanet DOT lv>
> > >
> > > I think one of the reasons is code and data alignment. For example
> > > gcc-3.0.1 Linux to DJGPP cross-compiler generates:
> > > '.p2align 4' before procedure code
> > > '.p2align 4,,7' in some other places inside procedure (like
> > > before then begin of loop)
> >
> > I don't think so: in two object files I compared (after "objdump -d"),
> > I counted only 269 nop instructions, which is 269 bytes. That object
> > file was 1.5KB larger when compiled with GCC 3.0.1.
>
> GAS uses not only NOP for alignment, so counting nop instructions doesn't
> show real size increase. Here is an example output from
> 'i586-pc-msdosdjgpp-gcc -c -O2 -Wa,-a ...':
True. So I wrote an awk script (available upon request) which found
all the real alignments and computed the sum total of their sizes.
I've run that on the file main.S, produced from main.c in the Make
distribution with a GCC command line such as above, and the script
reported 709 bytes of align-related bloat. This doesn't seem anywhere
near to the amount we need to explain, since the size of main.o when
compiled with GCC 3.0.1 is some 5KB more than the result of
compilation with GCC 2.7.2.1.
(Of course, it's possible that my script has a bug ;-)
Perhaps someone could try compiling Make on GNU/Linux, where I believe
the alignment issues didn't change much between the old and the new
GCC versions.
- Raw text -