GCC 6.2 toolchain for AmigaOS 3

[Thorham]

Originally Posted by matthey

I expect it is generally better to inline strcpy() where it is called than unroll strcpy()

This code can be both inlined and unrolled at the same time.

Originally Posted by matthey

It is much more useful to return a pointer to the end of the string like stpcpy().

What's more useful depends on what's needed and how the function is called.

[matthey]

Originally Posted by Thorham

This code can be both inlined and unrolled at the same time.

True. But...

o Inlining helps more with short strings and unrolling more with long strings. Strings tend to be short thus unrolling may be unnecessary.

o Inlining generally gives smaller code than the push/bsr/rts/pop of the AT&T ABI function call so is faster and smaller. Unrolling gives more code which can be bad for ICache usage and wastes memory. Inlining unrolled loops could result in substantially larger program sizes.

o String processing is rarely the bottleneck anyway (unless the compiler does an awful job of optimizing string handling ).

Originally Posted by Thorham

What's more useful depends on what's needed and how the function is called.

True again, but it is not so simple for compilers to figure out what is needed. Compilers generally need intrinsic and profiling information or they are ignorant but most programmers ignore this and expect them to figure out what they meant. Of course this is a separate problem than compilers not being able to do basic backend code generation right .

Admittedly OT here, but some folks in this thread appear to be the right ones to ask...so..

I've been writing code in C for a long time. However, I'm completely unfamiliar with the assembly it compiles into. Can someone recommend a good online class or reading material to help me learn this? A friend mentioned taking a class at some point whereby they actually wrote a C compiler in assembly, but he did it at his university and as such it isn't available to me. I'd be curious to do something like that. Thanks!

[Thorham]

Originally Posted by matthey

True. But...

o Inlining helps more with short strings and unrolling more with long strings. Strings tend to be short thus unrolling may be unnecessary.

o Inlining generally gives smaller code than the push/bsr/rts/pop of the AT&T ABI function call so is faster and smaller. Unrolling gives more code which can be bad for ICache usage and wastes memory. Inlining unrolled loops could result in substantially larger program sizes.

o String processing is rarely the bottleneck anyway (unless the compiler does an awful job of optimizing string handling ).

Very true, which is why you should be able to specify what you want per function call when needed, or use a default setting when it doesn't matter.

Originally Posted by matthey

True again, but it is not so simple for compilers to figure out what is needed. Compilers generally need intrinsic and profiling information or they are ignorant but most programmers ignore this and expect them to figure out what they meant. Of course this is a separate problem than compilers not being able to do basic backend code generation right .

This isn't up to the compiler. A good example is when you want a string copy that returns a pointer to the end of string character of the copy, which is useful for string concatenation. You either write the function, or see if there's one in the standard library.

[alkis]

Originally Posted by esc

Admittedly OT here, but some folks in this thread appear to be the right ones to ask...so..

I've been writing code in C for a long time. However, I'm completely unfamiliar with the assembly it compiles into. Can someone recommend a good online class or reading material to help me learn this? A friend mentioned taking a class at some point whereby they actually wrote a C compiler in assembly, but he did it at his university and as such it isn't available to me. I'd be curious to do something like that. Thanks!

There is this https://godbolt.org/g/aa9FDd

On how a compiler works this might be of help http://compilers.iecc.com/crenshaw/

[matthey]

Originally Posted by esc

I've been writing code in C for a long time. However, I'm completely unfamiliar with the assembly it compiles into. Can someone recommend a good online class or reading material to help me learn this? A friend mentioned taking a class at some point whereby they actually wrote a C compiler in assembly, but he did it at his university and as such it isn't available to me. I'd be curious to do something like that. Thanks!

Many of the "free" compiler design texts are rather old but can be fine for learning the basics. The Basics of Compiler Design is fairly modern and in depth.

Basics of Compiler Design
http://www.diku.dk/hjemmesider/ansat...sics_lulu2.pdf

It is always good to look at and play with some code too. The vbcc compiler source is fairly modern, advanced, has few dependencies (it compiles on my Amiga) and is written in C. The vbcc source, documentation and binaries are at the following link.

http://sun.hasenbraten.de/vbcc/

The GCC C source is available but a complex mess and full of dependencies. Clang/LLVM is written in C++ and has no official or finished 68k backend. The Amiga DICE source is in C and available but it is old and rather basic.

It is probably necessary to learn some basic assembly language and study the compiler output to fully understand the process. Various debuggers and disassemblers are available to disassemble compiled programs (ask if needed). The M68000PRM is the basic guide for the 68k ISA (now with spiffy NXP text).

http://www.nxp.com/assets/documents/.../M68000PRM.pdf

Thanks matthey!

[alkis]

Ok, I took the sources from the chess engine TSCP ( http://www.tckerrigan.com/Chess/TSCP/ )
and compiled them with sas/c, gcc and vbcc.

Tscp has an embedded benchmark. I lowered the 'max_depth' from 5 to 3, cause you know....amiga. And run the three executables produced from the three compilers.

gcc-3.4.0 19 secs
sas/c 25secs
vbcc 35secs.

gcc: m68k-amigaos-gcc -m68020 -O3 -fomit-frame-pointer -noixemul -o tscpgcc *.c
vbcc: vc +aos68k -O4 -o tscpvbcc *.c -I/usr/local/amiga/m68k-amigaos/sys-include/ -lmieee -cpu=68020
sas: see scoptions inside archive

All the above were run in fs-uae inside a vm so the absolute numbers probably shouldn't mean a thing, still the ratios should be good.

Included is the archive of sources, if you want to play with it. You run the executable, type 'bench' and wait. When it's finished type 'bye' to exit.

[bebbo]

Originally Posted by bebbo

You need the patched binutil-2.14 which is in the toolchain:

./toolchain-m68k --gcc 6 --binutils 2.14

... it's just a start.

Bebbo

the toolchains is now able to build the libnix library.

The examples hello-ks13 and hello-ks20 do compile and run.

Bebbo


PS and gcc 6 / binutils 2.14 are the default setting now

[Marlon_]

Originally Posted by bebbo

the toolchains is now able to build the libnix library.

The examples hello-ks13 and hello-ks20 do compile and run.

Bebbo


PS and gcc 6 / binutils 2.14 are the default setting now

Awesome news! =)

[bebbo]

Originally Posted by alkis

Ok, I took the sources from the chess engine TSCP ( http://www.tckerrigan.com/Chess/TSCP/ )
and compiled them with sas/c, gcc and vbcc.

Tscp has an embedded benchmark. I lowered the 'max_depth' from 5 to 3, cause you know....amiga. And run the three executables produced from the three compilers.

gcc-3.4.0 19 secs
sas/c 25secs
vbcc 35secs.

gcc: m68k-amigaos-gcc -m68020 -O3 -fomit-frame-pointer -noixemul -o tscpgcc *.c
vbcc: vc +aos68k -O4 -o tscpvbcc *.c -I/usr/local/amiga/m68k-amigaos/sys-include/ -lmieee -cpu=68020
sas: see scoptions inside archive

All the above were run in fs-uae inside a vm so the absolute numbers probably shouldn't mean a thing, still the ratios should be good.

Included is the archive of sources, if you want to play with it. You run the executable, type 'bench' and wait. When it's finished type 'bye' to exit.

Right now it compiles with gcc6, but links only if multiple symbols are suppressed

 m68k-amigaos-gcc -m68020 -O3 -fomit-frame-pointer -noixemul -o tscpgcc *.c -Xlinker  --allow-multiple-definition

and crashes :-(


Bebbo

[bebbo]

Originally Posted by Marlon_

Awesome news! =)

Don't expect to much. But I'm still on it.

Bebbo

[alkis]

Originally Posted by bebbo

the toolchains is now able to build the libnix library.

The examples hello-ks13 and hello-ks20 do compile and run.

Bebbo


PS and gcc 6 / binutils 2.14 are the default setting now

Ummm, as in you can actually run the exe on amiga 500 with kickstart1.3???!!!!

Btw, thanks for your work.

[alkis]

Originally Posted by bebbo

Right now it compiles with gcc6, but links only if multiple symbols are suppressed

 m68k-amigaos-gcc -m68020 -O3 -fomit-frame-pointer -noixemul -o tscpgcc *.c -Xlinker  --allow-multiple-definition

and crashes :-(


Bebbo

What symbols it complains about? Possible to attach the log?

Bebbo, I am still having issues compiling under macOS Sierra. I filed an issue for some common bits I overcame but I'm now getting this:

: --statistics -o po/zh_TW.gmo /Volumes/Code/amigaos-cross-toolchain/submodules/gcc-6/gcc/po/zh_TW.po
/usr/bin/clang++ -m32 -std=gnu++11   -g -O2 -Wall -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE   -o build/genmddeps \
    build/genmddeps.o build/read-md.o build/errors.o ../build-i686-linux-gnu/libiberty/libiberty.a
ld: illegal text-relocation to '___stdoutp' in /usr/lib/libSystem.dylib from '_main' in build/genmddeps.o for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [Makefile:2691: build/genmddeps] Error 1
make[1]: Leaving directory '/Volumes/Code/amigaos-cross-toolchain/.build-m68k/build/gcc-6/gcc'
make: *** [Makefile:4139: all-gcc] Error 2
ERROR: command "make all-gcc CFLAGS_FOR_TARGET=-noixemul MAKEINFO=makeinfo -j1" failed with 2

Any ideas?

[alpine9000]

Originally Posted by nyteshade

Bebbo, I am still having issues compiling under macOS Sierra. I filed an issue for some common bits I overcame but I'm now getting this:

: --statistics -o po/zh_TW.gmo /Volumes/Code/amigaos-cross-toolchain/submodules/gcc-6/gcc/po/zh_TW.po
/usr/bin/clang++ -m32 -std=gnu++11   -g -O2 -Wall -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE   -o build/genmddeps \
    build/genmddeps.o build/read-md.o build/errors.o ../build-i686-linux-gnu/libiberty/libiberty.a
ld: illegal text-relocation to '___stdoutp' in /usr/lib/libSystem.dylib from '_main' in build/genmddeps.o for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [Makefile:2691: build/genmddeps] Error 1
make[1]: Leaving directory '/Volumes/Code/amigaos-cross-toolchain/.build-m68k/build/gcc-6/gcc'
make: *** [Makefile:4139: all-gcc] Error 2
ERROR: command "make all-gcc CFLAGS_FOR_TARGET=-noixemul MAKEINFO=makeinfo -j1" failed with 2

Any ideas?

I managed to hack thru that error (manually hacked a generated makefile), but then I got a different error later in the build so I gave up.

[bebbo]

Originally Posted by nyteshade

Bebbo, I am still having issues compiling under macOS Sierra.

(...)

Since I don't own a Mac, I can't reproduce (I could get a VM with OSX, but then I'd also need XCode, which requires an account).

I'm not sure, but it looks like the target does match your system:

build-i686-linux-gnu

Does it work, if you build with gcc 2.9.3?

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

Fixed the register usage.
without -mregparm=2 the parameters are passed via stack (again):

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

And yes, the code could be better.

Bebbo

[Thorham]

Why is it so hard to get compilers to produce proper code for simple stuff like this? It absolutely boggles the mind

[bebbo]

Originally Posted by Thorham

Why is it so hard to get compilers to produce proper code for simple stuff like this? It absolutely boggles the mind

Because 68k is poorly and Amiga is not supported?

GCC performs the code generation and optimization with abstract instructions. A meta description/som code describes which operations are available, how they perform and how the assembly syntax looks like.

If that's not complete or the performance information is bogus, the optimal code can't be found.

If the code was still officially supported there were test cases and those bugs were found and fixed.

Now: Find and fix it yourself. You are part of the community.

Bebbo