GCC 6.2 toolchain for AmigaOS 3

[Samurai_Crow]

Originally Posted by 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.

If CLib2 doesn't work, try LibNix.

[ciVic]

Originally Posted by Samurai_Crow

If CLib2 doesn't work, try LibNix.

Thx but I have no choice. I need a lib that was compiled with clib2 and then the exe cannot use a different system afaik.

[Warty]

What's the current version of Bebbo's bgdbserver? The link on his page to version 6 is a 404. I was working on some code for deleting files recursively, and well, I seem to have deleted the contents of my 'test' directory, including bgdbserver. Version 5 is available on the web site, but I think that's an older version, as it requires -r.

Is there a version 7 coming? Anybody have a link to 6 I could use?

404:
https://franke.ms/amiga/bgdbserver_6.zip

from:
https://franke.ms/amiga/gdb-eclipse.wiki

[bebbo]

Originally Posted by Warty

What's the current version of Bebbo's bgdbserver? The link on his page to version 6 is a 404. I was working on some code for deleting files recursively, and well, I seem to have deleted the contents of my 'test' directory, including bgdbserver. Version 5 is available on the web site, but I think that's an older version, as it requires -r.

Is there a version 7 coming? Anybody have a link to 6 I could use?

404:
https://franke.ms/amiga/bgdbserver_6.zip

from:
https://franke.ms/amiga/gdb-eclipse.wiki

the correct link is: https://franke.ms/download/bgdbserver_6.zip - I updated the page. Thank you!

[Warty]

Awesome, thanks Bebbo!

[mateusz_s]

Originally Posted by bebbo

the correct link is: https://franke.ms/download/bgdbserver_6.zip - I updated the page. Thank you!

What that server does? Is it got some special features? For testing my apps I was planning to just static win running winuae, compiling the output to shared folder, and just relaunching the exe after every new build.

[thyslo]

I try to port some code from SAS-C. It's a callback function defined like this:

int __asm __saveds QBobFunc(register __a1 struct myBltNode *node)
{
...
}

Can I achive this somehow with gcc, too?

[bebbo]

Originally Posted by mateusz_s

What that server does? Is it got some special features? For testing my apps I was planning to just static win running winuae, compiling the output to shared folder, and just relaunching the exe after every new build.

the bgdbserver allows you to debug your program on the Amiga remotely.
What you need is a working TCP/IP stack on your Amiga, then you can debug the program even on a real Amiga.


debugging > printf

[bebbo]

Originally Posted by thyslo

I try to port some code from SAS-C. It's a callback function defined like this:

int __asm __saveds QBobFunc(register __a1 struct myBltNode *node)
{
...
}

Can I achive this somehow with gcc, too?

int __saveds QBobFunc(struct myBltNode *node asm("a1"))
{
...
}

__saveds is only needed if a baserel data model is used - it means that the function loads the a4 register. Useful in callbacks given to someone else or interrupt handlers... the latter may also need the __interrupt attribute.

[thyslo]

Thanks a lot, this works

[zero]

Is it me or does KPrintF formatting not work? I tried this:

KPrintF("Right: %d\n", 112);

And the output is

"Right: 0"

[alkis]

Originally Posted by zero

Is it me or does KPrintF formatting not work? I tried this:

KPrintF("Right: %d\n", 112);

And the output is

"Right: 0"

Try %ld
Every parameter in variadic functions is promoted to longs (32bits)

[zero]

Originally Posted by alkis

Try %ld
Every parameter in variadic functions is promoted to longs (32bits)

Thanks, that works.

[mateusz_s]

@Bebbo Hello, I just started using Your GCC 6.5.0b from that link" https://github.com/bebbo/amiga-gcc/releases/tag/gridone

I found this strange behaviour in performance between unsigned int and ULONG/LONG types.


I made dynamic int or LONG buffer to generate graphic there:

unsigned int* my_buf_1 = (unsigned int*)malloc(size);

and copy it to rtg output using CGX api, here are the results:

*******
with flags: -O3 -noixemul -lm -Wall :

ULONG - 30fps
LONG - 70fps
int / unsigned int - 171 fps

with theese flags: -O3 -noixemul -lm -Wall -march=68060 -mcpu=68060 -mtune=68060 -mhard-float -68881:

ULONG - 70fps
LONG - 70fps
int / unsigned int - 180 fps

*******

You can see the differences in both generated asm sources,
generated by this Diffchecker website by one of ppa.pl portal users @san_u:
https://www.diffchecker.com/gi3FDbkt

[mschulz]

Originally Posted by mateusz_s

@Bebbo Hello, I just started using Your GCC 6.5.0b from that link" https://github.com/bebbo/amiga-gcc/releases/tag/gridone

I found this strange behaviour in performance between unsigned int and ULONG/LONG types.

Hi. If you want to analyze code, always try to make a test case which is short enough to allow one to analyze it properly. The diff you have provided is very nice, but not really optimal to follow it. I have toyed with the code a little and extracted the innermost loop which was problematic:

#include <exec/types.h>
#include <stdlib.h>

ULONG APP_requested_width = 320;
ULONG APP_requested_height = 240;
ULONG APP_requested_depth = 24;

void* APP_Main_Loop(unsigned int fade)
{
    int size = APP_requested_width * APP_requested_height * sizeof(int);
    unsigned int* my_buf_1 = (unsigned int*)malloc(size);

    for (int y = 0; y < APP_requested_height; ++y)
        for(int x = 0; x < APP_requested_width; ++x)
        {
            my_buf_1[x + y * APP_requested_width] = (unsigned int)fade<<24;
        }

    return my_buf_1;
}

I have added few simplifications there, the code also returns the allocated pointer in order to prevent gcc from optimizing it away. The code compiled with flags -m68020 -m68881 -Os -fomit-frame-pointer, outputs following assembly:

_APP_requested_width:
        .long   320
_APP_requested_height:
        .long   240
_APP_requested_depth:
        .long   24
__Z13APP_Main_Loopj:
        movem.l d5/d4/d3/d2,-(sp)
        move.l _APP_requested_width,d3
        move.l _APP_requested_height,d2
        move.l d3,d0
        muls.l d2,d0
        lsl.l #2,d0
        move.l d0,-(sp)
        jsr _malloc
        move.l (24,sp),d4
        moveq #24,d1
        lsl.l d1,d4
        move.l d3,d5
        lsl.l #2,d5
        move.l d0,a0
        addq.l #4,sp
        move.l d2,d1
.L5:
        dbra d1,.L6
        clr.w d1
        subq.l #1,d1
        jcc .L6
        movem.l (sp)+,d2/d3/d4/d5
        rts
.L6:
        move.l a0,a1
        move.l d3,d2
.L4:
        dbra d2,.L7
        clr.w d2
        subq.l #1,d2
        jcc .L7
        add.l d5,a0
        jra .L5
.L7:
        move.l d4,(a1)+
        jra .L4

Here, few comments and questions. First of all, you should know few underlying details of m68k architecture if you want to obtain optimal code. The loops counting on a 32-bit type can be slower on m68k. The DBxx instructions operate on 16-bit portion of register only. Therefore, changing the counters within loop from "unsigned int" to "unsigned short", or preferably to UWORD will allow gcc to use one DBxx instruction per loop.

Another issue are width and height parameters. Do they need to be changeable? Are they changed once when your code starts or can they be made const? If the latter is the case, it would allow gcc to optimize even more. Making them const and changing ints to shorts, i.e.:

#include <exec/types.h>
#include <stdlib.h>

const ULONG APP_requested_width = 320;
const ULONG APP_requested_height = 240;
const ULONG APP_requested_depth = 24;

void* APP_Main_Loop(unsigned int fade)
{
    int size = APP_requested_width * APP_requested_height * sizeof(int);
    unsigned int* my_buf_1 = (unsigned int*)malloc(size);

    for (UWORD y = 0; y < APP_requested_height; ++y)
        for(UWORD x = 0; x < APP_requested_width; ++x)
        {
            my_buf_1[x + y * APP_requested_width] = (unsigned int)fade<<24;
        }

    return my_buf_1;
}

allows gcc to show its strength:

__Z13APP_Main_Loopj:
        move.l d3,-(sp)
        move.l d2,-(sp)
        move.l #307200,-(sp)
        jsr _malloc
        move.l (16,sp),d2
        moveq #24,d1
        lsl.l d1,d2
        move.l d0,a0
        addq.l #4,sp
        move.w #239,d1
.L3:
        move.l a0,a1
        move.w #319,d3
.L2:
        move.l d2,(a1)+
        dbra d3,.L2
        lea (1280,a0),a0
        dbra d1,.L3
        move.l (sp)+,d2
        move.l (sp)+,d3
        rts

Or, if you prefer "asm coder" solution and want to work with faster loops, add "-funroll-loops" to the flags (-m68020 -m68881 -O3 -funroll-loops -fomit-frame-pointer) to obtain:

__Z13APP_Main_Loopj:
        movem.l d4/d3/d2,-(sp)
        move.l #307200,-(sp)
        jsr _malloc
        move.l (20,sp),d1
        moveq #24,d2
        lsl.l d2,d1
        move.l d0,d4
        addq.l #4,sp
        move.w #239,d3
.L3:
        move.l d4,a0
        moveq #39,d2
.L2:
        move.l a0,a1
        move.l d1,(a1)+
        move.l d1,(a1)+
        move.l d1,(a1)
        move.l d1,(12,a0)
        move.l d1,(16,a0)
        move.l d1,(20,a0)
        move.l d1,(24,a0)
        move.l d1,(28,a0)
        lea (32,a0),a0
        dbra d2,.L2
        add.l #1280,d4
        dbra d3,.L3
        movem.l (sp)+,d2/d3/d4
        rts

[mateusz_s]

Thank You very much for very long answer. I am going to test all of that.
So do you suggest using shorts insted of ints where it is possible to have some speedups?


edit:
I must say, that I was checking different gcc flags, I switched ints into UINT8 or UINT16 where was possible,
changed width, height into CONST.. but there is almost no change at all in the performance.
It even looks like turning on/off 060/040 cpu flags doeasnt change anything..

maybe something is wrong with my gcc distribution, I used that precompiled version from msys2, that Bebo provided: http://franke.ms/download/setup-amiga-gcc.exe

Now I installed msys2 myself on Windows and build all distribution as described on Bebbos git hub page: https://github.com/bebbo/amiga-gcc

maybe that will help.. or maybe on winuae the differences can't be seen?

It looks like filling the whole buffer 320x240x32 even with simple calculations, takes ages


edit 2:
ok, it seems that all that changes works on that particular example You worked.
I run this test again there was a huge speed up..

I was talking about rest of my code, that is bigger and makes raycasts, on that code
there is no changes at all.. weird.. must be some kind of bottle neck..


edit 3:
I done more tests, and its amazing how changing WIDTH and HEIGHT from "int" into "const unsigned short" speeds up the whole thing from 190 fps to 550 fps !! (including all gcc flags you mentioned)
I have similar things in my full code - must change it and test.
Also in my full code I am dealing with RGBA struct that contains 4 unsigned chars. Thats also slows down. Must change it into unsigned int..


Thanks again..!

[mateusz_s]

@mschulz @Bebbo

The problem from above post is solved when I am compiling only one file main.c - the speed up is huuuge..

But I got a weird problem, when I am compiling multiple files like that, using this flags:

m68k-amigaos-gcc 
-Wall
-O3 -noixemul -march=68060 -mcpu=68060 -mtune=68060 -mhard-float -funroll-loops
main.c 
BM_Bitmap.c 
BM_Bitmap_TGA.c 
EM_Engine_Main.c 
GP_Gameplay.c
LV_Level.c  
MY_Draw.c 
MY_Math.c 
RC_Raycaster.c 
TM_Timer.c
-lm
 -o 
output

but when I am doing profiling theese soft-float functions are used:

__mulsf3
__subsf3
__addsf3
__ieee754_expf
__kernel_sinf
__ieee754_rem_pio2f

the efect is that everything is very sloooow again even on very fast cpus.
Additionally tutring off or on any flags makes no any effect

What am I doing wrong?

[bebbo]

Originally Posted by mateusz_s

@mschulz @Bebbo

The problem from above post is solved when I am compiling only one file main.c - the speed up is huuuge..

But I got a weird problem, when I am compiling multiple files like that, using this flags:

m68k-amigaos-gcc 
-Wall
-O3 -noixemul -march=68060 -mcpu=68060 -mtune=68060 -mhard-float -funroll-loops
main.c 
BM_Bitmap.c 
BM_Bitmap_TGA.c 
EM_Engine_Main.c 
GP_Gameplay.c
LV_Level.c  
MY_Draw.c 
MY_Math.c 
RC_Raycaster.c 
TM_Timer.c
-lm
 -o 
output

but when I am doing profiling theese soft-float functions are used:

__mulsf3
__subsf3
__addsf3
__ieee754_expf
__kernel_sinf
__ieee754_rem_pio2f

the efect is that everything is very sloooow again even on very fast cpus.
Additionally tutring off or on any flags makes no any effect

What am I doing wrong?

maybe you are not linking against -noixemul ?

[bebbo]

Originally Posted by bebbo

maybe you are not linking against -noixemul ?

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

[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