XGM Driver issue

SGDK only sub forum

Moderator: Stef

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Re: XGM Driver issue

Post by Chilly Willy » Tue Nov 20, 2018 3:05 pm

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.
:lol:

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: XGM Driver issue

Post by Stef » Tue Nov 20, 2018 4:26 pm

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).

Manveru
Very interested
Posts: 85
Joined: Wed Sep 05, 2012 3:30 pm

Re: XGM Driver issue

Post by Manveru » Tue Nov 20, 2018 6:27 pm

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.
The man who moves a mountain begins by carrying away small stones. Confucius, 551-479 BC

Manveru
Very interested
Posts: 85
Joined: Wed Sep 05, 2012 3:30 pm

Re: XGM Driver issue

Post by Manveru » Sun Dec 02, 2018 2:32 am

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.
The man who moves a mountain begins by carrying away small stones. Confucius, 551-479 BC

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: XGM Driver issue

Post by Stef » Mon Dec 03, 2018 8:13 am

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 :)

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: XGM Driver issue

Post by Sik » Mon Dec 03, 2018 3:08 pm

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…
Sik is pronounced as "seek", not as "sick".

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: XGM Driver issue

Post by Stef » Tue Dec 04, 2018 8:54 am

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.

Post Reply