GCC 6.2 toolchain for AmigaOS 3

[bebbo]

In file included from /usr/include/x86_64-linux-gnu/sys/select.h:47:0,
                 from /usr/include/x86_64-linux-gnu/sys/types.h:219,
                 from /usr/include/stdlib.h:275,
                 from /usr/include/c++/6/cstdlib:75,
                 from /usr/include/c++/6/stdlib.h:36,
                 from Array.h:4,
                 from AmigaFile.h:6,
                 from AmigaFile.cpp:3:
/usr/include/x86_64-linux-gnu/bits/time.h:30:8: error: redefinition of ‘struct timeval’
 struct timeval
        ^~~~~~~
In file included from /opt/amiga/m68k-amigaos/ndk-include/dos/dosextens.h:26:0,
                 from /opt/amiga/m68k-amigaos/ndk-include/clib/dos_protos.h:21,
                 from AmigaFile.cpp:1:
/opt/amiga/m68k-amigaos/ndk-include/devices/timer.h:30:8: error: previous definition of ‘struct timeval’
 struct timeval {

Is there some obvious error in the makefile?[/QUOTE]

/usr/include/x86_64-linux-gnu/

that's funny and not a good include path to compile for the Amiga...

[hmn]

Make infers automatically that is has to compile the objects with a C++ compiler - but you only tell it what C compiler to use (variable CC), and thus it uses the system default (c++) for your cpp files.

So you need to define and use CXX instead of CC.

[Hedeon]

You have to #ifndef either the NDK timer.h's timeval or the time.h timeval. Otherwise they clash. At least, it was that way in my includes.

[bebbo]

Originally Posted by Hedeon

You have to #ifndef either the NDK timer.h's timeval or the time.h timeval. Otherwise they clash. At least, it was that way in my includes.

there is no need for #ifdef fiddling with timeval in amiga-gcc.

[thyslo]

Originally Posted by hmn

Make infers automatically that is has to compile the objects with a C++ compiler - but you only tell it what C compiler to use (variable CC), and thus it uses the system default (c++) for your cpp files.

So you need to define and use CXX instead of CC.

Thank you, that solved it!

So this little makefile ist compiling my test app without problems:

CXX=/opt/amiga/bin/m68k-amigaos-c++
CXXFLAGS=-Wall -Wno-unused-function -noixemul -Os

APPNAME = Test

$(APPNAME): AmigaFile.o SimpleString.o main.o
  $(CXX) $(CXXFLAGS) -o $(APPNAME) AmigaFile.o SimpleString.o main.o

clean:
  rm -f *.o $(APPNAME)

[Hedeon]

Originally Posted by bebbo

there is no need for #ifdef fiddling with timeval in amiga-gcc.

Why not?

Edit:

Oh yeah.. It is already #if fiddled out in newlib ic....

#if 0
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* and microseconds */
};
#endif
#include <devices/timer.h>

[bebbo]

Originally Posted by Hedeon

Why not?

Edit:

Oh yeah.. It is already #if fiddled out in newlib ic....

#if 0
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* and microseconds */
};
#endif
#include <devices/timer.h>

random hacking prevails

[bebbo]

Originally Posted by thyslo

Thank you, that solved it!

So this little makefile ist compiling my test app without problems:

CXX=/opt/amiga/bin/m68k-amigaos-c++
CXXFLAGS=-Wall -Wno-unused-function -noixemul -Os

APPNAME = Test

$(APPNAME): AmigaFile.o SimpleString.o main.o
  $(CXX) $(CXXFLAGS) -o $(APPNAME) AmigaFile.o SimpleString.o main.o

clean:
  rm -f *.o $(APPNAME)

if you don't use features like exceptions or rtti I strongly encourage using -fno-rtti -fno-exceptions

[thyslo]

Originally Posted by bebbo

if you don't use features like exceptions or rtti I strongly encourage using -fno-rtti -fno-exceptions

For a smaller code size of the executables? I'll try it, thank you!

[Auscoder]

Originally Posted by bebbo

if you don't use features like exceptions or rtti I strongly encourage using -fno-rtti -fno-exceptions

Hey Bebbo, would be very cool if you could post the list of most recommended flags for optimization on Amiga. At least I am not super clear from reading this thread about a bunch of custom Amiga optimizations you have added. Currently using

-O3 (but I did see Ofast noted in one message)
-fomit-frame-pointer
-funroll-all-loops (gave me a large improvement which I didn't really expect)

I am also using __attribute__((__regparm__(n))) where appropriate

(Even some nice hints would be good)

[Auscoder]

Hi all I was wondering is there any documentation for the m68k-amigaos-as.exe - I am using this to compile assembly for my program built on this gcc toolchain.

Or should I just move to vasm?

[Hewitson]

Consult the as man page:

http://man7.org/linux/man-pages/man1/as.1.html

Although I would recommend vasm over as any day.

[Auscoder]

Originally Posted by Hewitson

Consult the as man page:

http://man7.org/linux/man-pages/man1/as.1.html

Although I would recommend vasm over as any day.

Thanks Hewitson, kind of got that feeling. Moved to vasm!

[bebbo]

Originally Posted by Auscoder

Hey Bebbo, would be very cool if you could post the list of most recommended flags for optimization on Amiga. At least I am not super clear from reading this thread about a bunch of custom Amiga optimizations you have added. Currently using

-O3 (but I did see Ofast noted in one message)
-fomit-frame-pointer
-funroll-all-loops (gave me a large improvement which I didn't really expect)

I am also using __attribute__((__regparm__(n))) where appropriate

(Even some nice hints would be good)

I am using

• if debugging: -g
• for C: -Os -fomit-frame-pointer
• for C++: -Os -fomit-frame-pointer -fno-rtti -fno-exceptions
• for C++ with exceptions: -Os -fomit-frame-pointer -fno-rtti

if speed matters, switching to -O3.



I'm rather using my own set/vector/string stuff with c++, since it yields smaller code. iostream is a no go too.

Originally Posted by Hewitson

Consult the as man page:

http://man7.org/linux/man-pages/man1/as.1.html

Although I would recommend vasm over as any day.

Both are like the question of the best religion. "Oh God, he converted to ..."

However, I recommend not to use any assembler code at all unless it is unavoidable. And if the generated code isn't good enough, make a suggestion on how the compiler should solve it.

[gregthecanuck]

Had a look at the makefile for the recently released AmiSSL 4.3 here: https://github.com/jens-maus/amissl/...aster/Makefile

It looks like for OS3/68K it is compiling with GCC version 2? (I presume 2.95?). Wouldn't this benefit a lot from the latest 6.x release with LTO support? I noticed for the OS4 version it pegs the GCC version at 4.04 because of issues with BASEREL support of some sort.

[midwan]

I've been trying to test the toolchain by compiling my fork of iGame (https://github.com/midwan/iGame).
I set up an environment on my Kubuntu laptop, leaving the PREFIX at the default of /opt/amiga.

I prepared a modified Makefile to use GCC instead of VBCC, and started fixing what I could along the way. I'm stuck at one point now, hence the request for any ideas/help.

It seems that when trying to compile "muimaster" (a dependency of iGame is MUI, and I've placed the mui38dev includes in the appropriate directories), I'm getting multiple errors related to the inline assembly it has.

Specifically:

In file included from /opt/amiga/m68k-amigaos/include/mui/proto/muimaster.h:6:0,
from src/iGameMain.c:29:
/opt/amiga/m68k-amigaos/include/mui/inline/muimaster.h: In function 'MUI_AslRequest':
/opt/amiga/m68k-amigaos/include/mui/inline/muimaster.h:55:19: warning: missing terminating " character
__asm volatile ("
^
/opt/amiga/m68k-amigaos/include/mui/inline/muimaster.h:55:19: error: missing terminating " character
/opt/amiga/m68k-amigaos/include/mui/inline/muimaster.h:56:3: error: expected string literal before 'jsr'
jsr a6@(-0x36)"
^~~
/opt/amiga/m68k-amigaos/include/mui/inline/muimaster.h:56:9: error: stray '@' in program
jsr a6@(-0x36)"
^
/opt/amiga/m68k-amigaos/include/mui/inline/muimaster.h:56:17: warning: missing terminating " character
jsr a6@(-0x36)"
^


and so on...

The GCC parameters I've used are: -noixemul -Os -fomit-frame-pointer (and the include paths of course).

Is there something I'm missing?

[pipper]

I did get it to compile with minor tweaks to the toolchain: https://github.com/mheyer32/amiga-gcc

And a bit of fiddling with the Source: https://github.com/mheyer32/iGame

Let me know if it actually worked; I didn’t test the executable

[midwan]

Hmm, what tweaks did you do to the toolchain? Your fork doesn't indicate any extra commits from you.

I saw the change you made in iGame's source, and besides removing #include <proto/muimaster.h> I had also done the same. And you didn't add any include paths?

But it still doesn't compile on my side :-/

[pipper]

Originally Posted by midwan

Hmm, what tweaks did you do to the toolchain? Your fork doesn't indicate any extra commits from you.

I saw the change you made in iGame's source, and besides removing #include <proto/muimaster.h> I had also done the same. And you didn't add any include paths?

But it still doesn't compile on my side :-/

Check out the guigfx branch. It adds the guigfx_mcc lib to the sdk and fixed some issue with muimaster
https://github.com/mheyer32/amiga-gcc/commits/guigfx

[midwan]

Thanks, I'll look into that and see.

Meanwhile, I found it strange that using the toolchains bundled "vbcc" it fails to compile (received an "Ouf of memory" error!), while it compiles normally with a standalone separate VBCC installation (e.g. following my guide here: https://blitterstudio.com/setting-up...ross-compiler/). Perhaps it has to do with the target configs? I didn't spend too much time to troubleshoot this.

@bebbo: could we get the target configs in the toolchain also, or otherwise "fix" the VBCC installation? It would be great if we could have one up-to-date toolchain that people can use, including both compilers.