|
Message
From: Christian Melki <christian.melki@a...>
Date: Mon, 14 Jul 2003 21:38:47 +0200 (CEST)
Subject: [openrisc] or1200 code size.
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.
chrisme@speed2: /> gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
chrisme@speed2: /> gcc-3.0 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,proto,objc --prefix=/usr
--infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as
--with-gnu-ld --with-system-zlib --enable-long-long --enable-nls
--without-included-gettext --disable-checking --enable-threads=posix
--enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc
i386-linux
Thread model: posix
gcc version 3.0.4
chrisme@speed2: /> cris-gcc -v
Reading specs from
/usr/local/cris/r53/lib/gcc-lib/cris-axis-elf/3.2.1/specs
Configured with: /home/cii/cris-dist-split/./gnu-toplev/configure
--enable-version-specific-runtime-libs --disable-nls
--target=cris-axis-elf --enable-languages=c,c++
--prefix=/usr/local/cris/r53
Thread model: single
gcc version 3.2.1 Axis release R53/1.53
chrisme@speed2: /> mmix-gcc -v
Reading specs from /usr/local/mmix/lib/gcc-lib/mmix/3.2/specs
Configured with: ../gnu-mmix-tools/configure --target=mmix
--prefix=/usr/local/mmix
Thread model: single
gcc version 3.2 20020718 (experimental)
chrisme@speed2: /> or32-uclinux-gcc -v
Reading specs from /opt/or32-uclinux/lib/gcc-lib/or32-uclinux/3.1/specs
Configured with: ../gcc-3.1/configure --target=or32-uclinux
--prefix=/opt/or32-uclinux --local-prefix=/opt/or32-uclinux/or32-uclinux
--with-gnu-as --with-gnu-ld --verbose --enable-languages=c :
(reconfigured) ../gcc-3.1/configure --target=or32-uclinux
--prefix=/opt/or32-uclinux --local-prefix=/opt/or32-uclinux/or32-uclinux
--with-gnu-as --with-gnu-ld --verbose --enable-languages=c
Thread model: single
gcc version 3.1 20020121 (experimental)
chrisme@speed2: /> or32-elf-gcc -v
Reading specs from /usr/local/or32-elf/lib/gcc-lib/or32-elf/3.1/specs
Configured with: ../gcc-3.1/configure --target=or32-elf
--prefix=/usr/local/or32-elf --local-prefix=/usr/local/or32-elf/or32-elf
--with-gnu-as --with-gnu-ld --verbose --enable-languages=c
Thread model: single
gcc version 3.1 20020121 (experimental)
chrisme@speed2: /> or1k-gcc -v
Reading specs from /usr/local/or1k-elf/lib/gcc-lib/or1k/2.95.3/specs
gcc version 2.95.3 20010315 (release)
chrisme@speed2: /> sparc-leon-linux-gcc -v
Reading specs from
/usr/local/leonccs/lib/gcc-lib/sparc-leon-linux/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --target=sparc-leon-linux
--with-gnu-as --with-gnu-ld --prefix=/usr/local/leonccs
--enable-threads=posix --enable-languages=c --disable-shared --disable-nls
--with-headers=/usr/local/leonccs/sparc-leon-linux/include
--with-libs=/usr/local/leonccs/sparc-leon-linux/lib
Thread model: posix
gcc version 3.2.2
Best regards,
Christian M
|
 |
Browse
