News about AROS 68k development?

[phx]

(The whole discussion does not belong into WinUAE-support, but better into support.Apps or coders.C/C++.)

Refer to chapter 1.3.1 of vbcc.pdf for some short installation instructions.

Additionally installed applications, not belonging to the base system, usually go under /usr/local on a Unix system. I chose /usr/local/vbcc.

The typical structure is:

frank@jaana ll /usr/local/vbcc/
total 20
drwxr-xr-x   2 frank  users  512 May 16  2013 bin
drwxr-xr-x   2 frank  users  512 Aug 23 17:37 config
drwxr-xr-x  12 frank  users  512 Apr 20  2013 targets

All binaries in bin and the config files (at least the default vc.config should be there) in config.
Install the targets you need (for example m68k-amigaos) under targets. You find them here:
http://sun.hasenbraten.de/vbcc/index.php?view=targets

frank@jaana ll /usr/local/vbcc/targets/
total 40
drwxr-xr-x  4 frank  users  512 Nov 18  2012 cf-atari
drwxr-xr-x  4 frank  users  512 Apr 20  2013 i386-aros
drwxr-xr-x  5 frank  users  512 Dec 28  2005 i386-netbsd
drwxr-xr-x  4 frank  users  512 Nov 30  2005 m68k-amigaos
drwxr-xr-x  4 frank  users  512 Nov 14  2012 m68k-atari
drwxr-xr-x  4 frank  users  512 Nov 30  2005 ppc-amigaos
drwxr-xr-x  5 frank  users  512 Dec 23  2005 ppc-morphos
drwxr-xr-x  4 frank  users  512 Dec  7  2008 ppc-netbsd
drwxr-xr-x  4 frank  users  512 Nov 30  2005 ppc-powerup
drwxr-xr-x  4 frank  users  512 Nov 30  2005 ppc-warpos

Make sure /usr/local/vbcc/bin is in your shell's path. Add that to the shell's rc file (e.g. .bashrc):

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

The frontend, vc, needs the $VBCC environment variable to find the installation directory. Define that as well:

export VBCC=/usr/local/vbcc

Now you can cross-compile for AmigaOS:

vc +aos68k -o hello_world hello_world.c

Copy your default config file (e.g. aos68k) to vc.config. Then you may omit the +configfile option.
BTW, the target archives contain config files for AmigaOS/MorphOS. If you don't want to adapt the config files for Unix yourself, you find them here:
http://mail.pb-owl.de/~frank/vbcc/2011-08-05/vbcc_unix_config.zip

[wawa]

@phx
yes, it was ot from the start, but went even more in its course. hower its a task for a mod to move it if neccessary. or do you think we should start over somewhere else?

i have dug a bit through the documentation pdf matthey linked to, and recalled again that setpatch and dir approach. i will try to go now systematicly through, i need to learn that properly if i am supposed to do anything in the end (very unlikely ).

i will continue through the weekend but may be a little slow since i have now my girlfriend here. i have yet to look at the heades in target archive and compare them to whats in the amiga sdk and the aros source.

[matthey]

I found the compiler generic assembler stubs (needed for Amiga library register passing) I was thinking of.

I would suggest that you write your code so that so that you can switch between compilers without needing to edit your source. If you have a header file that has something like:

#ifdef _DCC /* DICE */
#define REG(x) __ ## x
#define ASM
#define SAVEDS __geta4
#elif defined(__SASC) /* SAS/C */
#define REG(x) register __ ## x
#define ASM __asm
#define SAVEDS __saveds
#elif defined(__GNUC__) /* GCC */
#define REG(x) register __ ## x
#define ASM
#define SAVEDS
#elif defined(__STORM__)
#define REG(x) register __ ## x
#define ASM
#define SAVEDS __saveds
#endif

and then define your function as

SAVEDS ASM LONG DroppedFile (REG(a2) APTR object_p, REG(a1) struct AppMessage **msg_pp);


then you shouldn't need to worry about changing your compiler at any point.

There are some compiler macros at the link that follows which try to do similar preprocessor compiler abstraction.

https://searchcode.com/codesearch/view/9272166/

Maybe something similar could be done with the preprocessor for some of the GCC function and variable attributes?

[wawa]

@phx
followed your instructions so far. still not being able to compile helloworld, apparently vasmm68k_mot is missing. i assume i need to compile that assembler as well.

also having only the aos68k config in configs, which is going to be my sole target for starters, while invoking vc it seems to be nesessary to use the option -aos68k. perhaps its the case only while cross compiling.

[matthey]

Originally Posted by wawa

@phx
followed your instructions so far. still not being able to compile helloworld, apparently vasmm68k_mot is missing. i assume i need to compile that assembler as well.

You probably need vasm and vlink. They can be found at the following 2 links.

http://sun.hasenbraten.de/vasm/
http://sun.hasenbraten.de/vlink/

They are easier to compile than vbcc (targets still needed) and there are "compilation notes" at the links.

Originally Posted by wawa

also having only the aos68k config in configs, which is going to be my sole target for starters, while invoking vc it seems to be nesessary to use the option -aos68k. perhaps its the case only while cross compiling.

The configs are editable text files. I believe the default config is vc.config. I believe you can make a copy of the aos68k config to vc.config and this will become your default without specifying a config on the command line. The vbcc manual should have more info in case I'm wrong.

[wawa]

the executables of vasm and vlink do look like native binaries. i obviously need to build sross compiler binaries, which i wasnt been able to yet.

[Leffmann]

If you're on a Unix-like system, then step into the vasm directory and run

make CPU=m68k SYNTAX=mot

, and in the vlink directory you just run

make

.

On Windows, you first open the Visual C++ Command Prompt, and replace

make

with

nmake /f makefile.win32

.

[phx]

Originally Posted by wawa

also having only the aos68k config in configs, which is going to be my sole target for starters, while invoking vc it seems to be nesessary to use the option -aos68k. perhaps its the case only while cross compiling.

Where did you get aos68k from? When running under Linux you should take it from vbcc_unix_config.zip, or adapt the one from the target archive for your needs (change paths and replace "delete" by "rm").
Just copy your favourite config file to vc.config. This is the default for vc.

Originally Posted by wawa

the executables of vasm and vlink do look like native binaries.

Where are they from? Did you install one of the vbcc_bin_* archives? There are no Linux executables in them. You have to compile them yourself.

i obviously need to build sross compiler binaries, which i wasnt been able to yet.

That's simple. See what Leffmann wrote. Copy the vasm and vlink binaries to /usr/local/vbcc/bin like the compiler and frontend.

[wawa]

@phx

Where did you get aos68k from?

as you suggested:
http://mail.pb-owl.de/~frank/vbcc/cu...8k-amigaos.lha

i have compiled vlink and vasm now (vasm has given me some warnings).

edit: good and bad news. i have now succesfully compiled my hello world under vbcc, but while i was testing it under uae the virtual machine crashed and doesnt want to start again. must look into it, worst case resetting all damn ubuntu. good thing being vbcc installation wasnt so hard after all.

[phx]

Originally Posted by wawa

as you suggested:
http://mail.pb-owl.de/~frank/vbcc/current/vbcc_target_m68k-amigaos.lha

The config file therein is for an AmigaOS/MorphOS hosted vbcc. I also suggested to get the Unix-aos68k from vbcc_unix_config.zip.

i have compiled vlink and vasm now (vasm has given me some warnings).

That's certainly harmless, although I should fix them. Building vasm with gcc 4.5.3 under NetBSD showed no warning, though:

frank@tethys gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64--netbsd
Configured with: /usr/src2/tools/gcc/../../external/gpl3/gcc/dist/configure --target=x86_64--netbsd --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb2 20111202' --enable-__cxa_atexit --with-tune=nocona --with-mpc=/var/obj/mknative/amd64/usr/src2/destdir.amd64/usr --with-mpfr=/var/obj/mknative/amd64/usr/src2/destdir.amd64/usr --with-gmp=/var/obj/mknative/amd64/usr/src2/destdir.amd64/usr --enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch --build=x86_64-unknown-netbsd5.99.56 --host=x86_64--netbsd
Thread model: posix
gcc version 4.5.3 (NetBSD nb2 20110806) 
frank@tethys gmake CPU=m68k SYNTAX=mot
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  vasm.c -o obj/m68k_mot_vasm.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  atom.c -o obj/m68k_mot_atom.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  expr.c -o obj/m68k_mot_expr.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  symtab.c -o obj/m68k_mot_symtab.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  symbol.c -o obj/m68k_mot_symbol.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  error.c -o obj/m68k_mot_error.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  parse.c -o obj/m68k_mot_parse.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  reloc.c -o obj/m68k_mot_reloc.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  hugeint.c -o obj/m68k_mot_hugeint.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  supp.c -o obj/m68k_mot_supp.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  cpus/m68k/cpu.c -o obj/m68k_mot_cpu.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  syntax/mot/syntax.c -o obj/m68k_mot_syntax.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  output_test.c -o obj/m68k_mot_output_test.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  output_elf.c -o obj/m68k_mot_output_elf.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  output_bin.c -o obj/m68k_mot_output_bin.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  output_vobj.c -o obj/m68k_mot_output_vobj.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  output_hunk.c -o obj/m68k_mot_output_hunk.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  output_aout.c -o obj/m68k_mot_output_aout.o
gcc -I. -Icpus/m68k -Isyntax/mot  -c -O2  output_tos.c -o obj/m68k_mot_output_tos.o
gcc obj/m68k_mot_vasm.o obj/m68k_mot_atom.o obj/m68k_mot_expr.o obj/m68k_mot_symtab.o obj/m68k_mot_symbol.o obj/m68k_mot_error.o obj/m68k_mot_parse.o obj/m68k_mot_reloc.o obj/m68k_mot_hugeint.o obj/m68k_mot_supp.o obj/m68k_mot_cpu.o obj/m68k_mot_syntax.o obj/m68k_mot_output_test.o obj/m68k_mot_output_elf.o obj/m68k_mot_output_bin.o obj/m68k_mot_output_vobj.o obj/m68k_mot_output_hunk.o obj/m68k_mot_output_aout.o obj/m68k_mot_output_tos.o -lm -o vasmm68k_mot
frank@tethys

[wawa]

@phx
sorry, it was the one from vbcc_unix_config.zip of course.

now i just need to rebuild my compiler environment. i must say losing a whole setup due to simple vm crash has shaken my confidence in vmware. i must reconsider a while.

edit: ok, fixed after whole system reboot.

[matthey]

Originally Posted by wawa

now i just need to rebuild my compiler environment. i must say losing a whole setup due to simple vm crash has shaken my confidence in vmware. i must reconsider a while.

You could install the 68k AmigaOS 3.x version of vbcc (with an Amiga install script) on your 4000 060 with AROS. You would not be able to generate AROS specific executables but you should be able to generate 68k AmigaOS 3.x executables, the same as a cross-compiler. AROS 68k should even be able to execute the executables unlike your Linux environment. Vbcc is one of the easiest and fastest Amiga compilers to install too. The Amiga is a very fast environment for experimenting even if it doesn't have the raw CPU performance for compiling large programs quickly. Maybe you could get a feel for vbcc under AROS before trying to cross compile AROS with vbcc on a faster computer. You could also report any bugs you find to the AROS and vbcc developers as this is the first step necessary for adding AROS support to vbcc. Maybe Olaf Schoenweiss has tried vbcc 68k AmigaOS 3.x under 68k AROS but I doubt many others have.

P.S. The new version of vbcc may finally be released soon (before Christmas hopefully ).

[wawa]

@matthey
i would prefer aros compiled on aros, but i prefer to check vbb first under linux, since aros depends a lot on up to date gnu tools i suspect. i have vbcc under uae thanks to cubicide and i have it somewhere on genuine amiga drive that i have used on my main system before i went to test aros, but i would prefer not to compile on a hardware i am constantly messing with.

as i said, i have recovered ubuntu and even though some settings seem lost, im confirmed able to generate aos executables alright. i will try to generate some simple executable for aros68k tomorrow. i only need to discover how to generate parts of the source using those mmakefile.src. the other problem likely is that vbcc will generate genuine amiga hunk format, while aros uses some sort of elf format for executables (whatever it means ;P). any comment on that?

[matthey]

Originally Posted by wawa

i would prefer aros compiled on aros, but i prefer to check vbb first under linux, since aros depends a lot on up to date gnu tools i suspect. i have vbcc under uae thanks to cubicide and i have it somewhere on genuine amiga drive that i have used on my main system before i went to test aros, but i would prefer not to compile on a hardware i am constantly messing with.

I have experienced my share of vbcc crashes on my Amiga with PFS but I haven't had any problems that didn't go away with a cold reboot. I even write my MuForce output to a mostly empty temp partition without any HD issues (sometimes the output file is empty after a crash though). You are correct that compiling and debugging will do more than the normal amount of HD thrashing, at least with an AmigaOS. It's not like another popular OS that thrashes the HD constantly, even when not used .

Originally Posted by wawa

as i said, i have recovered ubuntu and even though some settings seem lost, im confirmed able to generate aos executables alright. i will try to generate some simple executable for aros68k tomorrow. i only need to discover how to generate parts of the source using those mmakefile.src. the other problem likely is that vbcc will generate genuine amiga hunk format, while aros uses some sort of elf format for executables (whatever it means ;P). any comment on that?

Shouldn't the Amiga Hunk format executables execute on 68k AROS? The vlink manual states that it supports:

Originally Posted by vlink.pdf

elf32m68k

ELF (executable linkable format) for Motorola M68k, 32-bit, big endian.
Small data offset: 0x8000. Linker symbols: _SDA_BASE_. Automatic
constructor/destructor function tables will be placed into the sections .ctors and .dtors. Supports ‘-Rstd’ and ‘-Radd’.

You could try copying the aos68k config and renaming "aros68k" or "elf68k". Then change all instances of "-bamigahunk" to "-belf32m68k" in the new text file. It may not work if AROS needs custom non-standard sections in the 32 bit 68k ELF format. Frank (phx) could probably tell you.

[phx]

Originally Posted by wawa

while aros uses some sort of elf format for executables (whatever it means ;P). any comment on that?

When I implemented experimental support for AROSx86 many years ago they were using relocatable object files in ELF-i386 format, in the same way PowerUp did with ELF-ppc before. So I added a new vlink-target, called "elf32aros", which creates those relocatable objects as executable files. I didn't expect that AROS executables could ever be for another architecture than x86 at that time.

I don't know AROS/m68k, but chances are high that they still use relocatable object files as executables, so the standard "elf32m68k" format, which matthey mentioned, won't work very well. It might work when you link the final executable with -belf32m68k and -r option, so it is still an object file. But vlink doesn't make sure that all symbols have been resolved in an object.

If you know what you need I can add a new arosm68k target to vlink. Just tell me, or send me an AROS executable which I can analyze.

[wawa]

Originally Posted by matthey

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?). .

sdi headers?
http://aminet.net/package/dev/c/sdi_headers-1.6
they have been added lately to aros as far i observed the commits, must locate it, the (68k) register stuff should be rewritten against that. perhaps asm inlines can be abstracted similar way and make compiler indipendant.

@toni

btw, have you ever tested the gcc 4.5.0 68k backend from bernd? it had not so much register support as the genuine amiga compilers, i guess but i dont remember very well. also no source available so probably not a subject for aros.

Originally Posted by phx

When I implemented experimental support for AROSx86 many years ago they were using relocatable object files in ELF-i386 format, in the same way PowerUp did with ELF-ppc before. So I added a new vlink-target, called "elf32aros", which creates those relocatable objects as executable files. I didn't expect that AROS executables could ever be for another architecture than x86 at that time.

I don't know AROS/m68k, but chances are high that they still use relocatable object files as executables, so the standard "elf32m68k" format, which matthey mentioned, won't work very well. It might work when you link the final executable with -belf32m68k and -r option, so it is still an object file. But vlink doesn't make sure that all symbols have been resolved in an object.

If you know what you need I can add a new arosm68k target to vlink. Just tell me, or send me an AROS executable which I can analyze.

aros still uses the same executable format i guess, the relocatable elf. aros68k can execute both elf and hunk binaries, but i dont know if it can itself be compiled as hunk, and if it should. i dont know about advantages and disadvantages there.

frank, if you need an executable, here is are the nightlies:
http://aros.sourceforge.net/de/download.php

download amiga-m68k-bootiso and pick your favourite example within. also other nightlies contain valid up to date executables for particular platform.
but you need to know that aros branches currently into v0 and v1 abis. all traditionally supported platforms that are available in userland (which means practically x86) are v0 for binary compatibility reasons, while aros68k belongs to v1 branch which is a further development en course and breaks the binary compatibility with v0. builds and sources for this branch except for 68k are available here:
http://aros.sourceforge.net/de/download2.php

let me know if i may be of further assistance. i can check how vbcc compiles on my system, but i think i would need to check the latest sources.

what concerns vbcc and aros my idea is so far:
1. introduce vbcc to aros toolchain and let it build automatically with aros build system (are licenses compatible?)
2. adopt mission critical platform specific 68k code (register assignments?) to be compiled with vbcc to object files. everything else may compile with gcc so far. i assume vbcc objects can be linked with gcc linker.
3. eventually introduce further vbcc compatibility to aros source up till it might be compiles with vbcc completely. bu that is a far target.

[wawa]

@toni, phx, matt &all interested

i am discussing these possibilities on aros-exec here:
http://aros-exec.org/modules/newbb/v...forumpost91053

[Heiroglyph]

I'm the guy wawa mentioned earlier that had done some vbcc builds of certain parts of Aros.

The reason I started is that I don't like the result coming out of gcc. It's huge and the binaries are only vaguely amiga-like at best. Square peg, meet round hole.

I think Aros is taking so long because the development path taken is completely backwards, working from x86 with foreign tools and kinda sorta wanting 68k to eventually work.

BS, that's untestable and unsustainable.

Use Amiga tools to write C replacements of individual libraries, test them individually with an otherwise stock AOS system to isolate the bugs and move to the next library.

Writing the entire OS and supporting libraries (CybergraphX, etc) in one shot while also porting to another platform is just insane. Get a working replacement in a stable environment, then port to a completely different platform after you feel confident that the code is reasonably stable. You need an anchor to rely on or you'll never get anywhere.

What I did was pull the C directory of Aros and start building and testing the resulting binaries on 3.1. No Aros specific calls, no additions, just binary compatible Amiga executables of similar size to the originals.

That was a test to get the development process down before starting on libraries and I think it worked out pretty well.

What kills me on the libraries is the massive wad of macros required to force gcc into submission and how far Aros strayed from using Amiga library interfaces, instead falling back to Aros specific calls, making it essentially monolithic, you can't just mix and match with AOS as it stands. Aros becomes more of a reference material than source.

I'm all for helping work on 68k Aros, but there's no way I'm going to go down the current path of development.

[Toni Wilen]

Originally Posted by wawa

@toni, phx, matt &all interested

i am discussing these possibilities on aros-exec here:
http://aros-exec.org/modules/newbb/v...forumpost91053

Sounds good.

Originally Posted by Heiroglyph

I think Aros is taking so long because the development path taken is completely backwards, working from x86 with foreign tools and kinda sorta wanting 68k to eventually work.

BS, that's untestable and unsustainable.

Are you serious? This is 100% unmaintainable, 100x more than aros is now. You really want to fork aros and maintain it (getting patches from mainline manually and so on..) as a separate OS when there is already too few developers? Especially developers that knows OS internals.

Totally not acceptable for me. Except of course "foreign tools" part which is topic of this thread. (But they also must not be too native, cross-compilation must be possible)

[phx]

Originally Posted by wawa

aros still uses the same executable format i guess, the relocatable elf. aros68k can execute both elf and hunk binaries, but i dont know if it can itself be compiled as hunk, and if it should. i dont know about advantages and disadvantages there.

I'm not sure what you are refering to with "itself" - probably a kind of kernel?

I have checked the amiga-m68k-bootiso and there is a file called aros-boot.bin. This is neither ELF nor hunk-format, but a 512K ROM image, similar to the original ROM, which can execute at 0xf80000.
There is also AROSBootstrap, which is in hunk-format. Don't know how AROS works or boots, though.

download amiga-m68k-bootiso and pick your favourite example within.

Seems that everything is in hunk-format. The executables and libraries look exactly like normal AmigaOS ones. Even the ABI seems to be identical, and the same registers and LVOs are used when calling functions from a library. Reassembling C/CD looks like this:

        SECTION S_0,CODE

SECSTRT_0:
        SUBQ.L  #4,A7                   ;000: 598f
        MOVEM.L D2-D7/A6,-(A7)          ;002: 48e73f02
        MOVE.L  A0,D7                   ;006: 2e08
        MOVE.L  ABSEXECBASE.W,D4        ;008: 28380004
        CLR.L   28(A7)                  ;00c: 42af001c
        LEA     LAB_0022,A1             ;010: 43f90000029d
        MOVEQ   #37,D0                  ;016: 7025
        MOVEA.L D4,A6                   ;018: 2c44
        JSR     -552(A6)                ;01a: 4eaefdd8
        MOVE.L  D0,D5                   ;01e: 2a00
        BNE.S   LAB_0000                ;020: 6612
        SUBA.L  A1,A1                   ;022: 93c9
        JSR     -294(A6)                ;024: 4eaefeda

Are you sure this is AROS?

what concerns vbcc and aros my idea is so far:
1. introduce vbcc to aros toolchain and let it build automatically with aros build system (are licenses compatible?)

There is no problem from my side. I have a signed contract that I can do with vbcc, targeted for Amiga-like platforms, whatever I want.