|
Message
From: Matjaz Breskvar <phoenix@f...>
Date: Tue, 15 Jul 2003 00:00:46 +0200
Subject: Re: [openrisc] or1200 code size.
One thing to try is -Os flag to the compiler, used to optimize for
code size. Also if I understood correctly you are compareing code size
on a pretty small project so you should be careful that what you
meassure isn't just a messurment error (maybe on another code
base you'd get pretty much different results). I would guess (could be
very wrong) that a few percent difference on 100Kb binary isn't
statisticaly meaningful.
Nevertheless this is quite interesting, could you post your results...
regards,
p.
* Christian Melki (christian.melki@a...) wrote:
> Hello ppl.
>
> I just recently decided to do a codesize comparision between
> some archs: i386, cris v10, sparc v8, or1000 and mmix.
> Since flash is generally more expensive than ram etc
> I thought that this could be a valid test to make.
> I compiled some toolchains and unpacked a couple of
> binary compiler distributions. With the aim of trying
> to even out the oddities between the compilers etc
> ( beeing different versions and so on ) i generated
> unlinked code since i didn't want to link against a library.
> problem is that the function definitions might be somewhat
> different between libraryheaders etc.. but this should only be
> minor since the code i tried to compile was not to complex.
> before i started i decided on a order of codesize expected
> from the compilers: cris, x86, ( sparc, or1000 same size ), mmix.
> mmix is a 32bit insn 64bit data for those of you that havn't
> heard of the mmix.
> Anyway. The results where both surprising at some times
> and predictable at some times.
> x86 and cris did change positions for smallest binary
> between different codebases.. i suspect that this is because
> generating code for x86 has become very efficient ( with
> regard to gcc in general, not in regard to icc etc) these
> days.. on the whole cris generated the smallest binaries.
> ( beeing the 16-bit insn machine it is ).
> The openrisc compiler did however generate smaller binaries
> than the sparc on a more regular basis.. this was somewhat
> unexpected. I had expected them to be _very_ close.. which
> they also where, but OR1000 keeping the smaller size of them
> two. And MMIX taking up the rear with 64-bit datasizes.
>
> Anyway.. not all people store uncompressed data in flash.
> It is usually compressed in some form.. So i did some
> gzip and bunzip2 compressions on the code generated.
> Here is the funniest part... MMIX beeing the space hog
> it is.. compressed to almost the same sizes as the others..
> When compressing the binaries really hard.. they more
> or less ended up in the same size. EXPECT for the
> or1000 code which always ended up quite a few percent
> higher than the rest.. _really, really_ odd.
> So im asking for your advice here.. Is the OR1000 ISA
> more difficult to compress than for example the SPARC v8 ISA?
> It shouldn't be according to me.. But otoh the compressed
> results do speak a clear language. Something is up,
> and I can't figure out what it is. Suggestions anyone?
> I do know that the factors surrounding this test hasn't been
> perfect.. ;) but it is equal for all archs. why does or1000 generate
> bigger compressed code..?
> Here are the compilers used.
|
 |
Browse
