gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Word alignment problem...

#3254 - CoolMan - Fri Feb 21, 2003 5:39 am

Okay, I'm trying to decompress some lz77 compressed arrays via bios calls, and I've discovered that gcc 3.1 (devkitadv for linux) is NOT aligning my data to word boundries.

(GBA is 32-bit words, which is 4 byte, which is why I keep hearing that the addy of your compressed data must be divisable by 4... right?)

I wrote a simple catch.

Code:

   if( ((u32)mypic) != (u32)(((u32)mypic >> 2) << 2) ) //Check to make sure this addy is on a word boundry.
      {
      dprints("WARNING!!! Attempting to decompress an image whose beginning is not on a word boundry.\n");
      sprintf(tstring, "Word Boundry: 0x%X, Actual Address: 0x%X\n", (u32)(((u32)mypic >> 2) << 2), ((u32)mypic));
      dprints(tstring);
      }


This worked at one point, but now my linker suddenly feels like mis-aligning all of this stuff...

So, my questions is, how do I force word alignment?

Thanks in advance...
_________________
Moron! You don't herd chickens with a shotgun!

--CoolMan

#3256 - CoolMan - Fri Feb 21, 2003 6:19 am

Okay, I guess I'm retarded. I forgot that gcc only aligns variables based on their type. (For ease of coding, my little bin2c tool was outputting the binary stream as byte chunks instead of word chunks.)

So, now that word alignment is fixed, but my decompression is spewing garbage. Odd... Especially considering the fact that it was working earlier.
_________________
Moron! You don't herd chickens with a shotgun!

--CoolMan

#3257 - CoolMan - Fri Feb 21, 2003 6:36 am

Alright, it works now. It ended up being the byte ordering...

My program was taking the bytes in, and assembling them like so...

Code:

//Bytes are in the order that they come to me. (In the input stream.)
final_word = 0;
final_word = final_word | ((first_byte << (8*3)) & 0xFF000000);
final_word = final_word | ((second_byte << (8*2)) & 0x00FF0000);
final_word = final_word | ((third_byte << (8*1)) & 0x0000FF00);
final_word = final_word | ((fourth_byte << (8*0)) & 0x000000FF);


(Basically, not exactly.)

Anyway, switching it around fixed it.

Any gurus have any ideas why?
_________________
Moron! You don't herd chickens with a shotgun!

--CoolMan

#3263 - FluBBa - Fri Feb 21, 2003 10:33 am

Little endian.
DCB 0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77
=
DCD 0x33221100,0x77665544

read up on little endian vs big endian.
_________________
I probably suck, my not is a programmer.

#3278 - CoolMan - Fri Feb 21, 2003 5:28 pm

lol, my first endianness bug...
_________________
Moron! You don't herd chickens with a shotgun!

--CoolMan