Why is my GNU-based m68k program too big?

Why is my GNU-based m68k program too big?

[Christopher Bahns]

Hello,

I am converting a program (based on the MC68306) from the Microtec
Research (MRI) compiler to the GNU compiler. Things in general are going
pretty well, but I'm having a problem: The size of the code generated by
GNU is too big to fit in my flash memory, whereas the code generated by
MRI does fit.

I have 96k of flash available. The MRI-built program uses all but the
last 2572 bytes, so it is rather close to reaching the limit. However,
the GNU-built program is 11080 bytes over limit, causing my link to
fail. The total difference in sizes between the two compilers is 13652
bytes, or an increase of 14.3% when going from MRI to GNU. These numbers
just apply to the executable code, which is the ".text" section with
GNU, and with MRI it is the combination of the "code", "const",
"literals", "strings", "??INITDATA", and "ioports" sections. The others
sections are ok, but the general trend seems to be that if two
corresponding sections are not the same size, the GNU version is always
bigger. In this particular case it is too big for my program to work.

My configuration: Windows 98SE, Cygnus Cygwin 1.0, binutils-2.9.1
(patched), gcc-2.95.2, newlib-1.8.2, target=m68k-coff.

I built the compiler myself without modifying the default configuration
for this target. When building my program I use the "-O2" option, which
makes the program quite small in comparison to other optimization
settings ("-O3" is larger, and "-Os" is only slightly smaller). I'm not
sure whether it's the difference in the sizes of the project's
functions, or those of the MRI and GNU run-time libraries that are
linked in. But, I suspect that it's the run-time libraries since the
project's functions are built from essentially the same source. The
differences in the compilers may account for a small difference here,
but I assume that if the source code is identical, that the size of code
generated by GNU (with level 2 optimizations) should be very near the
size of code generated by MRI.

So, I'll assume that it's the difference in the implementation of the
run-time libraries. But, how do I proceed? Has anyone else had this
problem, or been at all concerned about the sizes of the executables
generated by the GNU compiler (particularly for m68k targets)? I think
I'll try to rebuild the compiler with the "-O2" option and see if that
makes a difference. Has anyone done this, or have any insight into
whether the resulting libraries will work, or whether the optimizations
will make a significant difference?

Thanks a lot for any help. The help that I've gotten here so far has
been very helpful.
Chris

Re: Why is my GNU-based m68k program too big?

[Kai Tuschner]

Christopher Bahns wrote:

> Hello,
>
> I am converting a program (based on the MC68306) from the Microtec
> Research (MRI) compiler to the GNU compiler. Things in general are going
> pretty well, but I'm having a problem: The size of the code generated by
> GNU is too big to fit in my flash memory, whereas the code generated by
> MRI does fit.
>
> I have 96k of flash available. The MRI-built program uses all but the
> last 2572 bytes, so it is rather close to reaching the limit. However,
> the GNU-built program is 11080 bytes over limit, causing my link to
> fail. The total difference in sizes between the two compilers is 13652
> bytes, or an increase of 14.3% when going from MRI to GNU. These numbers
> just apply to the executable code, which is the ".text" section with
> GNU, and with MRI it is the combination of the "code", "const",
> "literals", "strings", "??INITDATA", and "ioports" sections. The others
> sections are ok, but the general trend seems to be that if two
> corresponding sections are not the same size, the GNU version is always
> bigger. In this particular case it is too big for my program to work.
>
> My configuration: Windows 98SE, Cygnus Cygwin 1.0, binutils-2.9.1
> (patched), gcc-2.95.2, newlib-1.8.2, target=m68k-coff.
>
> I built the compiler myself without modifying the default configuration
> for this target. When building my program I use the "-O2" option, which
> makes the program quite small in comparison to other optimization
> settings ("-O3" is larger, and "-Os" is only slightly smaller). I'm not
> sure whether it's the difference in the sizes of the project's
> functions, or those of the MRI and GNU run-time libraries that are
> linked in. But, I suspect that it's the run-time libraries since the
> project's functions are built from essentially the same source. The
> differences in the compilers may account for a small difference here,
> but I assume that if the source code is identical, that the size of code
> generated by GNU (with level 2 optimizations) should be very near the
> size of code generated by MRI.
>
> So, I'll assume that it's the difference in the implementation of the
> run-time libraries. But, how do I proceed?

You might use the size command to figure out if the gcc is larger than the MRI
compiled version of your function (e.g. >>size my_func.o). This might answer the
question if the standard libraries or your object file is the cause of the over
size.

> Has anyone else had this
> problem, or been at all concerned about the sizes of the executables
> generated by the GNU compiler (particularly for m68k targets)? I think
> I'll try to rebuild the compiler with the "-O2" option and see if that
> makes a difference. Has anyone done this, or have any insight into
> whether the resulting libraries will work, or whether the optimizations
> will make a significant difference?
>
> Thanks a lot for any help. The help that I've gotten here so far has
> been very helpful.
> Chris
>
>   ------------------------------------------------------------------------
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com