On Dec 7, 6:45 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
> On 7 Dec., 18:10, waxinwaxout <waxinwax...@hotmail.com> wrote:
>
>
>
> > On Dec 7, 5:04 pm, waxinwaxout <waxinwax...@hotmail.com> wrote:
>
> > > On Dec 7, 4:34 pm, Matthias Buelow <m...@incubus.de> wrote:
>
> > > > waxinwaxout wrote:
> > > > > I can understand there's a difference between RISC and CISC code (more
> > > > > RISC instructions for the equivalent operation on a CISC
> > > > > architecture). I can't understand that this difference is this large.
> > > > > I was hoping this was due to compiler differences or I'm missing some
> > > > > (not so) obvious optimization switch. Or maybe the linker is somewhat
> > > > > different for MIPS.
>
> > > > I don't consider it that large. You obviously haven't seen Alpha AXP
> > > > code. Does it really matter?
>
> > > 3.5 HD floppy size for a binary matters a lot for embedded devices
> > > with limited storage space.
>
> > > WRT Alpha AXP, you've made me curious !
>
> > > I'm currently rebuilding my toolchain without math support.
>
> > Didn't at all. The mips binaries are still large.
>
> > objdump -D <binary>
>
> > produces 351466 lines for the (-Os) mips binary and 275415 lines for
> > the (unoptimized) x86 binary. Both binaries were stripped.
>
> > This means (poor man's calculation approaching):
> > 961600/275415 = 3.49 bytes per instruction for x86 and
> > 1414612/351466 = 4.02 bytes per instruction for mips, give or take
> > some garnish produced by objdump. Note this is really weak calculation
> > as the binary sizes includes non-instructions as well. But the x86
> > hasn't even eliminated duplicate strings which the mips build is
> > doing, and still there's this big/huge difference between the two
> > which I can't ascribe to CISC-RISC differences.
>
> > Are the mips instructions larger than the x86 instructions? Seems like
> > something else is going on. What is it?
>
> > Thanks,
>
> > Miyagi
>
> While I can understand your interest in the size of the binary, I
> really can't understand why you want to bring it up in this newsgroup:
> it is off-topic. ;-)
> What I would recommand you to do is to look at the assembly code for
> some representative function of yours. See if the result is
> implemented in an inefficient way and compare the inefficiency with
> that of the other compiler. If the code generated by the mips compiler
> is to bad, it is time to read the compilers documentation (if you
> haven't done so already!) and perhaps look at other suppliers of
> compilers for that platform if you can't live with the overhead and
> can't get the compiler to produce higher quality code.

Comparing the assembly code is not straightforward. There's (at least)
two different instruction sets. What's inefficient can really only be
empirically determined if one can generate various forms of assembly
all producing the same output (given equal input). Unless there's some
extremely obvious inefficiency, this is somewhat overkill although I
appreciate the suggestion.

Apparently some people get smaller code when not using -Os while using
other immediate/direct compiler optimization switches, but it differs
per source.

I had hoped that someone would have pointed out some major change
between 3.4.6 and 4.1.2, or some (unobvious) compiler switch.

Looking for a gcc group,

thanks,

Miyagi


>
> /Peter