GCC 6.2 toolchain for AmigaOS 3

[BSzili]

Originally Posted by alkis

FYI, the link doesn't work. (At least it doesn't work for me)

Oops. I fixed the link, "http" got corrected to "https" somehow.

[bebbo]

Originally Posted by bubbob42

Or a script, which simply pulls the NDK from Aminet and installs it. The NDK is freely available, not dependant on Hyperion (which is important to us).

What you request was an absolute necessity in 1988, but not today. It is much better to always fetch the latest NDK release at installation or even update it easily for an existing installation of the compiler. This would fit with our plan to release incremental NDK updates instead of bigger ones every decade.

However, for this to work out it has be be ensured by all of us, that both your GCC's and the NDK's revision do not depend on each other, so users won't be left alone in case either product's development "stalls" for some time. An update of the compiler should not break the NDK and vice versa.

1st:
It's not "my" gcc, gcc is open source, see http://www.gnu.org/licenses/. Everyone is welcome to contribute.

2nd:
The available NDKs aren't usable without applying this and that. It's pure fantasy that installing a new NDK will work out of the box.

3rd:
Without this prerequisite, someone else is welcome to provide an Amiga version.

[bubbob42]

Originally Posted by bebbo

1st:
2nd:
The available NDKs aren't usable without applying this and that.

Such as?

[Samurai_Crow]

@bubbob42

Have you looked at the compiler cross-compatibility patches in the the SDI headers?

[bubbob42]

Originally Posted by Samurai_Crow

Have you looked at the compiler cross-compatibility patches in the the SDI headers?

Years ago. And?

If bebbo thinks, that there's no way around shipping modified NDK headers with gcc, then he could simply ask Ben for permission.

[Olaf Barthel]

Originally Posted by bebbo

2nd:
The available NDKs aren't usable without applying this and that. It's pure fantasy that installing a new NDK will work out of the box.

We're trying to make it real. Give us a chance, please.

I know that there are copyright and licensing issues for the material involved, and there is doubt about where this whole effort will lead. It's comparatively safe to rework the old NDK material, but it has its limits. For example, there is no sound NDK 1.3 header file set which works well enough with existing compilers.

[alkis]

Originally Posted by Olaf Barthel

We're trying to make it real. Give us a chance, please.

Great! That's good to know.

[Warning: philosophical question ahead]

Originally Posted by Olaf Barthel

I know that there are copyright and licensing issues for the material involved, and there is doubt about where this whole effort will lead. It's comparatively safe to rework the old NDK material, but it has its limits. For example, there is no sound NDK 1.3 header file set which works well enough with existing compilers.

Well, since header files are API declarations, do you think they are copyrightable in a post-Oracle-Vs-Google Supreme court decision?

[Olaf Barthel]

Originally Posted by alkis

Great! That's good to know.

That commitment is what made the NDK 3.2 R4 work such a slog. We fixed ancient bugs in the header files, mostly related to how the many macros work which are still documented and active. A substantial part of these were vulnerable to side effects due to lack of parentheses.

Then the interface header files had to be rebuilt over and over again (at least five times) after we discovered small defects which prompted fixes for the sfd files which the interface header files were produced from. Interface header files included, NDK 3.2 R4 now contains 691 'C' header files in total. This finally covers vbcc support in all respects. We now support Lattice 'C' 4.0, Lattice 'C' 5.0, Aztec 'C' 5.0, SAS/C 5.1, SAS/C 6.x, DICE, Maxon 'C', StormC, gcc and vbcc. That's ten 'C' compilers, many of which are no longer under active development or being maintained.

The header files have also been polished and, hopefully, improved, adding documentation where previously was none, e.g. for some of the oldest graphics.library header files there are, such as "graphics/gfx.h" (what good are those many macros, for example). If possible, this will continue for subsequent NDK releases...

[Warning: philosophical question ahead]



Well, since header files are API declarations, do you think they are copyrightable in a post-Oracle-Vs-Google Supreme court decision?

I am not a lawyer, so my guess is that this kind of question can only be settled in court. Because there are multiple parties still engaged in litigation to clear up what exactly is permitted in the Amiga operating system and associated technology domain it's unclear (at least to me) whether the work we have done for the NDK 3.2 R4 is likely to end in trouble.

That work was certainly done in good faith and for the benefit of its users, regardless of what the outcome of the litigation will be. Sticking you head out is risky, but somebody had to "till this field", lest it wither away over time. This is my opinion on the matter, for now.

[bebbo]

Originally Posted by Olaf Barthel

...


We now support Lattice 'C' 4.0, Lattice 'C' 5.0, Aztec 'C' 5.0, SAS/C 5.1, SAS/C 6.x, DICE, Maxon 'C', StormC, gcc and vbcc.



...

it still needs some patches to work with gcc 6.5.0b

[paraj]

@bebbo: Do you have the build scripts/steps necessary to build the cross compiler available on github? Regardless of the outcome with regards to NDK redistribution, I think that would make it easier for someone else to pick up the torch/contribute or for interested observers to battle it out themselves.
I've built gcc cross compilers in the past and it's always been a huge hassle, so any assistance in reducing that friction would really help.

Thanks again for your contributions, and I appreciate if you don't want to the extra support burden.

[alancfrancis]

Originally Posted by paraj

@bebbo: Do you have the build scripts/steps necessary to build the cross compiler available on github? .

Thanks again for your contributions, and I appreciate if you don't want to the extra support burden.

https://github.com/bebbo/amiga-gcc

[tygre]

Hi all!

Just wanted to say Thank You bebbo!

It's amazing to have a modern GCC on my Amiga!

And thanks to Camilla, Olaf, and all who improve the NDK

Cheers!

[paraj]

Originally Posted by alancfrancis

https://github.com/bebbo/amiga-gcc

I worded my post badly. I meant for building the native AmigaOS version of GCC. I just assumed that it was cross compiled under Linux and not natively, but it was or the info is already there and I can't see it.

[alancfrancis]

Originally Posted by paraj

I worded my post badly. I meant for building the native AmigaOS version of GCC. I just assumed that it was cross compiled under Linux and not natively, but it was or the info is already there and I can't see it.

Ah sorry

[alancfrancis]

I have tried the Amiga version in FS-UAE (fake A1200 with a P5 030 board and 128Mb under 3.2.1) and it just crashed immediately so I’ll wait until there’s a proper release, I think

[bebbo]

Originally Posted by alancfrancis

I have tried the Amiga version in FS-UAE (fake A1200 with a P5 030 board and 128Mb under 3.2.1) and it just crashed immediately so I’ll wait until there’s a proper release, I think

guess you haven't set a reasonable stack size...

[bebbo]

Originally Posted by paraj

I worded my post badly. I meant for building the native AmigaOS version of GCC. I just assumed that it was cross compiled under Linux and not natively, but it was or the info is already there and I can't see it.

Yet there is no recipe, it was random hacking, editing this and that plus a tad of debugging to get that far. The changes - where I'm confident it will work -are already live, others aren't.

[alancfrancis]

Originally Posted by bebbo

guess you haven't set a reasonable stack size...

As always, being accidentally offensive is my worst fear, so to be clear I meant

"I clearly dont know what I'm doing and will wait for better instructions"

not

"wow this thing is really buggy I'll wait till its better' :-)

I had stack at 32768 ? Does it need to be bigger ? Its a "recoverable alert" 0006 8881

[bebbo]

Originally Posted by alancfrancis

As always, being accidentally offensive is my worst fear, so to be clear I meant

"I clearly dont know what I'm doing and will wait for better instructions"

not

"wow this thing is really buggy I'll wait till its better' :-)

I had stack at 32768 ? Does it need to be bigger ? Its a "recoverable alert" 0006 8881

Well, to be fair: any number is a reasonable stack size. So this sounds reasonable.

that alert is my creation^^
try reading it again and again and again maybe you'll figure, what's missing:

0006 8881
00068881
0068881
068881
68881

PS:
Bonus question: Guess what you'll get, if you start it with a 68000 cpu...

[alancfrancis]

Hah! Very good on both alerts. :-) I cant see a way in FS-UAE to "add" an FPU. My real A1200 has a 68882 on the P5 board. I'll try that when I get a minute.