GCC 6.2 toolchain for AmigaOS 3

[Paul1962]

Hi,
I've been using this toolchain for a while now for my Amiga, the enhancements by bebbo are really useful.
I have other 68k/coldfire boards which I'm using gcc for but obviously without the enhancements.
Just wondered if anyone had got this toolchain to compile for m68k-elf ?
Tried it myself but binutils fails to build and if I get past that gcc fails with various undefines etc.
Happy to put in the work, just didn't want to reinvent the wheel.
Or maybe the mods are so amigaos specific that compiling for m68k-elf while keeping the improvements isn't on ?

If this is deemed off topic please delete.

Paul

[Samurai_Crow]

Originally Posted by Paul1962

Hi,
I've been using this toolchain for a while now for my Amiga, the enhancements by bebbo are really useful.
I have other 68k/coldfire boards which I'm using gcc for but obviously without the enhancements.
Just wondered if anyone had got this toolchain to compile for m68k-elf ?
Tried it myself but binutils fails to build and if I get past that gcc fails with various undefines etc.
Happy to put in the work, just didn't want to reinvent the wheel.
Or maybe the mods are so amigaos specific that compiling for m68k-elf while keeping the improvements isn't on ?

If this is deemed off topic please delete.

Paul

AROS uses ELF binaries but not Bebbo's GCC except for some AmigaOS 68k compatibility. Look into that instead. Bebbo's GCC is Hunk formatted, not ELF.

[Paul1962]

Originally Posted by Samurai_Crow

AROS uses ELF binaries but not Bebbo's GCC except for some AmigaOS 68k compatibility. Look into that instead. Bebbo's GCC is Hunk formatted, not ELF.

Thanks for your reply.
I’ll take a look at AROS and see what it produces.
I’m currently using GCC 9.2 built for m68k-elf but the code generated by Bebbo’s gcc is considerably more efficient.

Paul

[bebbo]

Originally Posted by Samurai_Crow

AROS uses ELF binaries but not Bebbo's GCC except for some AmigaOS 68k compatibility. Look into that instead. Bebbo's GCC is Hunk formatted, not ELF.

the binutils are using hunk not gcc. gcc generates asm source code.

[alkis]

I am trying to compile lua for A500 1.3.
Exe comes out fine, works on A1200. On A500 needs locale.library. What triggers the autoinit for locale.library? Does 1.3 have a locale.library? Any tricks/switches to exclude locale.library?

[bebbo]

Originally Posted by alkis

I am trying to compile lua for A500 1.3.
Exe comes out fine, works on A1200. On A500 needs locale.library. What triggers the autoinit for locale.library? Does 1.3 have a locale.library? Any tricks/switches to exclude locale.library?

provide dummy functions for setlocale(...) and friends or create a dummy locale.library for 1.3^^

[Toni Wilen]

Is it possible to have KS 1.x compatibility and use compiler's softfloat math libraries?

I implemented FPU support to my cpu tester and I need to print floating point values (scientific notation is fine). It needs to support Motorola 80-bit extended (long double) format, including very very very large and very very very small numbers (larger and smaller than double can support) and NaNs and infinities. Performance does not matter, this code is only used to output error reports.

Library is allowed to use FPU but only if FPU is used when calling (s)printf() (Which is unlikely, some init code surely executes some FPU instructions?). Program must still run normally in non-FPU test mode. Separate FPU version is out of the question.

It is also allowed to require KS 3.0+ when calling (s)printf() when printing floating point values.

Another option is to use custom code but printing human readable floating points is painfully boring to do.. (And most likely most existing code uses Intel extended doubles which don't have exactly same format as Motorola. Extended unfortunately is not IEEE standard) Also use of Amiga math libraries directly is not possible, program must be mostly portable.

(Yes, I know. Weird special requirements again..)

[bebbo]

Originally Posted by Toni Wilen

Is it possible to have KS 1.x compatibility and use compiler's softfloat math libraries?

I implemented FPU support to my cpu tester and I need to print floating point values (scientific notation is fine). It needs to support Motorola 80-bit extended (long double) format, including very very very large and very very very small numbers (larger and smaller than double can support) and NaNs and infinities. Performance does not matter, this code is only used to output error reports.

Library is allowed to use FPU but only if FPU is used when calling (s)printf() (Which is unlikely, some init code surely executes some FPU instructions?). Program must still run normally in non-FPU test mode. Separate FPU version is out of the question.

It is also allowed to require KS 3.0+ when calling (s)printf() when printing floating point values.

Another option is to use custom code but printing human readable floating points is painfully boring to do.. (And most likely most existing code uses Intel extended doubles which don't have exactly same format as Motorola. Extended unfortunately is not IEEE standard) Also use of Amiga math libraries directly is not possible, program must be mostly portable.

(Yes, I know. Weird special requirements again..)

have you tried to modify the linkers lib path order to pick the libgcc's libm.a first?

[Toni Wilen]

Originally Posted by bebbo

have you tried to modify the linkers lib path order to pick the libgcc's libm.a first?

Details and command line please. I don't want to know gcc details too much, because they usually don't make much sense..

[thyslo]

A quick question. I'm compiling a C++ project with these settings:

-noixemul -fomit-frame-pointer -fno-exceptions -fno-rtti -Wall -Os -s

Then thinking about using some exceptions here and there. Removing the -fno-exceptions and throwing one exception to test it. Exception handling works great but binary size increased from about 50K to 150K.

I've read somewhere that turning on C++ exceptions increases the binary size by about 10%. So I'm confused why I got this big increase instead. What could be the reason?

[jotd]

probably because everything is statically linked here. On "modern" platforms, the C++ run time is dynamic (DLL/.so) by default.

[thyslo]

Yeah this could be the reason.

When I compile the same project with old StormC4 (gcc 2.95) the use exceptions blows the binary from about 77K to 83K so I was hoping the modern gcc6.5 would act in the same overhead area.

[bebbo]

Originally Posted by thyslo

Yeah this could be the reason.

When I compile the same project with old StormC4 (gcc 2.95) the use exceptions blows the binary from about 77K to 83K so I was hoping the modern gcc6.5 would act in the same overhead area.

the main difference is the exception kind.


gcc 2.95 is using sjlj = setjump longjump, which means that on every try/catch block setjump is used to snapshot the state and affects the runtime


gcc 6.5 is using seh = structured exception handling, which has no runtime overhead unless an exception is thrown. Then some additional structures + some code are used to figure out what do and how to set the state correctly.


So there is a one time malus from the seh functions plus the (maybe) 10% overhead to provide the static info to reconstruct the state.


Try a loop containing a try catch block and you can measure the performance difference.

[TomSoniq]

Hi, I've got a link library written in C++ which exports plain C functions to access it. It dynamically creates and destroys objects, so it makes use of the new and delete operators. This works great with this toolchain.

Now I'm trying to wrap a shared library around it.

First some strange things I noticed:
Since it's a shared library I compile it with -noixemul -nostartfiles
But the linker complains about missing symbols: exit and _WBenchMsg ?!?
Alright, to please it I've put an exit() function and a NULL initialized _WBenchMsg pointer in my code.

So far so good, now it compiles.

But when I open it from my application (which is plain C) it happily enters the exported C function but crashes as soon as it reaches the new operator (even if the constructor of the corresponding class is empty).

Any idea what could be wrong? Is this supposed to work at all?
Can I build a shared library with all the C++ runtime code (especially new and delete) linked to it? So that I can access it from a plain C application?

[bebbo]

Originally Posted by TomSoniq

Hi, I've got a link library written in C++ which exports plain C functions to access it. It dynamically creates and destroys objects, so it makes use of the new and delete operators. This works great with this toolchain.

Now I'm trying to wrap a shared library around it.

First some strange things I noticed:
Since it's a shared library I compile it with -noixemul -nostartfiles
But the linker complains about missing symbols: exit and _WBenchMsg ?!?
Alright, to please it I've put an exit() function and a NULL initialized _WBenchMsg pointer in my code.

So far so good, now it compiles.

But when I open it from my application (which is plain C) it happily enters the exported C function but crashes as soon as it reaches the new operator (even if the constructor of the corresponding class is empty).

Any idea what could be wrong? Is this supposed to work at all?
Can I build a shared library with all the C++ runtime code (especially new and delete) linked to it? So that I can access it from a plain C application?

linking stdlibs into a library - obviously without startup - means that nothing is initialized properly... adding c++ may adds further stuff which needs initialization. And exceptions thrown from a library...


* do not add dummy functions.
* check what gets linked and judge if it's necessary and properly intialized.
* use own functions if a lib function causes linking tons of stuff
* disable exceptions and rtti
* ...

[TomSoniq]

Ah thanks! I've learnt a lot. Can I turn of this automatic linking somehow?
And can you please tell me where I can find the source code of these standard libs? So that I can clearly see which functions in it can run without prior initialisation? And so that I can learn how this initialisation is done?


Thanks,
Tom

[thyslo]

I'm using this toolchain for a bigger c++ project. Recently I enabled exceptions with the result that the binary no longer runs on a plain 68000 CPU. On such a machine it crashes without warning. It needs at least an 68020 to run.

As bebbo explained on GitHub, the crash on 68000s might not be fixable: "exception info may lead to a word read from an odd address, which raises an address error trap on the 68000."

But I don’t want it simply to crash on 68000 machines. Instead I’d like to have a message "This program needs at least an 68020 to run." printed to stdout.

So, is it possible to link an own startup code that performs this check before the program really starts? How could this be done?

[jotd]

Maybe running run68017 before the program can workaround the issues. Linking startup code is slightly trickier.

I've tried to put the check first thing in "main" but to no avail... also tried "-fno-exceptions" => still crashes

[bebbo]

Originally Posted by thyslo

I'm using this toolchain for a bigger c++ project. Recently I enabled exceptions with the result that the binary no longer runs on a plain 68000 CPU. On such a machine it crashes without warning. It needs at least an 68020 to run.

As bebbo explained on GitHub, the crash on 68000s might not be fixable: "exception info may lead to a word read from an odd address, which raises an address error trap on the 68000."

But I don’t want it simply to crash on 68000 machines. Instead I’d like to have a message "This program needs at least an 68020 to run." printed to stdout.

So, is it possible to link an own startup code that performs this check before the program really starts? How could this be done?

if you compile and link with

  -noixemul -m68020

the program should show a recoverable alert with something like 00068020
... if not ... uhm ... it needs a fix^^

[ciVic]

Hi all!

I'm trying this:

#include <string>
#include <fstream>
#include <iostream>
using namespace std;

int main (int argc, char *argv[])
{
    cout << "running test" << endl;
    ofstream out("test.dat");
    out << "Hallo Welt";
    out.close();
    return 0;
}

Compiling this way writes data to file but crashes afterwards:

m68k-amigaos-g++  -mcrt=clib2  main.cpp

If I omit -mcrt=clib2 it works. I'm using m68k-amigaos-g++ (GCC) 6.5.0b 200706181046 and my last pull was last week.