Re: [MiNT] gcc 68000 vs 68020-60 vs 68060 comparison

[Paul Wratt <paul.wratt@gmail.com>]

On Fri, Jan 15, 2010 at 6:24 AM, Miro Kropacek <miro.kropacek@gmail.com> wrote:
> Hi all,
> this may be a little bit offtopic but it's quite interesting thing,
> especially for users of real machines. For quite a long time I was always
> curious how much influence have various compilation options to the speed of
> compilation. Concretely, impact of 020+ options so this week I've decided to
> make some tests. So here are few notes:
> - I've compiled every dependency with desired options, i.e. gmp, mpfr,
> mintlib, every library and executable in binutils, every library (except
> multilib targets) and executable in gcc were compiled with "-O2
> -fomit-frame-pointer" plus "-m68020-60" or "-m68060"
> - preparation of those binaries finally cleared the libm dependency out and
> that is, it's not needed. Since I needed to recompile also my cross compiler
> (to support m68060 multilib), after my makefile ended, I deleted all traces
> of libm.a in cross compiler setup and started to build m68020-60 & m68060
> binaries. So unless m68000 is some exception, I'd say libm is needed only
> for gmp / mpfr tests on native builds
> - gcc doesn't do very good job with bit operations. my testcase was
> compilation of all mintlib targets and for the testing I used aranym (if my
> binaries works well), everytime compilation finished, I closed aranym and
> guess what most used untranslated instructions were? BFEXTU, BFCLR, BFINS
> etc -- so regardless m68020-60 or m68060, gcc refuses to use registers +
> simple move/and/or operations that are at least 4x faster than horrible
> BFxxx instructions (add the instruction pairing thanks to 2nd pipeline and
> you'll get pretty amazing results when the code is well optimized)
> - compilation of mintlib targets (000, 020, profile, debug) on CT60, 66/16
> MHz, mono res and optimized binutils/gcc:
> 68000: 318m56s
> 68020-60: 293m5s
> 68060: 290m45s
> what is quite interesting (or: disappointing ;-) -- I could swear when I've
> tried gcc3/m68060 on my falcon looong time ago, I could measure 30% speedup
> against gcc3/68000 when compiling quake. So either I was really drunk or
> this new gcc has drastically changed since then or mintlib is not very good
> testcase (since it uses a lot of external stuff) or 68000 optimization in
> general is so damn good there's no space for massive speedups thanks to raw
> CPU power. Hmm, maybe I try to re-compile that quake ;-)
> Btw I've measured also aranym builds, it's about 3x faster than my ct060
> (finally guys! ;-), in % are results nearly identical.
> So as you see, special 68060 target is probably not worth of attention,
> maybe for some special application that uses sinus, cosinus etc heavily
> (instructions emulated on 060) or FPU in general. Except slightly faster
> build with 68020-60 there's one advantage and that is 68020-60/68060 builds
> are significantly smaller (2/3 of 68000 approximately).
> --
> MiKRO / Mystic Bytes
> http://mikro.atari.org
>
There is some good info here Miro, just the sort of thing I was hoping
to do with various versions, but at the moment I am waiting atm...

"68020-60/68060 builds are significantly smaller (2/3 of 68000 approximately)"
hmm, due to better instruction usage maybe, or better instructions on
those CPU's..

I presume this is all gcc 4.2.2 and binutils 2.20..

Is it possible to "fix" the BFxxx issues permanently in anyway?

Is there anything else that would benefit vanilla 68000's, like -O3 or
other size/speed producing optimizations for ST/e binaries

Paul