GCC 6.2 toolchain for AmigaOS 3

[bebbo]

Originally Posted by mateusz_s

Thanks for answer @Bebbo, I will try compile this using make file and compiling separately all .c files into .o and then merge it

plus I recommend using WSL instead of msys2 or cygwin!


https://franke.ms/amiga/wsl2.wiki

[mateusz_s]

Originally Posted by bebbo

or some of the libs aren't build with -mhard-float?

Unfortunately
I tried compile separate every .c file using MAKE like this, but the effect is still the same

HEADERS = main.h BM_Bitmap.h BM_Bitmap_TGA.h EM_Engine_Main.h GP_Gameplay.h IO_In_Out.h LV_Level.h MY_Draw.h MY_Math.h MY_Typedefs.h RC_Raycaster.h TM_Timer.h

CC = m68k-amigaos-gcc

LIBS = -lm

FLAGS = -pg -g -O3 -noixemul -m68060 -mhard-float -funroll-loops

default: ray

BM_Bitmap.o: BM_Bitmap.c $(HEADERS)
	$(CC) $(FLAGS) -c BM_Bitmap.c $(LIBS) -o BM_Bitmap.o

BM_Bitmap_TGA.o: BM_Bitmap_TGA.c $(HEADERS)
	$(CC) $(FLAGS) -c BM_Bitmap_TGA.c $(LIBS) -o BM_Bitmap_TGA.o

GP_Gameplay.o: GP_Gameplay.c $(HEADERS)
	$(CC) $(FLAGS) -c GP_Gameplay.c $(LIBS) -o GP_Gameplay.o

LV_Level.o: LV_Level.c $(HEADERS)
	$(CC) $(FLAGS) -c LV_Level.c $(LIBS) -o LV_Level.o

MY_Draw.o: MY_Draw.c $(HEADERS)
	$(CC) $(FLAGS) -c MY_Draw.c $(LIBS) -o MY_Draw.o

MY_Math.o: MY_Math.c $(HEADERS)
	$(CC) $(FLAGS) -c MY_Math.c $(LIBS) -o MY_Math.o

RC_Raycaster.o: RC_Raycaster.c $(HEADERS)
	$(CC) $(FLAGS) -c RC_Raycaster.c $(LIBS) -o RC_Raycaster.o

TM_Timer.o: TM_Timer.c $(HEADERS)
	$(CC) $(FLAGS) -c TM_Timer.c $(LIBS) -o TM_Timer.o

EM_Engine_Main.o: EM_Engine_Main.c $(HEADERS)
	$(CC) $(FLAGS) -c EM_Engine_Main.c $(LIBS) -o EM_Engine_Main.o

main.o: main.c
	$(CC) $(FLAGS) -c main.c $(LIBS) -o main.o

ray: main.o BM_Bitmap.o BM_Bitmap_TGA.o EM_Engine_Main.o GP_Gameplay.o LV_Level.o MY_Draw.o MY_Math.o RC_Raycaster.o TM_Timer.o
	$(CC) $(FLAGS) main.o BM_Bitmap.o BM_Bitmap_TGA.o EM_Engine_Main.o GP_Gameplay.o LV_Level.o MY_Draw.o MY_Math.o RC_Raycaster.o TM_Timer.o $(LIBS) -o ray

[Samurai_Crow]

I think the linking stage needs different flags than the compiling stages.

[emiespo]

Hi all!
First of all thanks Bebbo for the great toolchain, I am trying to build a datatype (and re-learning Amiga C-stuff after many years...).

Starting from this example: http://aminet.net/package/dev/c/C_V44-DT

I managed to go past the compilation phase after adjusting all the __saveds and inline registers stuff.

However, I am now stuck with this error, tried lots of compiler/linker options, but I am not really sure what's wrong (also could not find it anywhere else, hence I decided to post it here):

/opt/amiga/bin/m68k-amigaos-gcc -noixemul -nostartfiles -fbaserel -s -lm -pg -o samplePNM.datatype libfuncs.o StartUp.o LibInit.o -ldebug -lc -lamiga
/opt/amiga/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: libfuncs.o: in function `ObtainPicClass':
libfuncs.o:(.text+0x4): undefined reference to `__restore_a4'

it's my understanding that -fbaserel should work with __saveds and use a4 as . Any help please? TIA!

[pipper]

Since you’re not linking the regular startfiles, you’ll have to provide your own implementation.
You can do this like shown here:

https://github.com/mheyer32/dopus5al.../libinit.c#L62

[mateusz_s]

Originally Posted by bebbo

plus I recommend using WSL instead of msys2 or cygwin!


https://franke.ms/amiga/wsl2.wiki

Hi @Bebbo,
Thanks for answer,

I am using WLS, I build the setup/buildwin file, the installer was made
but the output files like m68k-amigaos-gcc was not windows executable?

Do you suggest using only Linux insted of Windows?
If not, how can I make the windows bins myself?

Thanks you in advance.

[bebbo]

Originally Posted by mateusz_s

Hi @Bebbo,
Thanks for answer,

I am using WLS, I build the setup/buildwin file, the installer was made
but the output files like m68k-amigaos-gcc was not windows executable?

Do you suggest using only Linux insted of Windows?
If not, how can I make the windows bins myself?

Thanks you in advance.

I recommend using WSL to compile and debug. I even run Eclipse to develop C/C++ within WSL.
You find all your windows drives at /mnt/c etc.p.p. so if you open a WSL bash you can cd and make also on your windows drives. Or create softlinks to folders on the Windows side, or ... or .... This way I copy created files into the WinUAE folder and run it there. For simple not hardware related stuff, also vamos is great to test these directly.

I also mounted the linux drive as U: (like unix) to access all the Linux stuff from Windows too.


If you want Windows executables you have to build these via Cygwin oder MSys2. But it's sooo slooooooooooow.....

[mateusz_s]

Originally Posted by bebbo

I recommend using WSL to compile and debug. I even run Eclipse to develop C/C++ within WSL.
You find all your windows drives at /mnt/c etc.p.p. so if you open a WSL bash you can cd and make also on your windows drives. Or create softlinks to folders on the Windows side, or ... or .... This way I copy created files into the WinUAE folder and run it there. For simple not hardware related stuff, also vamos is great to test these directly.

I also mounted the linux drive as U: (like unix) to access all the Linux stuff from Windows too.


If you want Windows executables you have to build these via Cygwin oder MSys2. But it's sooo slooooooooooow.....

GOT IT!
Thank You

[bebbo]

Originally Posted by pipper

Since you’re not linking the regular startfiles, you’ll have to provide your own implementation.
You can do this like shown here:

https://github.com/mheyer32/dopus5al.../libinit.c#L62

it's not related to the toolchain - but why do so many people use -fbaserel to create libraries, if you could store all your data in your library via a6?

[emiespo]

Originally Posted by bebbo

it's not related to the toolchain - but why do so many people use -fbaserel to create libraries, if you could store all your data in your library via a6?

Originally Posted by pipper

Since you’re not linking the regular startfiles, you’ll have to provide your own implementation.
You can do this like shown here:

https://github.com/mheyer32/dopus5al.../libinit.c#L62

Thanks pipper, that worked! Although the file is 600 bytes bigger than the pre-compiled example eheh. I'll investigate...

@bebbo: I am basically re-learning AmigaOS, libraries, etc. etc... is there any documentation explaining what all these options do? I'd be glad to read it!

I only tried to readapt that example (on Aminet) which in turn recommends looking at another example meant for libraries, and it seems it won't work without -fbaserel (there's a warning pointing at it for __saveds__) ... but as I said: I am relearning and might be doing many things wrong! Sorry about that!

[bebbo]

Originally Posted by emiespo

Thanks pipper, that worked! Although the file is 600 bytes bigger than the pre-compiled example eheh. I'll investigate...

@bebbo: I am basically re-learning AmigaOS, libraries, etc. etc... is there any documentation explaining what all these options do? I'd be glad to read it!

I only tried to readapt that example (on Aminet) which in turn recommends looking at another example meant for libraries, and it seems it won't work without -fbaserel (there's a warning pointing at it for __saveds__) ... but as I said: I am relearning and might be doing many things wrong! Sorry about that!

I stripped my library file to create a lib skeleton and attached it. (I also started with one of the examples). I also added a mathieeesingbas.library created this way, to support KICK 1.3...



If you follow this recipe, you simply link the library with.

m68k-amigaos-gcc -nostartfiles -o "your.library"  f1.o ...

You can also link against libs (-noixemul) as long you don't use stdio, or other stuff which needs globals.



All lib bases are kept in your mylib struct and are fetched into a local variable - or you provide defines to access the member...



And in the resulting library there should be no data segment at all. Thus code generation and linking does not need any special stuff.

[Bartman]

Originally Posted by mateusz_s

Hi @Bebbo,
Thanks for answer,

I am using WLS, I build the setup/buildwin file, the installer was made
but the output files like m68k-amigaos-gcc was not windows executable?

Do you suggest using only Linux insted of Windows?
If not, how can I make the windows bins myself?

Thanks you in advance.

Of course you can also generate Windows binaries with WSL: Check
https://github.com/BartmanAbyss/vsco...-debug#porting how I did it. (You would have to adapt to bebbo's toolchain)

[mateusz_s]

Originally Posted by Bartman

Of course you can also generate Windows binaries with WSL: Check
https://github.com/BartmanAbyss/vsco...-debug#porting how I did it. (You would have to adapt to bebbo's toolchain)

Thank You Bartman

[mateusz_s]

Hello,
Can we "fix it" somehow?

1.
CyberGfxBase = OpenLibrary("cybergraphics.library", CYBERGFXVERSION);

**** pointer targets in initialization differ in signedness [-Wpointer-sign] ****

2.
OpenDevice("timer.device", 0, &TM_timer_request, 0);

**** pointer targets in initialization differ in signedness [-Wpointer-sign] ****



Thank you

[hooverphonique]

Originally Posted by mateusz_s

Hello,
Can we "fix it" somehow?

1.
CyberGfxBase = OpenLibrary("cybergraphics.library", CYBERGFXVERSION);

**** pointer targets in initialization differ in signedness [-Wpointer-sign] ****

You could configure your compiler to use the same char signedness as the prototypes for those functions, perhaps..

[alkis]

Originally Posted by mateusz_s

Hello,
Can we "fix it" somehow?

1.
CyberGfxBase = OpenLibrary("cybergraphics.library", CYBERGFXVERSION);

**** pointer targets in initialization differ in signedness [-Wpointer-sign] ****

2.
OpenDevice("timer.device", 0, &TM_timer_request, 0);

**** pointer targets in initialization differ in signedness [-Wpointer-sign] ****



Thank you

try adding -Wno-pointer-sign in compiler flags

[mateusz_s]

Hello @bebbo,

Could you please take a look at this asm sources generated by GCC 6.5.0b ?

I am also adding interactive version from your website online compiler to see all the C code.

This function draws floor and ceiling on fullscreen at 32bits.
- the FAST variant have fixed constant index
- the SLOW variant have variable index


FAST

u_int32 texture_current_pixel = level_textures[0].row[texture_pixel_x][texture_pixel_y];

SLOW

 if (is_floor)
 {
    texture_index = RC_level->map[curr_cell_x + (curr_cell_y << LV_MAP_SIZE_BITSHIFT)].floor_id;
}
else
{
    texture_index = RC_level->map[curr_cell_x + (curr_cell_y << LV_MAP_SIZE_BITSHIFT)].ceil_id;
}

u_int32 texture_current_pixel = level_textures[texture_index].row[texture_pixel_x][texture_pixel_y];

The problem is, that difference in C code is very small, but the difference in ASM code and performace is hudge.
So I just wonder if the SLOWER source is generated rigth or maybe are some not optimal instructions?

for example: on V6, the FAST version is 70fps, and the SLOW is 37fps..
but on winuae as 060 the result is also the same.. I mean 2x slower


This is comparision of the two sources generated direct from my compiler, You can see a big difference:
https://www.diffchecker.com/1a3U053H

and this is interactive full code version from Bebbos Online Compiler with the same flags:
FAST: http://franke.ms/cex/z/bMTKj5
SLOW: http://franke.ms/cex/z/Wq1qz7


I can't say if outputs from my compiler and online compiler are the same..

I don't know assembler, but I have comments that there is an uneccesary use of bfext instead of simple masking which is 6 times slower..

ps. I was compiling using that preinstaled windows distro of gcc 6.5.0b

Thank You in advance

[bebbo]

Originally Posted by mateusz_s

Hello @bebbo,

Could you please take a look at this asm sources generated by GCC 6.5.0b ?

I am also adding interactive version from your website online compiler to see all the C code.

This function draws floor and ceiling on fullscreen at 32bits.
- the FAST variant have fixed constant index
- the SLOW variant have variable index


FAST

u_int32 texture_current_pixel = level_textures[0].row[texture_pixel_x][texture_pixel_y];

SLOW

 if (is_floor)
 {
    texture_index = RC_level->map[curr_cell_x + (curr_cell_y << LV_MAP_SIZE_BITSHIFT)].floor_id;
}
else
{
    texture_index = RC_level->map[curr_cell_x + (curr_cell_y << LV_MAP_SIZE_BITSHIFT)].ceil_id;
}

u_int32 texture_current_pixel = level_textures[texture_index].row[texture_pixel_x][texture_pixel_y];

The problem is, that difference in C code is very small, but the difference in ASM code and performace is hudge.
So I just wonder if the SLOWER source is generated rigth or maybe are some not optimal instructions?

for example: on V6, the FAST version is 70fps, and the SLOW is 37fps..
but on winuae as 060 the result is also the same.. I mean 2x slower


This is comparision of the two sources generated direct from my compiler, You can see a big difference:
https://www.diffchecker.com/1a3U053H

and this is interactive full code version from Bebbos Online Compiler with the same flags:
FAST: http://franke.ms/cex/z/bMTKj5
SLOW: http://franke.ms/cex/z/Wq1qz7


I can't say if outputs from my compiler and online compiler are the same..

I don't know assembler, but I have comments that there is an uneccesary use of bfext instead of simple masking which is 6 times slower..

ps. I was compiling using that preinstaled windows distro of gcc 6.5.0b

Thank You in advance

the slow variant has an inner loop whith 18 instead of 8 insns, also more memory lookups plus a multiplication - that sums up



I guess the code could be better, but first you should start to use integer math whereever possible...

Also use 32 bit for variables which are used as array index...
... try reducing shifts.



And I doubt that bitfield insns are slower on 68080...

[mateusz_s]

Hi, Thank you for answer and hints..

[bebbo]

Originally Posted by mateusz_s

Hi, Thank you for answer and hints..

if you group your statements you'll see what I mean:

            u_int32 output_pixel_index = ry_x + ry_m_render_width;

            floor_x__fp += floor_step_x__fp;
            int32 curr_cell_x_fraction__fp = (floor_x__fp & FP_FRACTION_MASK_16) >> 8;
            int32 texture_pixel_x = (int32)((128 * 256 * curr_cell_x_fraction__fp) >> 16);
            int32 curr_cell_x = (floor_x__fp & FP_INTEGER_MASK_16) >> 16;
            curr_cell_x &= LV_MAP_SIZE_m1;

curr_cell_x_fraction__fp is x>>8 and used with *256 which is <<8 ...


for curr_cell_y you end up using it with a left shift. maybe all y calculation can be done with left shifted values -> no need to shift in the loop...




... and this belongs into a separated thread...