GCC 6.2 toolchain for AmigaOS 3

[bebbo]

Originally Posted by patrik

What hardware did you run the benchmark on?

WinUAE, 68020, fastest possible, More compatible, NO JIT

And if switch to

WinUAE, 68020, A1200 cycle exact, More compatible, NO JIT

The results differ:

tscpsc:   18920ms
tscpgcc:  14120ms 
tscpvbcc: 14120ms
tscpgcc6: 12280ms

So gcc6 is still the fastest but tscpvbcc is on par.

Guess I have to start my A3000T and test there too^^

Bebbo

[wawa]

btw. probably not the case, but if there is anything to get from it, aros uses currently binutils 2.25 for gcc 6.3.0. if needed for reference, the diffs are to find in the usual locations. what id love to see, however likely too much to hope for, would to be bundling effort to improve amiga-m68k backend being usable for both for aros and aos. i lack though the expertise to contribute to it.

[bebbo]

Originally Posted by wawa

btw. probably not the case, but if there is anything to get from it, aros uses currently binutils 2.25 for gcc 6.3.0. if needed for reference, the diffs are to find in the usual locations. what id love to see, however likely too much to hope for, would to be bundling effort to improve amiga-m68k backend being usable for both for aros and aos. i lack though the expertise to contribute to it.

I wish there were AROS for the m68k, but there isn't. But thank you for pointing it out.

The problems with gcc/binutils are:

1. m68k Amiga register usages: A6 as library base, A5 as frame pointer, A4 as data segment ref.
2. The amiga hunk file format
3. fast ram / chip ram
4. special stuff like resident
5. dunno... guess way more.

The binutils modifications can't be merged easily since many things have changed, but I have an experimental binutils 2.27. And patching binutil 2.14 was easier. (Notice: some bugs I fixed in 2.14 are still present in the current 2.27, so noone really uses that **abandoned** code)

And gcc changed a lot from 3.4.* to 4.0.0. Porting the changes to 4.0.0 is the same effort as porting them to gcc-6, so I started with gcc-6.

Bebbo

PS: I am using the gcc-6 branch, so it's atm "version 6.3.1 20170217 (GCC)"

[wawa]

Originally Posted by bebbo

I wish there were AROS for the m68k, but there isn't.

you really dont know that there actually is aros68k ? i even posted a comparison binary results compiled with it (6.1.0) somewhere further above.

The problems with gcc/binutils are:


1. m68k Amiga register usages: A6 as library base, A5 as frame pointer, A4 as data segment ref.

afaik, on aros this is taken care by a set of macros, similarly/interchengable like with sdi includes. functions that need parametrizing must of course follow certain syntax.

2. The amiga hunk file format

aros binaries are compiled as elf since aros executes both formats and elf is the currently default binary format produced ba the compiler. however aros68k binaries are subsequently converted to hunk with elf2hunk utility while preparing distfiles, and runnable on aos, as long as they dont depend on specific aros libs.

3. fast ram / chip ram

its being taken by the usual memory definition macros (MEMF_FAST and the like).

4. special stuff like resident

dont know details, but must be handled somehow, the kickstart image works after all.

And gcc changed a lot from 3.4.* to 4.0.0. Porting the changes to 4.0.0 is the same effort as porting them to gcc-6, so I started with gcc-6.

Bebbo

yes. thats understandable. btw for reference, except 3.4.x from zerohero there is 4.5.x from bernd rosch on amiga.sf. aros is currently still using 4.6.4 as default and 6.3.0 optionally. btw aros build system is to a certain extent ready for different further compiler options, like llvm/clang and lately some support for linking stage optimization has been introduced. also usage of vbcc/vasm has been evaluated already some time ago, but hasnt delivered expected advantage, so put on hold. toni btw, is much better informed in the matter, assistance needed, since he is/was one of the maintainers.

[bebbo]

Originally Posted by wawa

you really dont know that there actually is aros68k ? i even posted a comparison binary results compiled with it (6.1.0) somewhere further above.

just kidding, I once tried it but not using it.

And I can't find your post: http://eab.abime.net/search.php?searchid=3707779

...
aros is currently still using 4.6.4 as default and 6.3.0 optionally.
...

The 4.6.4 version I found via sourceforge and what's provided in gcc-4.6.4-aros.diff does not provide very much. It's basically:

* support for A4/A5 instead of A5/A6.

Everything else what was in 2.95.3 is missing. And that's plenty.

Or does that exist? Where?

Bebbo

[wawa]

Everything else what was in 2.95.3 is missing. And that's plenty.

thats why i said there might be some refference, but on the other hand it likely needs improvement, which if someone would focus on might be beneficial for both platforms.

the 6.3.0 diff should be actualy alongside 4.6.4 in the repository. ill check in a minute. do you have a diff of your version against the upstream one? might be worth comparing, especially if you introduced further patches. still it would be a job for someone actually experienced. i fear toni doesnt bother with it, but maybe someone else might.

here are all diffs, voila:
https://trac.aros.org/trac/browser/A...ols/crosstools

[Samurai_Crow]

And the GitHub mirror is https://github.com/ezrec/AROS-mirror...ols/crosstools

[wawa]

btw, bebbo, you read german?

here are some comments on the subject, just in case there was something helpful:

http://amiga-news.de/de/news/comment...-00029-DE.html

[bebbo]

Originally Posted by wawa

btw, bebbo, you read german?

here are some comments on the subject, just in case there was something helpful:

http://amiga-news.de/de/news/comment...-00029-DE.html

Uhm German? Guess I do.

Thanks for pointing me/us to that german thread.

Bebbo

[sbergmann]

Originally Posted by sbergmann

I started to work on a Dockerfile for building a Docker image with this toolchain: https://github.com/sebastianbergmann...ter/Dockerfile

It's now usable, see https://amiga.sebastian-bergmann.de/...ross-compiler/ for details.

[bebbo]

Finally an update:

The implementation to support -fbaserel and -fbaserel32 is looking good. The libraries and examples do compile, link and run.

Just pushed my changes.

Bebbo

[alkis]

Anyone can figure out why when I run

./toolchain-m68k --prefix=/home/alex/amiga/gcc6 --gcc 6 --binutils 2.14 build

I get the following errors???

DEBUG: execute "git submodule init"
DEBUG: execute "git submodule update"
fatal: reference is not a tree: 2f126be011f78b6477fc123ba1fb0886822b97f1
fatal: reference is not a tree: 79e2eaa4195f064229a6e5376bb608332c8dcf28
Unable to checkout '2f126be011f78b6477fc123ba1fb0886822b97f1' in submodule path 'submodules/clib2'
Unable to checkout '79e2eaa4195f064229a6e5376bb608332c8dcf28' in submodule path 'submodules/libdebug'
ERROR: command "git submodule update" failed with 1

[bebbo]

./toolchain-m68k --prefix=/home/alex/amiga/gcc6 --gcc 6 --binutils 2.14 build

Maybe you misspelled alex ^^

Nah - just kidding.

Some submodules were forked and are using now a different location. So I suggest running a manual

git pull

. If the error persists, remove the submodules then

./toolchain-m68k clean
./toolchain-m68k --prefix=/home/alex/amiga/gcc6 build

(binutils-2.14 and gcc-6 are the default options now)

Bebbo

[matthey]

Originally Posted by bebbo

Finally an update:

The implementation to support -fbaserel and -fbaserel32 is looking good. The libraries and examples do compile, link and run.

The -fbaserel option is valuable but does anyone really use -fbaserel32? The -fbaserel32 option would cause code to be slower on 68020-68060 as it uses the full extension word format with base displacement size of 32 bits (bd32,An,Rn.Size*Scale). Not only is this addressing mode slower on every 68k CPU but the code is also larger. These relative references would be 2 bytes larger than an absolute reference (the RELOCs for the absolute references may cause the executable size to grow but they do not clog the ICache or reduce performance after the program is loaded). Of course larger is also generally slower on 68k processors. Perhaps there are sometimes where RELOCs in the executable should be avoided but I expect they are rare to non-existent on the Amiga. The -fbaserel32 option should be very low priority and any documentation should clearly state that this option (also probably -resident32) are slow and normally should be avoided.

Which other AmigaOS "unofficial" GCC features have you already added or were you planning on bringing back?

[bebbo]

Originally Posted by matthey

The -fbaserel option is valuable but does anyone really use -fbaserel32? The -fbaserel32 option would cause code to be slower on 68020-68060 as it uses the full extension word format with base displacement size of 32 bits (bd32,An,Rn.Size*Scale). Not only is this addressing mode slower on every 68k CPU but the code is also larger. These relative references would be 2 bytes larger than an absolute reference (the RELOCs for the absolute references may cause the executable size to grow but they do not clog the ICache or reduce performance after the program is loaded). Of course larger is also generally slower on 68k processors. Perhaps there are sometimes where RELOCs in the executable should be avoided but I expect they are rare to non-existent on the Amiga. The -fbaserel32 option should be very low priority and any documentation should clearly state that this option (also probably -resident32) are slow and normally should be avoided.

Which other AmigaOS "unofficial" GCC features have you already added or were you planning on bringing back?

baserel32 is no additional effort if baserel is done, plus you can create huge location independent programs, just combine it with pcrel => no reloc at all.

What features are missing?

Bebbo

[matthey]

Originally Posted by bebbo

baserel32 is no additional effort if baserel is done, plus you can create huge location independent programs, just combine it with pcrel => no reloc at all.

As long as -fbaserel32 is very easy to implement and documented that it is slower in practically every case, then it wouldn't hurt to have it for compatibility. Do PC relative accesses out of 16 bit range (+-32kB) in the code use the 68020 (d32,PC,Rn.Size*Scale) addressing modes (easier but slower and bigger code) or convert to using absolute addressing mode with RELOCs? If GCC converts to using the faster absolute addressing mode then you are unlikely to have RELOC free programs anyway as it is more common for the code of large programs to grow past ~64kB than the static (global) variable data.

I proposed in an enhanced 68k (68kF) ISA to add shorter PC relative addressing modes for (d32,PC) and (d24,PC,Rn.Size*Scale) which could be as fast and as small as using the absolute addressing mode with RELOC. This would allow PC relative code without RELOCs in most cases but it would not be possible to add the same short encodings for (bd,An,Rn.Size*Scale).

Originally Posted by bebbo

What features are missing?

http://cahirwpz.users.sourceforge.ne...aos/index.html

[bebbo]

So missing at the moment:

2.7 -mstackcheck
2.8 -mstackextend
2.9 -mfixedstack
2.10 -mrestore-a4
2.11 -malways-restore-a4
2.13 -frepo

3.1 chip
3.2 saveds
3.3 interrupt
3.4 stackext

Not very important to me :-)

Bebbo

[bebbo]

Originally Posted by nogginthenog

I don't have libnix built yet but GCC 6.2.1 produces this:

_strcpy:
        move.l a2,-(sp) |,
        move.l a0,d0    | dst, dst
        move.l a0,a2    | dst, ivtmp.11
.L2:
        move.b (a1)+,d1 | MEM[base: src_8, offset: 4294967295B], _9
        move.b d1,(a2)+ | _9, MEM[base: _14, offset: 0B]
        jne .L2 |
        move.l (sp)+,a2 |,
        rts

The current version is now producing better code for:

__attribute__((__regparm__(2))) char * strcpy(char *dst, const char *src) {
  char *ret = dst;
  while(*dst++=*src++)
    ;
  return ret;
}

m68k-amigaos-gcc -S -fomit-frame-pointer -O3 strcpy.c -o strcpy.s

_strcpy:
        move.l a0,d0
.L2:
        move.b (a1)+,d1
        move.b d1,(a0)+
        jne .L2
        rts

Still not the best code, but better than previous.

[matthey]

Originally Posted by bebbo

_strcpy:
        move.l a0,d0
.L2:
        move.b (a1)+,d1
        move.b d1,(a0)+
        jne .L2
        rts

Still not the best code, but better than previous.

This is good enough to compete for best 68k code generation quality from any Amiga compiler ever. If the code generation was consistently this good with few bugs, it would be a miracle after all these years.

[alkis]

Originally Posted by bebbo

m68k-amigaos-gcc -S -fomit-frame-pointer -O3 strcpy.c -o strcpy.s

_strcpy:
        move.l a0,d0
.L2:
        move.b (a1)+,d1
        move.b d1,(a0)+
        jne .L2
        rts

A tad better than gcc-3.4.0

#NO_APP
        .text
        .even
        .globl  _strcpy
_strcpy:
        movel a0,d1
        .even
L2:
        moveb a1@+,d0
        moveb d0,a0@+
        jne L2
        movel d1,d0
        rts