SpritesMind.Net

Ok, i think i got it working right now, with a single bin folder
After some tests i can say the new GCC 6.3 can perform much better in some case (when you are calling many time a small method for instance where the previous GCC 3.4.6 was not able to inline it) and generally perform better than GCC 3.4.6.
On the SGDK benchmark tests i observed a score increase from ~18000 to ~21000 in total score. But i was using -O1 with GCC 3.4.6 while i'm using -03 and others extra optimization flags with GCC 6.3 so at the end, the difference is not that important. I even observed some cases where GCC 3.4.6 was a bit faster (with -O1) but only by a very small margin... SGDK is also already using assembly for some critical parts and i always tried to profile slow parts of the library and tried to help the compiler to produce the best code so this result is not that surprising.
I still believe that for a full C project the performance difference can be much more important (20% up to 50% faster in best case), I am confident it will help for the sprite engine which is still done in 100% C code

I had to fix some stuff in the lib to get it working correctly :
- put vtimer as 'volatile' (this is expected, it should have been volatile from beginning)
- increasing the default Stack size from 0x400 to 0x800 as newer optimizations tend to consume much more stack memory...
this one was tricky to figure (stack overwriting part of heap memory which create all sort of weird bugs).

So the next SGDK will definitely use the new GCC 6.3 ! Thanks again Gligli for your big contribution here =) I was even able to reduce a bit the size of required files so the bin folder size is about 43 MB for GCC 6.3 compared to previous 26 MB for GCC 3.4.6, definitely not as much as i was expecting
One minor bad news is that despite my efforts i couldn't get GDB working with BlastEm nor GensKmod, i obtains different errors on both emulators... I think the problem is on emulator side, probably not compatible with GDB 7.12

vtimer should not be volatile. If that helps anything, that's an optimization bug.

Stef:
Great The integrated benchmark doesn't even benefit much from the new optimisations, benchmarking mainly ASM code.
About GDB, I didn't have anything to test it, so it may just be compiled wrong...

cero:
vtimer is written by an interrupt and red by the main loop, that seems like a pretty standard case of needing volatile (being updated "behind the back" of the main loop).

@cero>vtimer should be volatile as it's modified externally by the vint : the waitTick(..) call the getSubTick() and if vtimer is not volatile then the compiler can try to optimize the whole...

@gligli> I'm almost certain the problem is on emulator side about GDB don't worry. For the benchmark, yeah, lot of ASM code (for firsts tests) but not only Anyway we can still see the nice improvement

Being updated via an interrupt is no different to being updated by a function called by the main loop. It's a global variable, any function can update it.

edit: But of course, LTO knows what the other functions do. So in the LTO case, making it volatile is correct.

No, it's different as it can be updated while you're "reading" it :
While you are in the waitMs(..) method for instance, vint can happen and modify vtimer variable... no way to have this happening in classical single threaded environment.

If vtimer is not volatile main function could have it in one register while testing it endlessly, while the interruption is updating it in memory.

Stef wrote:After some tests i can say the new GCC 6.3 can perform much better in some case (when you are calling many time a small method for instance where the previous GCC 3.4.6 was not able to inline it) and generally perform better than GCC 3.4.6.

The oldest version of GCC simply doesn't do any optimization between object files (*.o, *.obj), not a single inline expansion. That means that all optimization performed are done inside the c files, there is never a whole program optimization.
A think full way to overcome this limitation is to do what is called an amalgation, append all *.c files in to single one (not my idea) on compile time, using a makefile for example.
Talking about MD programs: Binary file grows, let's say about 20% more, but if you have your code distributed between several/lots of files is way faster, perhaps measures like twice as fast (obviously all depends on the code itself).

This is all exciting news, thanks all for your efforts in getting this going!

Pretty much repeating what everybody is saying but:

cero wrote:Being updated via an interrupt is no different to being updated by a function called by the main loop. It's a global variable, any function can update it.

The change can literally happen in the middle of a sentence (let alone a whole function), so yes it needs to be volatile. Technically, it actually should be atomic, but a 68000 is only ever going to run one "thread" at a time (either main code or interrupt code), so it's good enough here.

It still won't work with values longer than 32-bit (in which case you should consider implementing mutexes or one-way queues). Not the case here, but something to take into account if the interrupt is meant to update multiple values or a struct or whatever else.

You can try the new GCC 7.1. It seems good.

In the new version numbering, .1 is the old .0. I don't recommend .0 releases in general, especially for the compiler.

FYI, gcc 6.4 is going to be released in about three weeks.

To be honest GCC 6.3 is "good enough" I think i will stick with it for sometime as long i don't meet any issues..