Kernel "upgrade" -- Released!

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
martinsustek
Posts: 117
Joined: Sat Apr 30, 2011 11:34 am
Location: Ostrava, Czech Republic

Re: Kernel "upgrade" -- Released!

Post by martinsustek » Sun Jan 15, 2012 1:42 am

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.

User avatar
nebososo
Posts: 188
Joined: Sun Oct 04, 2009 10:33 pm
Location: Curitiba, Paraná, Brazil
Contact:

Re: Kernel "upgrade" -- Released!

Post by nebososo » Sun Jan 15, 2012 3:55 am

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

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};
Emuze expects MapUnknown1's addresses to be MapUnknown0's + 16, but their addresses are, respectively:

Code: Select all

3D30
3D20
3D10
The order is not garanteed in C's specification (as far as I know), so we can't expect them to be right next to each other.
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.

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Kernel "upgrade" -- Released!

Post by uze6666 » Sun Jan 15, 2012 5:28 am

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?

User avatar
nebososo
Posts: 188
Joined: Sun Oct 04, 2009 10:33 pm
Location: Curitiba, Paraná, Brazil
Contact:

Re: Kernel "upgrade" -- Released!

Post by nebososo » Sun Jan 15, 2012 9:43 am

After playing with the compiler, the linker and their flags for an hour I found -fno-toplevel-reorder :D, I'm gonna commit it soon,

User avatar
martinsustek
Posts: 117
Joined: Sat Apr 30, 2011 11:34 am
Location: Ostrava, Czech Republic

Re: Kernel "upgrade" -- Released!

Post by martinsustek » Sun Jan 15, 2012 10:17 am

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

User avatar
nebososo
Posts: 188
Joined: Sun Oct 04, 2009 10:33 pm
Location: Curitiba, Paraná, Brazil
Contact:

Re: Kernel "upgrade" -- Released!

Post by nebososo » Sun Jan 15, 2012 10:28 am

-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.
Do 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.
The fix is in r219 ;)

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Kernel "upgrade" -- Released!

Post by uze6666 » Sun Jan 15, 2012 6:56 pm

Awesome, great find! Thanks for fixing this.

HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

Re: Kernel "upgrade" -- Released!

Post by HardlyUnique » Tue Jan 17, 2012 12:50 am

Still not much love for curr_field :*(

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Kernel "upgrade" -- Released!

Post by uze6666 » Tue Jan 17, 2012 5:03 am

Still not much love for curr_field :*(
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.

HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

Re: Kernel "upgrade" -- Released!

Post by HardlyUnique » Tue Jan 17, 2012 7:55 am

Thanks, I'll check it out soon! :mrgreen:

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests