Kernel Updates
- martinsustek
- Posts: 117
- Joined: Sat Apr 30, 2011 11:34 am
- Location: Ostrava, Czech Republic
Re: Kernel "upgrade" -- Released!
I've used linux and gcc to compile it few months ago, but don't know which version. Maybe there's problem with order of progmem arrays - compiler may put them into program in different order than in source is (look at tiles source - it isn't one long array, but there are 3 arrays under each other). I don't know if this can be set in compiler.
Re: Kernel "upgrade" -- Released!
Took me quite some time to figure it out, but it is exactly that. Gcc 4.6.2 is putting the arrays in reverse order, for example:martinsustek wrote:I've used linux and gcc to compile it few months ago, but don't know which version. Maybe there's problem with order of progmem arrays - compiler may put them into program in different order than in source is (look at tiles source - it isn't one long array, but there are 3 arrays under each other). I don't know if this can be set in compiler.
Code: Select all
#define MAPEXTRAS_WIDTH 6
#define MAPEXTRAS_HEIGHT 2
const int mapExtras[] PROGMEM ={
6,2
,0x2,0x3,0x4,0x5,0x6,0x7,0x31,0x32,0x33,0x34,0x35,0x36};
#define MAPUNKNOWN0_WIDTH 3
#define MAPUNKNOWN0_HEIGHT 2
const int mapUnknown0[] PROGMEM ={
3,2
,0x8,0x9,0xa,0x37,0x38,0x39};
#define MAPUNKNOWN1_WIDTH 3
#define MAPUNKNOWN1_HEIGHT 2
const int mapUnknown1[] PROGMEM ={
3,2
,0xb,0xc,0xd,0x3a,0x3b,0x3c};
Code: Select all
3D30
3D20
3D10
I tried a find a way to force that order, but I couldn't. I haven't checked, but I think there will be quite a few broken games (including mine).
If anyone has an easy fix for that, it would be very helpful, rewriting the way the demos access the memory would be a big pain.
Re: Kernel "upgrade" -- Released!
Well, that sucks big time. Specially if GCC 4.6.2 don't offer some compatibility mode. Anyway, those arrays could be put in a struct since, as far as I know, members are guaranteed to be allocated in the order they are declared. Can you try that?
Re: Kernel "upgrade" -- Released!
After playing with the compiler, the linker and their flags for an hour I found -fno-toplevel-reorder , I'm gonna commit it soon,
- martinsustek
- Posts: 117
- Joined: Sat Apr 30, 2011 11:34 am
- Location: Ostrava, Czech Republic
Re: Kernel "upgrade" -- Released!
Do you know, why compiler is doing this? Is it a kind of optimalization? Is it somehow better? I rely on address arithmetic sometime (don't know why, maybe because it's usual in assembler to preserve order).
Re: Kernel "upgrade" -- Released!
-Os does that, I think it has to do with aligning the variables. It didn't make any difference in the final size on both emuze and Corrida Nebososa.
The fix is in r219Do not reorder top-level functions, variables, and "asm" statements.
Output them in the same order that they appear in the input file.
When this option is used, unreferenced static variables will not be
removed. This option is intended to support existing code which
relies on a particular ordering. For new code, it is better to use
attributes.
Enabled at level -O0. When disabled explicitly, it also imply
-fno-section-anchors that is otherwise enabled at -O0 on some targets.
Re: Kernel "upgrade" -- Released!
Awesome, great find! Thanks for fixing this.
-
- Posts: 65
- Joined: Tue Dec 08, 2009 7:44 pm
Re: Kernel "upgrade" -- Released!
Still not much love for curr_field :*(
Re: Kernel "upgrade" -- Released!
Oops forgot about this one! Thanks for reminding me about it. It's now a global flag (SYNC_FLAG_FIELD) part of sync_flags and it's been retrofitted to all video modes. Code is committed.Still not much love for curr_field :*(
-
- Posts: 65
- Joined: Tue Dec 08, 2009 7:44 pm
Re: Kernel "upgrade" -- Released!
Thanks, I'll check it out soon!