News about AROS 68k development?

[Toni Wilen]

Perhaps I missed something but aros-m68k of course uses same ABI and everything, it is supposed to run normal AOS binaries after all. (and vice versa if binary is not linked with aros startup)

Most executables should be in elf-format (unless something was changed and they all are now converted to hunk before distribution files are created).

At least arosbootstrap loadable rom image (aros.elf.gz) is elf formatted. (arosbootstrap = softkick for aros.elf, only works with elf executables). Note that arosbootstrap is also a special case, it is designed to run on AOS to allow aros m68k softkick.

afaik only point of having elf excutables (vs hunk) is better debugging and compatibility with other "alien" tools (standard nm can be used to list all symbols etc..)

Are you sure this is AROS?

No but perhaps it is only some assembly startup code. (I don't really remember)

[wawa]

Originally Posted by Heiroglyph

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

welcome! thx for interest!

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.

that is what i used to think first when aros68k kicksart replacement started. i thought, coming from afa-os, exactly that: compile file for file, library for library and replace the genuine parts with it one by one. it might be one way, but now i understand that experienced professinal developers like jason and toni have chosen the most convenient way. anyway it came a long way down this way and it would be foolish to abandon this and start over from the beginning. however whil testing one might adopt the one by one strategy.

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.

but thinking like that we will not come anywhere, because aros is in steady development, a moving target if you will anyway. waiting till it would be ready is waiting forever. and as it is now, it is already working pretty well, wee just need to improve it.

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 have you compiled it against? amiga or aros headers?

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 think thiese macros is one of the main problems that have to be taken care about, as we all acknowledge. however its not true, that you cannot mix aros and amiga library calls under aros68k. on the contrary, you can use genuine amiga libs and classes under aros allright along the aros ones and substitute them by each other.

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.

please understand that the current patch of development, it is just what makes aros sensible as aos replacement. you get aros improvements on 68k practically for free. one of the big issues is not to get something ready, but to have it maintained and automate as much of the maintenance as possible, especially with the limited human ressources. we need to cooperate, not split. and so building own aros fork would cut us away from all advantages aros might provide. im completely with toni on that. project of this size is impossible to be worked on by hand, especially it needs to provide the structure for contributors to fit in.

[phx]

Originally Posted by Toni Wilen

Perhaps I missed something but aros-m68k of course uses same ABI and everything, it is supposed to run normal AOS binaries after all.

Ok. So there is not much to change for the executables and libraries.

Most executables should be in elf-format (unless something was changed

Not in the last nightly ISO, which I just downloaded.

At least arosbootstrap loadable rom image (aros.elf.gz) is elf formatted.

No. It's called aros.hunk.gz now.

[wawa]

Originally Posted by Toni Wilen

afaik only point of having elf excutables (vs hunk) is better debugging and compatibility with other "alien" tools (standard nm can be used to list all symbols etc..)

are these debugging options available for amiga-m68k at all?

i thought the exec loaders for elf and hunk were different and deadwood improved aomething the elf one few months ago while the other was left as is.

if nothing of this matters and it seems that elf format has no advantages for amiga-m68k platform, we can stay with hunk as well.

[wawa]

@toni

just trying to compile some small pieces of aros outside the build mechanism (single file sources like c commands) and i notice how powerfull mechanism it is to configure to a target platform. headers need to be created, a lot of constants have to be defined, while doing this by hand is crazy.

what and where are acually these annoying macros? asmcall.h? can we narrow down a possibly small region of source that would be beneficial to make changes to in order to have it compiled with vbcc? i think it would be best to mess with the build system only where absolutely necessary.

[Toni Wilen]

Originally Posted by wawa

are these debugging options available for amiga-m68k at all?

i thought the exec loaders for elf and hunk were different and deadwood improved aomething the elf one few months ago while the other was left as is.

if nothing of this matters and it seems that elf format has no advantages for amiga-m68k platform, we can stay with hunk as well.

My debugging is mainly via UAE debugger (and adding special case tests in CPU/memory access code) but I am quite sure everyone else uses native debuggers.

Originally Posted by wawa

@toni

just trying to compile some small pieces of aros outside the build mechanism (single file sources like c commands) and i notice how powerfull mechanism it is to configure to a target platform. headers need to be created, a lot of constants have to be defined, while doing this by hand is crazy.

what and where are acually these annoying macros? asmcall.h? can we narrow down a possibly small region of source that would be beneficial to make changes to in order to have it compiled with vbcc? i think it would be best to mess with the build system only where absolutely necessary.

I don't know (and it is something I'd prefer not to know in future either )

Jason did 99% of the macro stuff. (The most difficult to part that had to be done before anything m68k was possible)

Originally Posted by phx

No. It's called aros.hunk.gz now.

Strange. It has always been elf and arosbootstrap has not changed for long time.. I guess some build option has changed and now all files are converted to hunk. (Note that I practically have never used binaries, I always compile everything myself)

[wawa]

Originally Posted by Toni Wilen

I don't know (and it is something I'd prefer not to know in future either )

i cant spare you, looks like here is that evils tail sticking off:
/AROS-source/arch/m68k-all/include/gencall.c

Jason did 99% of the macro stuff. (The most difficult to part that had to be done before anything m68k was possible)

he hasnt been seen around, and has only made few commits lately. he wants to be left alone i take it, or have you any contact to him, toni? otherwise i will probably need to ping him again with anunforseeable effect..

[wawa]

i have a message from jason whom i will directly quote here, not to miss something:

gencall.c would need to be modified to emit the correct library call macros for vbcc - whatever they would happen to be.

asm.c is is the trickier issue, see:


http://en.wikibooks.org/wiki/Aros/Pl.../Compiler#VBCC



And i know of no good resolution for that one, without extending vbcc.

[matthey]

Originally Posted by wawa

i have a message from jason whom i will directly quote here, not to miss something:

Jason did a good job of documenting. So the problems are here:

asm.c
https://gitorious.org/aros/aros/sour.../include/asm.c

gencall.c
https://gitorious.org/aros/aros/sour...lude/gencall.c

The whole AROS build system does look overly complex and full of GCCisms. Maybe Heiroglyph's idea of creating a new 68k build (like AFA OS but with real Amiga executables and libraries) isn't that bad of an idea.

[wawa]

@matthey

you would have to put together another build system instead. okay, it might be easier, because you would have a fixed target and you wouldnt have to automate building a toolchain if you would update it by hand. but the question, whatever solution, is about the same: who is going to do that?

another question remains: how will we keep synchronized with aros upstream? also by hand? you have to keep track of changes, test, and update accordingly to maintain. also we lose influence on the main aros branch, on which we though still depend in that case. our reports may not be taken into account if there is a problem.

also, we would have either to heavily modify the sources or does heiroglyph already forund out what set of definitions is needed to compile the executables vith vbcc?

@phx:

what you you think about jasons mail, do you know what he is reffering to exactly (im just reading on struct offsets, but its way ahead before i understand what particular problem is crosscompiling from x86 to 68k any why it is so special). if so do you think there is a solution we can think of, i mean aros/vbcc?

[phx]

Originally Posted by wawa

what you you think about jasons mail, do you know what he is reffering to exactly

Without any AROS background not really. He wants to define structure offsets with the preprocessor for an assembler source, by using the C headers. But for what purpose is that needed?
He mentions it might be for generating assembler include files or generating a cpu.i (whatever this is needed for) ... ?

(im just reading on struct offsets, but its way ahead before i understand what particular problem is crosscompiling from x86 to 68k any why it is so special).

Running a cross compiler on x86 (not matter if 32- or 64-bit) which emits 68k code is not a problem at all. I'm doing that frequently with vbccm68k. There are neither alignment nor endian issues, as the cross compiler should be aware of that. I can only see minor problems with floating point constants in the source, which might differ in the least significant bit, because the x86 FPU has a different (lower) precision than the M68k FPU.

But probably Jason is refering to something else.

if so do you think there is a solution we can think of, i mean aros/vbcc?

I can ask Volker to extend vbcc's inline assembly, to treat it as format strings allowing arguments to be passed.

Better would be to understand why all these macros and inline assembly are needed and think about a better solution. For example, all other Amiga-like operating systems use FD or SFD files to define their library functions and arguments, so fd2pragma can generate stubs for any compiler.

[Toni Wilen]

Originally Posted by phx

Without any AROS background not really. He wants to define structure offsets with the preprocessor for an assembler source, by using the C headers. But for what purpose is that needed?
He mentions it might be for generating assembler include files or generating a cpu.i (whatever this is needed for) ... ?

Yes. It appears to be automatically generating assembler header file with offsets to structures from C header files. (used by assembly/inline assembly files). Manually duplicating it would be really painful.

Perhaps there is less ugly method to automatically generate structure offsets from C headers? (We don't need extra care because our compiler already knows m68k structure alignment)

We can't use official AOS headers because AOS headers have private fields (that are documented or reused in AROS) and AROS also have extensions.

Better would be to understand why all these macros and inline assembly are needed and think about a better solution. For example, all other Amiga-like operating systems use FD or SFD files to define their library functions and arguments, so fd2pragma can generate stubs for any compiler.

In AROS fd (and friends), even library base structure header file is created automatically from library.conf file, not the other way around. Which is nice, there is single file that defines everything about the library, for example if you want to add new function to library, just add it to .conf file (+implementation in separate source), the rest is automatic.

[wawa]

Originally Posted by Toni Wilen

In AROS fd (and friends), even library base structure header file is created automatically from library.conf file, not the other way around. Which is nice, there is single file that defines everything about the library, for example if you want to add new function to library, just add it to .conf file (+implementation in separate source), the rest is automatic.

just found about it too

[Hewitson]

Originally Posted by phx

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

This is a very strange configuration. If you did not want to follow the normal /usr/local/bin, /usr/local/share, etc structure, you should have used /opt/vbcc, IMHO.

[phx]

Making new directories for software under /usr/local is not that unusual. /opt, on the other hand, is used by Linux only (for optionally installed software packages?) while I'm using NetBSD.

[wawa]

just to document the progress and save a reference for further apporoach.

aros dependency packages:

binutils-source
libcloog-ppl-dev (adds lots of other dependencies)
g++
libelf-dev
bison
flex
gcc-4.5-source
libmpfr-dev
libmpc-dev
libecm-dev
netpbm
automake
libpng-dev (on ubuntu i have libpng12-dev, lets see if this will cause problems)
libc6-dev-i386


currently building aros68k crosstools on ubuntu:

directory structure:

<some dir>
- aros (clean aros sources here, no binaries!)
- build-m68k-tools (cross compiler will be built here)
- yet another directory where aros-m68k will be build (I just use "build")

<some dir>
cd build-m68k-tools
./../aros/configure --target=amiga-m68k --with-aros-toolchain-install=/opt/aros-m68k
sudo make -s crosstools

[wawa]

../aros/configure --target=amiga-m68k --with-aros-toolchain-install=/opt /aros-m68k --with-aros-toolchain=yes --with-serial-debug=yes
make -s

am proud to report that with an extensive help of toni i was able to build aros68k on my machine. many thanks, toni!

now i will be looking into the details.

How is it going guys,
Are we making any progress?

[wawa]

Originally Posted by ZyBeR

How is it going guys,
Are we making any progress?

i dont know. i am learning and documenting how to cross build aros and trying to get around the source and build system. thats what i can do myself atm. but it seems deadwood is up to something:
http://eab.abime.net/showthread.php?t=75973
looks like he tries to compile some example part of aros with gcc.

[Samurai_Crow]

@wawa
You mean VBCC don't you?