[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Some comments on gcc 4.3.2



Hi everybody,

Hello, MiKRO !

today I played with the newest gcc 4.3.2 with the aim to compile native m68kmint binary.

That means you built a native gcc 4.3.2 ?
Wow, I've always wondered if it was possible !

- for some strange reason I had to #define HAVE_GNU_LD to 0 in files gcc/gcc.c and gcc/collect2.c. When I compiled cross compiler, it was OK, it only appears when I compile native gcc using that cross compiler... When I used #ifdef HAVE_GNU_LD if it exists, it does!

Hummm... what was wrong ?

- there's no need to use libm (libpml) anymore -- libmpfr takes care about every math operation. you even don't need libm anymore when compiling your binaries! (I used simple printf("%f", sin(M_PI)) using the cross compiler and the resulting binary compiled & executed in aranym with no problem)

Hehe... You have been fooled by the optimizer ;-)
sin(M_PI) is a constant, so gcc computed the value at compile time (using libmpfr, I suppose), so there is no call to sin() remaining in the final executable, so libm.a is not required.

However, if you call sin() with a global variable for example, the call to sin() will be generated, and a link with -lm will be required, as usual. libm.a is still required for runtime maths.

Note that I originally used PML in my GCC port, because I didn't know fdlibm :-( Of course, PML should be dropped, and fdlibm be used instead, like in GCC 2.95. As an alternative, we may use the libm provided by Newlib: it is derived from fdlibm, it works and it is still maintained. Olivier Landemarre made tests with a FreeBSD libm, too.

- t-mint file it seems is obsolete -- gcc now looks for multilib output of host compiler, so if m68k-atari-mint-gcc cross compiler was compiled with m68020-60 and m68060 support, no matter what I write into t-mint file, libgcc, libstdc++ etc are always in m68020-60 and m68060 versions, too

Nice. But I guess it will always be mandatory for a cross-compiler...

- performance: I measured quake compilation on real CT60@70 MHz machine with -O3 -m68020-60:

gcc 2.95 (68000 version): 7:30 minutes
gcc 4.2.3 (68000 version): 21 minutes
gcc 4.3.2 (68000 version): 23:40 minutes
gcc 4.3.2 (68020-60 version): 22:20 minutes

Longer compilation times is a known problem of GCC 4.
It is the same on other platforms.

quake reported similar problem as with gcc 4.2.x some months ago

I really would be interested in a quick benchmark of Quake compiled with GCC 2.95 and 4.3.2. However, the critical routines of Quake are written in assembly, so a compiler change may not show significant performance change...

Beware: I usually noticed *slower* performance with -O3 than with -O2... Make your own tests !

All at all -- my feelings are quite mixed, 3 times slower compilation, I don't know if this is what I wants to see as default freemint compiler... and that generated code doesn't seems to be much faster anyway.

Having the latest GCC available on MiNT is cool. That means we can use the latest C/C++ features on our favorite platform. However, making the latest GCC 4.X the *default* compiler for MiNT is another story... I'm not sure if there is any benefit to do so.

If anybody interested, I can public the binaries somewhere.

You should publish your work on some website !
I will put a link on my one.

Anyway, congratulations for this native build !
I think you are the first to have compiled and run GCC 4.3.X natively :-)

--
Vincent Rivière