http://sourceforge.net/projects/adtools/

What is ADTools?

Quote:

So, is there any volunteer?


---- General discussion ----

Why I pointed it top your attention?

Because one of the Friedens wrote me some hours ago that:

Quote:

Take careful attention to these statements.

These words could be the start of a new kind of co-operation, not between Amiga related firms, but a co-operation limited to the coders and programmers of both camps.

This co-operation is needed for both major Amiga OSes to survive.

Focus some problems both OSes need to solve.

Join efforts and realize common platforms of development for the most important project which could help Amiga survive 21th Century and beyond.

This is why started this thread here on amigaworld site:

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=18535&forum=32

And it is very interesting and promising for the co-operation in both camps that one of Friedens it is one of the first persons who just wrote to me.

Entire discussion is continuing without flames, and it is open to all proposals.

Enjoy it.

This was already discussed on moobunny.
AROS and MorphOS do not rely on horrible and giant compiler patches breaking the SystemV ABI and such.
Our diffs are much smaller (or even non-existant...) and can be applied in no time.
On this matter, no need to coordinate anything except if you want to lose your time or look cool to some range of people...

Edit:
And to be sure Michael Merkel understands why such coordination is not really required... there is no patch to apply to get a working MorphOS compiler. Just grab GCC source, configure&make and you get a working MorphOS compiler :-)
This is not the case for os4, AFAIK. So they have a reason to have several people maintaining their heavy patches... But do not generalise.

[ Edited by Henes on 2006/4/6 18:57 ]

Quote:

I disagree.

Because, if you don't see the point, then there are problem from AOS side of the world, to port their programs into MorphOS world.

A well balanced and multistandard ADtools system for GCC could keep ease to port programs, and increase userbase for a single program.

AOS coders could release MOS counterparts of their programs, and perhaps give it for free or sell it also into our environment, and this will increase Amiga market and renevues for the amiga programmers.

No, there are no real problems to port programs.

For exemple, os4 system calls require GCC patches.
On MorphOS and AROS, there is no need to patch anything and any standard compiler works.

But at source level, for programmers, there is zero difference.
So, there is nothing to ease.

And remember dante's Inferno Canto XXXIV, vv 1-3:

«Vexilla regis prodeunt inferni
verso di noi; però dinanzi mira»,
disse 'l maestro mio, «se tu 'l discerni».

«The flags of the king of hell are coming toward us, but let's look forward, said my master, if you are capable to perceive it.»

And this is my creeps. Apple Macintosh is advancing, leaving occupied all market spaces, which once upon a time were free for Amiga-like systems.

These widget system in OS X is very promising and keeps the OS X very simple for new users little work environments to deal with, a nd completely customizable.

Also they are enhanced multiboot systema and emulation of Windows...
When until yesterday it is us Amigans who emultated macintoshes.

For example to stay on the market, then we must open a constructive and open talk with our cousins into AmigaOS, to let us develop all liitle utilities we lack of.

And this is a fact!

[ Edited by Raf_MegaByte on 2006/4/6 19:11 ]

[ Edited by Raf_MegaByte on 2006/4/6 23:24 ]

But it is completly unrelated...

Quote:
Probably not exactly working because MorphOS hasn't moved beyond gcc 2.

If the gcc stuff is so easily ported, could any of the cracks please compile the gdb debugger?

It also works for more recent and broken GCC. Try if you want.
The exact configure arguments are even in #morphos topic to prove it :-)

@Dietmar

Quote:

It probably would need using non-public APIs.

It should be also noted that ADTools project (GCC4 part of it at least) doesnt configure in MorphOS so Linux is needed to do the job. But then, you could port it from the official GCC4 source as well.


[ Edited by itix on 2006/4/6 21:55 ]

Quote:

What about vararg68k?

@Georg

Varargs68k is not used in the system calls or in any link lib. It is handy for lazy developers but such code is not portable and there are other means to work around it.

Of course if the source code depends on it you must use GCC2 or VBCC.


[ Edited by itix on 2006/4/7 0:04 ]

Quote:

It is unrelated to the answer I made to your statements.

It is not un-related, but again it matches it perfectly with "ALL" the "general discussion" of co-operate at various level between AmigaOS and MorphOS.

This is why I put this new comment here, starting with Dante, because this is another topic to talk about, but in the same thread.

Sorry. I had had introduced it with a starting phrase to let readers keep it intended better than I had explained.

@itix
Ok, so any MOS changes were integrated back into the gcc tree itself, then? (sounds like it..?)

@raf

If so, there really isn't much point of working together, at least not on this. If there's now 'official' gcc support, that's the ideal 'end of line'- pick up free bugfixes from the gcc crew, and maintain the < whatever OS > specific changes in the codebase...

In case it's not obvious, the above isn't meant to come off in any way, shape or form as 'Oh no, no one should work together!' as I certainly don't believe it, not to mention itix and others have already been working on some 'joint projects' with some of the guys from #amigadev....just there may not be any real point in this case.

Q-Master have started working on it. I'll tell him about the project.

The problem is also that binutils MUST be patched to use base relative code. And also binutils won't just so easily link, coz they need some special section ID's. Also gcc should be patched to produce base relative code. So it's not THAT easy.

@wegster

No they never did. It is not needed to patch GCC at all to get it compile working code. You just dont get 68k varargs stuff and such.

Quote:
Are you talking about __libcall__? The funny thing is that this extension causes no problems with new GCC versions. Th old GCC2 modifications apply to ALL later versions. Go figure..

Quote:
Are we talking about the same diffs? FWIW, the binutils patches (at least for 2.9.1) contain lots of unrelated crap! One of these hunks was the reason for non-working code until Piru disabled it... It could have been removed without trouble. The same applies to the GCC patches, lots of unrelated stuff. Altivec support is different with newer binutils/GCC versions (different argument names, maybe even the syntax changed). And looking the AltiVec MOS-GCC version I can easily spot questionable changes in rs6000.c/rs6000_stack_info.

Quote:
Without all the fancy stuff like __varargs68k, __saveds and all the target options that got added to the 2.95.x sources. And what about the SDATA_BREL?

Quote:
Does configure know MorphOS? Don't you need the GET_MIN_[MODE,TYPE]_ALIGNMENT changes?

Quote:

gcc != gdb

Quote:
Nope, the official GCC sources don't contain support for AmigaOS/68k, AmigaOS4 or MorphOS. MOS is slightly different because (as Henes already stated) it uses plain SYSV V.4 ABI and thus you could use a GCC configured for ppc-elf32. Its without all the fancy stuff but maybe thats enough for certain purposes.

Quote:
Can't you use 2.9.1? Works fine here.

Quote:
AFAICT, binutils in the adtools repository do contain MOS support. However, I have no idea whether they work.

Quote:

Yes I can. I already use them. (with some fixes to make libiberty compile)

Quote:

To use baserel compiling the gcc must also be patched.
BTW, I can't browse the svn repository on SF. It says it has internal server error.

Quote:

Does it support 68k vararg hack too?

According to amiga_compiler.h GCC uses

#define APICALL __attribute__((libcall))

when VBCC uses

#define APICALL __aos4libcall __linearvarargs

So that every vararg library call in OS4 uses 68k varargs instead of native SysV varargs (newlib.library being an exception).

One would also ask who had this idea using (the system private) r2 as a base pointer for baserel libraries... maybe r13 was too obvious...

Luckily you can always extend struct Process when you need new base pointer (though it makes it tricky when your code is called from other context but not impossible).

Quote:

Lack of __vararg68k is not problem. You can always work around this by piece of code. However without baserel support SDL libraries cant be compiled on anything else than GCC2. But GCC4 is not secret overclocking utility so...

@ wegster:

Quote:

Don't worry.

ADTools it is only the first project that could require a joint effort.

Rogue (Friedens) signalled it to me and I bounce this project here into Morphzone.

Has it been revealed impossible to work on it by both camps together?

No problem at all.

More projects will require joint efforts in the coming future.

At least we have now a channel of communication left open to send "smoke messages" from an Amiga-like OS to another one.

Keep good will by programmers of both camps to let it stay opened.

Quote:

Sure 'official' GCC support is needed.

Quote:
What system/compiler are you using if libiberty breaks there?

Quote:
I know. Maybe I state the obvious: the adtools reposity does only have MorphOS support in binutils (and its seems its not based on the zapek binutils sources). There is no other MorphOS support.

Quote:
Never done that. I have a checkout.

Quote:

It breaks on x86 debian sarge gcc version 3.3.5 (Debian 1:3.3.5-13).

Quote:

I understand this. I just mentioned that gcc also must be patched. 8)

Quote:

I can't do that at work.