It was easier on old compilers because said compilers didn't try things like reordering execution of code trying to get that extra 1% speed up... which is hilarious considering modern gcc for 68000 tends to be SLOWER than those old compilers.
XGM Driver issue
Moderator: Stef
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: XGM Driver issue
newer GCC gets really much better now
- Later GCC 2.x were very fast for 68k
- GCC 3.4.X were ok
- GCC 4.X and 5.X were quite bad for 68k
- GCC 6.X fixed many problems and is already very fast for 68k (with -03 opt level at least)
and it seems than GCC 7.X and 8.X can even do better (not much i guess).
- Later GCC 2.x were very fast for 68k
- GCC 3.4.X were ok
- GCC 4.X and 5.X were quite bad for 68k
- GCC 6.X fixed many problems and is already very fast for 68k (with -03 opt level at least)
and it seems than GCC 7.X and 8.X can even do better (not much i guess).
Re: XGM Driver issue
I am using gcc 8.2 but i did my tests also with gcc 6.3 and 7.2, and with all of them i have the issue.
Probably one day i will try to make some performance test with different gccs, it can be interesting.
Probably one day i will try to make some performance test with different gccs, it can be interesting.
The man who moves a mountain begins by carrying away small stones. Confucius, 551-479 BC
Re: XGM Driver issue
As after some weekend party is a great moment for coding xD, i decide to check a bit the "volatile" pointers causing the issue.
I tested adding a "volatile" keyword to every var accessing memory, and (at least in emulators Blastem and KMod, can't test in real hardware) i can make music samples sound perfectly.
Checking one by one, the volatile that fixed the sound is the var used at Z80_upload function, line 159 of z80_ctrl.c:
u8* dst = (u8*) (Z80_RAM + to); => volatile u8* dst = (u8*) (Z80_RAM + to);
Just with that change, music sounds good (tested with -Ofast and -O3).
I would recomend you adding the volatile keyword to all the Z80_RAM access (i saw it in various functions) and the *pb pointer in Z80_loadDriver function (line 263).
EDIT: tested and working now on a Mega Drive.
I tested adding a "volatile" keyword to every var accessing memory, and (at least in emulators Blastem and KMod, can't test in real hardware) i can make music samples sound perfectly.
Checking one by one, the volatile that fixed the sound is the var used at Z80_upload function, line 159 of z80_ctrl.c:
u8* dst = (u8*) (Z80_RAM + to); => volatile u8* dst = (u8*) (Z80_RAM + to);
Just with that change, music sounds good (tested with -Ofast and -O3).
I would recomend you adding the volatile keyword to all the Z80_RAM access (i saw it in various functions) and the *pb pointer in Z80_loadDriver function (line 263).
EDIT: tested and working now on a Mega Drive.
The man who moves a mountain begins by carrying away small stones. Confucius, 551-479 BC
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: XGM Driver issue
Well done !
I've to admit i don't really understand why it requires the volatile keyword at this location specifically. We are just writing to Z80 RAM, normally volatile is important on read access except if it keep track of previous written values eventually but shouldn't be the case here...
Anyway, as Z80 can modify this RAM on its own, it make senses to put it as volatile, i will patch SGDK to take care of this.
It's really weird that i don't meet the same issue as you as i'm using GCC 6.3 with -O3 as well, but anyway for future it's safer...
Thanks again for having inspecting and reporting your founds
I've to admit i don't really understand why it requires the volatile keyword at this location specifically. We are just writing to Z80 RAM, normally volatile is important on read access except if it keep track of previous written values eventually but shouldn't be the case here...
Anyway, as Z80 can modify this RAM on its own, it make senses to put it as volatile, i will patch SGDK to take care of this.
It's really weird that i don't meet the same issue as you as i'm using GCC 6.3 with -O3 as well, but anyway for future it's safer...
Thanks again for having inspecting and reporting your founds
Re: XGM Driver issue
If GCC even remotely suspects it could optimize a memory access into something else, it will gladly optimize it away. So yes, Z80 RAM accesses need to be volatile (e.g. if you only ever write to an address, GCC may assume the value is thrown away and get rid of all those writes).
Sorta related: writing to arrays that will be DMA'd later has the same issue (GCC notices you aren't reading back from them and outright may get rid of all the writes, while ignoring that the VDP needs that data), so those need to be volatile too. Also it seems GCC is a lot more aggressive about this kind of optimization if you're daring to use -mshort…
Sorta related: writing to arrays that will be DMA'd later has the same issue (GCC notices you aren't reading back from them and outright may get rid of all the writes, while ignoring that the VDP needs that data), so those need to be volatile too. Also it seems GCC is a lot more aggressive about this kind of optimization if you're daring to use -mshort…
Sik is pronounced as "seek", not as "sick".
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: XGM Driver issue
Yeah, GCC optimizations can become insane in some ways, you have to think about all edge cases and put volatile where it need to be. In fact any memory touched (read or write) by something else that the 68000 (VDP, Z80, DMA...) should be declared as volatile.