News about AROS 68k development?

[wawa]

Originally Posted by OlafSch

If I understand you right building a own fork based on another compiler would be the only realistic chance to move forward?

i dont like that course. we would lose the mutual advantage of direct cooperation,

[OlafSch]

Originally Posted by wawa

i dont like that course. we would lose the mutual advantage of direct cooperation,

You read what Toni wrote? It is almost impossible (or would need huge efforts) to get it running with two different compilers. Perhaps something like ABI0, someone has to "backport" changes from time to time to get it up-to-date again.

68k is not their main interest and I think they have different interests. Many things they work on are uninteresting for 68k on the other side certain things are only partly or not implemented on 68k. If it would be a 68k dedicated branch you would only need to backport changes that are relevant for 68k. Many components like Intuition or Gadtools are working very well already, some parts not (like MESA/Gallium and so on).

Besides what is still not working you can already use Aros 68k very well on emulation but on hardware it is still limited and we either make a step forward or give it up. On FPGA things will hopefully different (at least on fast hardware the limits of Aros will not be so visible).

[Toni Wilen]

Only solution that imho can work is to find other (supported) compiler that is compatible enough with gcc (can use macros etc..) but also has full Amiga-m68k support.

Including some automatic and transparent way for lib init to add bss/copy data section(s) to libbase and access it automatically via a6. It would fix rommable + bss/data compatibility problem completely.

No one cares if already existing (ugly) m68k gcc inline assembly needs to be rewritten. It also does not need to support any non-m68k platform's code. Only generic aros + m68k specific parts.

In my opinion gcc is a dead-end for m68k-amiga support. It can be patched and worked around until you hit next wall and so on..

[wawa]

okay then only way is vbcc? right? can it be set up as default compiler for the amiga-m68k branch, especially as cross compiler on linux server to deliver nightly builds? can the rest of codebase be adopted to support it? i think only 68k inlines would have to be made vbcc compatible first. van vbcc understand the whole build mechanism behind aros, the configures an makefiles as they are? what is perticularly necessary? i think it is like beating a dead horse, but do we need matthey and co to check with us?

[wawa]

@toni
as i said heiroglyph has already come glue code for his reworked c commands, probably nothing you couldnt do yourself, but how about to gather some amiga coders, vbcc and asm experts that walk around here and get it working? matthey would surely help to keep us in contact with vbcc team. but it would be better if you have alled out such an initiative, toni, i know you dont like it, but if i do try that, none will react, and for a reason.

[OlafSch]

Originally Posted by wawa

@toni
as i said heiroglyph has already come glue code for his reworked c commands, probably nothing you couldnt do yourself, but how about to gather some amiga coders, vbcc and asm experts that walk around here and get it working? matthey would surely help to keep us in contact with vbcc team. but it would be better if you have alled out such an initiative, toni, i know you dont like it, but if i do try that, none will react, and for a reason.

If I can help... Toni would of course be more competent there

[wawa]

one of the problems will probably be the multitude of gnu tools aros build system takes advantage of except the compiler itself.

[matthey]

I think it's possible to modify the AROS 68k build system to work with vbcc. I was impressed by a generic register stub system for Amiga library functions that works with GCC, vbcc, SAS/C and even Dice (Thomas Rapp creation?). There may be a significant amount of work adapting the register definitions to the generic format though. I would continue to support GCC. It's possible that the 68k and Amiga support could make a comeback with new fpga hardware. Many of the build tools should work with vbcc. The biggest incompatibilities between GCC and vbcc are the vbcc lack of many built in function and variable attributes and the inline assembler is much different. The former is overly complex and somewhat redundant with C99 improvements. The latter is very powerful and allows for more efficient inlined assembler but would also be a lot of work (the current vbcc inline assembler is simple and easy to use). I suggested to Frank Wille (phx) that it has become a standard (both GCC and LLVM/Clang use it which is most of the world) and it would be nice to support but he didn't comment. It would be best to use standard C and C99 functions where possible (C99 support in vbcc has improved and anything missing needs to be added anyway). Vbcc does have Amiga specific support but it has its own syntax and interfaces. I would need to look into the specifics of problems and I am no expert with compilers and build systems either. I don't know that vbcc would offer any big improvement (no magical optimization fix) but it would be good if building AROS did not require a specific compiler. There isn't a big motivation when there isn't a big advantage though.

[wawa]

@matthey
seems toni considrs it an essential step, and all i can do is but trust his judgement. i have not found any x86 based vbcc crosscompiler build though i remember you have been mentioning. i have cubicide i have never been able to use properly let alone for a complex project but im sceptic towards compiling under 68k at the moment.

edit: perhaps it has to be built for x86 target. would it be possible to use it, say, under cygwin along with the other neccassary gnu tools instead of gcc? or maybe it could be used along with gcc just to compile amiga specific parts and asm inlines.

[Samurai_Crow]

re:LLVM on AROS

There is a Clang 2.9 AROS x86 ABI v0 cross compiler in the AROS repository. The current version of LLVM/Clang is 3.5. The world has been moving on in the meantime. I still have the sources on my hard drive for the Clang 2.9 cross compiler but that code has bit-rotted so bad that we might have to do that code all over again if we do decide to go with LLVM.

I would still recommend LLVM over a new GCC backend at this point due to the modularity of the code. If we hope to ever be able to run LLVM on a 68k Amiga, we'll have to make it store the optimization passes as separate shared libraries so the ones not being used can be flushed out of memory to make room for the next batch.

As a point of reference, linking that Clang cross-compiler on my x86_64 Mac required 2 Gigs of RAM just to link it. The LLVM codebase is larger today. Since LLVM is written in C++, getting it compiled to shared libraries might require OOP.library use from the AROS kernel so that pretty much rules out an AmigaOS 3.1 compatible way to run it.

It'll take a lot of work, as Matthey said, but it'll be worth it since it's not just a C/C++ compiler but a modular framework that can be used from other compilers as well. (GCC started out to be that also but is even more poorly documented than LLVM.)

re:Other compilers
VBCC can generate code for AROS but can't be used to actually compile AROS because AROS uses GCC extensions (that might be supported in Clang by now). It has a better micro-optimization than GCC largely due to the fact that it uses VAsm and VLink as its Assembly backend. I'd sooner use the documentation where it says what optimizations it does than to use this codebase itself, since Volker Barthelmann is busy with other projects.

DICE (Dillan's Integrated C Environment by Matt Dillan, maintainer of Dragonfly BSD) has bitrotted so bad that it's not even useful in this day and age.

SAS/C also generates bad code in certain corner cases (though it has a good debugger) and despite being improved somewhat and rereleased as freeware in version 7, can't be improved by others due to its closed-source status.

[Toni Wilen]

I only say that gcc is not going to get any better for m68k-amiga. Nothing has happened with gcc m68k support since aros-m68k started.

Something else is needed, I have no idea what or don't really care much. I probably can help with this but I am not going to work with tools, I only want to use tools that "just work". (for both aros-m68k and "normal" Amiga m68k)

[phx]

Originally Posted by matthey

I think it's possible to modify the AROS 68k build system to work with vbcc.

Everything is possible, if you put sufficient time and effort into it.

There may be a significant amount of work adapting the register definitions to the generic format though.

IIRC the OS-call inlines are only a part of the problem. The AROS headers are full of gcc specific code.

and the inline assembler is much different. The former is overly complex and somewhat redundant with C99 improvements. The latter is very powerful and allows for more efficient inlined assembler but would also be a lot of work (the current vbcc inline assembler is simple and easy to use). I suggested to Frank Wille (phx) that it has become a standard (both GCC and LLVM/Clang use it which is most of the world) and it would be nice to support but he didn't comment.

Maybe I missed that. But there is also not much to say. Certainly it won't happen until the next release.

It would be best to use standard C and C99 functions where possible

Indeed. That's what standards are made for. To be able to write code which compiles nicely on all C compilers following the standard.
What the AROS developers did was short-sighted. Forcing all developers for your OS to use a specific compiler is not very nice. This is one of the reasons I never did anything with AROS...

Originally Posted by wawa

i have not found any x86 based vbcc crosscompiler build though i remember you have been mentioning.

An experimental version exists.
I did it many years ago, without getting any support from the AROS developers. I had to rewrite all system-call inlines in the OS headers and was able to compile very simple programs at some point. But AROS moved on and changed their headers and ABI again and again, so I lost interest.
Also vbcc's x86 backend is not very mature (nobody ever used it).

[wawa]

@phx
thanks for your attention. i actually mean a version for x86 host and 68k target. a version that could be used on a linux host along with gnu tools to produce 68k binaries. is that possible at all? i am actually completely inexperienced and am just digging up my cubicide under winuae. so far i will just try to compile something simple with vbcc and work myself a little up.

[phx]

Originally Posted by wawa

i actually mean a version for x86 host and 68k target. a version that could be used on a linux host along with gnu tools to produce 68k binaries.

Sure. Volker Barthelmann develops vbcc under Linux/x86.

The vbcc compiler, as well as the assembler and linker, is written in plain ANSI-C. So it can be easily compiled, without any modification, to run hosted on any OS which has a working C compiler.

The last release source from 2011 is available here: http://www.ibaug.de/vbcc/vbcc.tar.gz
For the recent 0.9d beta source, just ask me.

Recent vasm and vlink release and snapshot sources are here:
http://sun.hasenbraten.de/vasm/
http://sun.hasenbraten.de/vlink/

[strim]

a version that could be used on a linux host along with gnu tools to produce 68k binaries. is that possible at all?

I am doing that all the time with VBCC . It works perfectly.

[wawa]

thx, guys, sounds really cool. this was one of the things i was worried about. just checked if my vmware ubuntu setup is still valid.

@strim
so the whole amiga netbsd is compiled with it? promissing.

[wawa]

is there any guide how to compile it on ubuntu, since there is no configure i obviously need to edit makefile by hand. right now i commented out -DHAVE_AOS4, but i guess i need to specify some more parameters. im stuck here:

huhu@huhu:~/vbcc$ make 
gcc -std=c9x -g -v  frontend/vc.c -o bin/vc -lm
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) 
COLLECT_GCC_OPTIONS='-std=c99' '-g' '-v' '-o' 'bin/vc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.7/cc1 -quiet -v -imultiarch i386-linux-gnu frontend/vc.c -quiet -dumpbase vc.c -mtune=generic -march=i686 -auxbase vc -g -std=c99 -version -fstack-protector -o /tmp/ccl27EVc.s
GNU C (Ubuntu/Linaro 4.7.2-2ubuntu1) version 4.7.2 (i686-linux-gnu)
	compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128328
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/4.7/../../../../i686-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-linux-gnu/4.7/include
 /usr/local/include
 /usr/lib/gcc/i686-linux-gnu/4.7/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
GNU C (Ubuntu/Linaro 4.7.2-2ubuntu1) version 4.7.2 (i686-linux-gnu)
	compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128328
Compiler executable checksum: a80a8d5d70f6ac2a366881f8103456bd
frontend/vc.c: In function ‘add_name’:
frontend/vc.c:194:9: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:196:9: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c: In function ‘read_config’:
frontend/vc.c:214:7: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:225:9: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:246:5: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c: In function ‘main’:
frontend/vc.c:448:5: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:449:5: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:450:5: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:451:5: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:507:15: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:573:27: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:577:27: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:583:27: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:623:9: warning: format not a string literal and no format arguments [-Wformat-security]
frontend/vc.c:626:9: warning: format not a string literal and no format arguments [-Wformat-security]
COLLECT_GCC_OPTIONS='-std=c99' '-g' '-v' '-o' 'bin/vc' '-mtune=generic' '-march=i686'
 as -v --32 -o /tmp/ccIzQzSQ.o /tmp/ccl27EVc.s
GNU assembler version 2.22.90 (i686-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.22.90.20120924
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-std=c99' '-g' '-v' '-o' 'bin/vc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.7/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -z relro -o bin/vc /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crt1.o /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crti.o /usr/lib/gcc/i686-linux-gnu/4.7/crtbegin.o -L/usr/lib/gcc/i686-linux-gnu/4.7 -L/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu -L/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib -L/lib/i386-linux-gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/i686-linux-gnu/4.7/../../.. /tmp/ccIzQzSQ.o -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-linux-gnu/4.7/crtend.o /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crtn.o
/usr/bin/ld: cannot open output file bin/vc: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [bin/vc] Error 1
huhu@huhu:~/vbcc$

i probably need to specify TARGET. sorry about the dumbness, as an eternal beginner i even forgot what i new few years ago and it wasnt much.

[matthey]

Originally Posted by wawa

is there any guide how to compile it on ubuntu, since there is no configure i obviously need to edit makefile by hand. right now i commented out -DHAVE_AOS4, but i guess i need to specify some more parameters. im stuck here:

See chapter 13 of the manual for how to build vbcc.

http://mail.pb-owl.de/~frank/vbcc/docs/vbcc.pdf

Building a cross compiler is a little more difficult as there are several options for targets. I can build vbcc, vasm and vlink on my 68060 Amiga though. One of the best features of vbcc is that there are minimal dependencies and tools needed to compile and build it.

[phx]

Originally Posted by wawa

right now i commented out -DHAVE_AOS4

Yes, you can leave that out, but it doesn't hurt either.

i probably need to specify TARGET.

Correct.
It's not as simple as typing "make", but nearly that simple.

Just type "make TARGET=m68k" to build a compiler (also cross-compiler) which generates M68k code.

First (and only once) you will be asked if you are building a cross-compiler. Always reply with 'y', even if you don't. Then reply to all the following questions with just "Enter" (=default). The compilation starts.

Example (building under NetBSD, so I'm using GNU-make = gmake):

frank@syrinx gmake TARGET=m68k
bin/dtgen machines/m68k/machine.dt machines/m68k/dt.h machines/m68k/dt.c
Are you building a cross-compiler?
Type y or n [y]: 
Does your system/compiler support a type implemented as
standard 2-complement 8bit byte?
Type y or n [y]: 
Enter that type[signed char]: 
Does your system/compiler support a type implemented as
standard unsigned 8bit byte?
Type y or n [y]: 
Enter that type[unsigned char]: 
Does your system/compiler support a type implemented as
standard 8bit-byte-based 2-complement 16bit word, big-endian?
Type y or n [y]:
...

[wawa]

hooray! i have been just looking around for docus concerning these type definitions or what that is, even though i suspected default would fit. that spared me some time hesitating. have vbccm68k now!

gotta see how to install and use it in within ubuntu directory structure. linux makes me always feel lost alas. i suppose i need it in the same dir where all other tools are. and then test if this so working correctly at all.