GCC 6.2 toolchain for AmigaOS 3

[bebbo]

Originally Posted by bebbo

-Os uses a different optimizer pass named "hoist" instead of "pre".

Maybe you can reach almost the code size of -Os by using -O1 plus disabling some of the size expensive optimizations.

register parameters are now recognized correctly. -Os is working as intended.

[Samurai_Crow]

When trying to cross compile LibOgg on a 64-bit Linux box, I ran into this in the configure script:

checking for inttypes.h... (cached) no
checking for stdint.h... (cached) no
checking for sys/types.h... (cached) no
checking for an ANSI C-conforming const... yes
checking size of int16_t... 0
checking size of uint16_t... 0
checking size of u_int16_t... 0
checking size of int32_t... 0
checking size of uint32_t... 0
checking size of u_int32_t... 0
checking size of int64_t... 0
checking size of short... 0
checking size of int... 0
checking size of long... 0
checking size of long long... 0
configure: error: No 16 bit type found on this platform!

My configure line was as follows:

../submodules/libogg-1.3.2/configure --host=x86_64-unknown-linux --build=m68k-amigaos --target=m68k-amigaos --prefix=/home/samuraicrow/amigaos-cross-toolchain/m68k-amigaos CC=/home/samuraicrow/amigaos-cross-toolchain/m68k-amigaos/bin/m68k-amigaos-gcc CFLAGS="-noixemul -m68020 -mtune=68020-40 -msoft-float -mpcrel" CPP=/home/samuraicrow/amigaos-cross-toolchain/m68k-amigaos/bin/m68k-amigaos-cpp LDFLAGS="-L/home/samuraicrow/amigaos-cross-toolchain/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b"

It looks like a stdint.h is missing. Where do I get it from?

[bebbo]

Originally Posted by Samurai_Crow

When trying to cross compile LibOgg on a 64-bit Linux box, I ran into this in the configure script:

My configure line was as follows:


It looks like a stdint.h is missing. Where do I get it from?

Try -mcrt=clib2 instead of -noixemul.

Once ixemul.library is built working again, stdint.h will be included and no option is required. Maybe I'll add it to noixemul too...

Many TODO's ...

[matthey]

Originally Posted by Toni Wilen

I forgot that -Os is AROS m68k default. -O1 just fits (only 13k free, vs -Os which leaves ~70k free), -O2 does not fit (26k too big). I haven't done any performance tests. (Note that debugging was disabled but serial logging is enabled)

So 68k AROS defaults to the slowest ISA choice and slowest optimization choice possible. It's not like anybody complains about the performance of 68k AROS .

Originally Posted by bebbo

Maybe you can reach almost the code size of -Os by using -O1 plus disabling some of the size expensive optimizations.

With old versions of GCC, -O1 generated code on the 68k was not very optimized and looked like it was generated for a debugger (unnecessary writes to variables in memory). Moving to -O2 fixed this and was greatly improved but with much more function inlining and loop unrolling that reduces code density (enlarges code). Function inlining is especially good for performance on the 68k with its stack arg AT&T ABI (one study showed 7% average integer performance gain). Your performance optimizations could allow for higher optimization levels if they also improve code density (not unusual on the 68k). I would be interested to know the stripped executable sizes of compiled benchmarks compared to the original GCC. The information could improve AROS by allowing for more performance optimizations if there is any significant amount of improvement in code density. Of course, in Toni's case, compiling for the 68020 would recover some space while improving performance as well. I wonder what percentage of AROS 68k users are using a 68000?

[wawa]

Originally Posted by matthey

So 68k AROS defaults to the slowest ISA choice and slowest optimization choice possible. It's not like anybody complains about the performance of 68k AROS .

of course. we are still testing and debugging. toni is against optimisation at this point. you can likely take it for granted that it will be faster when compiled for 020 when its ready for the consumers. im currently running it on a4000/040/16mb/aga and the apps are reasonably responsive. just watching fireworks demo on aga, as i write

maybe later this week, we can look into compiling a more optimized version.

[matthey]

Originally Posted by wawa

of course. we are still testing and debugging. toni is against optimisation at this point. you can likely take it for granted that it will be faster when compiled for 020 when its ready for the consumers. im currently running it on a4000/040/16mb/aga and the apps are reasonably responsive. just watching fireworks demo on aga, as i write

Optimizing for size is optimizing too. Optimizing with -Os is probably less tested so there could be more bugs though.

[wawa]

Originally Posted by matthey

Optimizing for size is optimizing too. Optimizing with -Os is probably less tested so there could be more bugs though.

i think you realize that optimizing for size may be mandatory in case of kickstart modules in order to fit them within the available space at all.

if you look at the commit history just these days toni had to move ata device from the primary into the secondary kickstart image as we started to have issues with the primary kickstart growing to an inadequate size.

but i think he may explain it better if need be and we are moving offtopic here. if you have consideratiion about aros optimisations i have opened a thread ybout how to compile it here:

http://eab.abime.net/showthread.php?...s+instructions

[Samurai_Crow]

Originally Posted by bebbo

Try -mcrt=clib2 instead of -noixemul.

Once ixemul.library is built working again, stdint.h will be included and no option is required. Maybe I'll add it to noixemul too...

Many TODO's ...

Commented and attached config.log on issue 17 for linkage problems: https://github.com/bebbo/amigaos-cro...hain/issues/17

[paraj]

EDIT: Got it built using latest version.

Late to the party and trying to get it compiling on 32-bit cygwin on Windows 10 I'm getting an internal compiler error while compiling libstdc++. I can see a bit earlier in the thread that libstdc++ isn't supported yet, but that's only once everything's done right?

I'll gladly go through the motions of reporting it properly, but I just want to check whether it's supposed to work at all? Can I disable building libstdc++ for now? (--help didn't seem to indicate any way to do so)

Just in case I've attached a build log (contains multiple runs appended).

[bebbo]

PUSH - a clean build went through and all my tests were ok. The current compiler (not linker) related issues are fixed (even -Os for poseidon.library)

If there are errors, check the existing issues or (re-)open one at github: https://github.com/bebbo/amigaos-cross-toolchain/issues

Thank you all for your interest and support - especially to the one who donated me a fair amount. That is helping me to put more effort into the good old Amiga world.

PS: Uh-Oh - found a bug^^

PPS: Ok - pushed also a fix for this. All good! Yes? No?

[wawa]

Originally Posted by wawa

still trying to source down the issue why stdio linked amiga-gcc6 binaries crash aros68k here. funny enough en course of testing have compiled mui test with the aros-gcc6 and it worked, not unexpectedly i suppose.

btw i wanted to report that the issue above i mentioned in post #153 has been fixed. it must have been the semaphore issue tracked down a while back.

all helloworld examples compiled with 6.2 work fine now under aros.

[bebbo]

Originally Posted by wawa

btw i wanted to report that the issue above i mentioned in post #153 has been fixed. it must have been the semaphore issue tracked down a while back.

all helloworld examples compiled with 6.2 work fine now under aros.

it's 6.3.1 now (to be precise: 6.3.1b)

[wawa]

errm, sorry, no offence meant.
have not even noticed, silly me.

[Keir]

This is totally awesome work! I'm going to try moving from my unmodified upstream GNU toolchain to this, the code quality seems much much better even for cases I don't care about the AmigaOS 3 compatibility.

I can see this being the new standard C compiler for Amiga (for those who cross-compile!).

Oh, by the way I didn't see anyone mention yet that this now builds in 64-bit environments. No need for 32-bit compat libs or Docker container!

[alkis]

Minor tip for path handling. (linux targeted)

If you have a prior gcc like I do you probably have this in your .bashrc

export PATH=$PATH:/usr/local/amiga/bin

now if you compile beebo's gcc, you might reference it with absolute path and the like, but here is a solution

prepend the above line in your .bashrc with one line

export ORIGPATH=$PATH
export PATH=$PATH:/usr/local/amiga/bin

and add two functions at the bottom on your .bashrc

amigaold () {
    export PATH=$ORIGPATH:/usr/local/amiga/bin
}

amiganew () {
    export PATH=$ORIGPATH:/home/alex/amiga/gcc6/bin
}

Now, type amiganew and you have the new gcc in path, type amigaold and you are back at the old one.

[bebbo]

I just released a new version with a new optimizer pass to (e)liminate redundant loads.

Again only little gain here and there, but overall I am quite content now.

I'll add soon the last optimizer to use more auto increments. Then maybe improve some of my already built optimizers, then - I think - I'm done.

How is my gcc-6 version working for you?

[alpine9000]

Originally Posted by bebbo

I just released a new version with a new optimizer pass to (e)liminate redundant loads.

Again only little gain here and there, but overall I am quite content now.

I'll add soon the last optimizer to use more auto increments. Then maybe improve some of my already built optimizers, then - I think - I'm done.

How is my gcc-6 version working for you?

I wonder if we are ready to declare that bebbo's port produces the highest quality asm of any C compiler ever released for Amiga?

For people that didn't know I use bebbo's version for my game engine:

[ Show youtube player ]

[Toni Wilen]

Originally Posted by bebbo

How is my gcc-6 version working for you?

I am still waiting for instructions how to use it to compile aros-m68k.

I'll even try to help if possible. I don't normally want to know nothing about compiling compilers or setting them up but in this case I think it will be worth the trouble

Originally Posted by wawa

i think you realize that optimizing for size may be mandatory in case of kickstart modules in order to fit them within the available space at all.

It may make sense to compile arosbootstrap image with higher optimization level and only compile rom images with -Os. (I don't know how to do that)

[bebbo]

Originally Posted by Toni Wilen

I am still waiting for instructions how to use it to compile aros-m68k.
...

Hehe - the aros build system is not fool proof.

The first hurdle is that the standard approach

--target=m68k-amigaos

fails. Because of a jodeldiplom you have to use

--target=amiga-m68k

... I am still at the very beginning of building aros and again it's a pita.

/cheers

PS: next hurdle is: do not use configure with a relative path - since readlink -f is not used...

[wawa]

maybe we should open a separate thread to share experience about compiling aros with bebbos backend, in order not to derail this thread. i had my go at that but a bit hacky admittedly, trying to edit the target.cfg for the time being. i think we need coorinated common approach. perhaps kalamatee can advise us as he is responsible for the build system and has registered here already.

alternatively we can follow the subject on aros-dev ml. bebbo has already opened this topic there.