#14065 - gbawiz - Sun Dec 28, 2003 9:41 pm
Hello,
I was wondering about what happens when my code is compiled. Is it compiled and stored in the area where the GBA rom information resides or is it loaded into the RAM.
I ask this because I seem to have run out of memory in my project and would like to know more about the way my compiler allocates memory.
Thanks
GbaWIZ
#14068 - Lord Graga - Sun Dec 28, 2003 11:22 pm
if you ran out of RAM, then check if there's some arrays/etc that you could make constant.
Are you compiling in multiboot?
#14071 - sajiimori - Mon Dec 29, 2003 12:23 am
| Quote: |
I seem to have run out of memory in my project and would like to know more about the way my compiler allocates memory.
|
This is roughly analogous to:
| Quote: |
My shirt is dirty and I'd like to know if the colors will bleed if I put it in my washing machine.
|
Just about every aspect of the question is missing crucial information. =)
Obviously, it depends on what your code is, what compiler you're using, and what flags you use with the compiler.
#14084 - gbawiz - Mon Dec 29, 2003 12:07 pm
hello all,
well my code consists of the main program with the graphics data stored as hexadecimal header info i.e mygfx[n]={12,12,64,76,etc.....};
I have noted that making these headers const tends to cause problems in some cases and solves problems in others.
I use devkit advance with the standard compiler batch file:
set path=C:\devkitadv\bin;%path%
gcc -o main.elf main.c -lm
objcopy -O binary main.elf main.gba
pause
are there any specific flags which need set which would make my programs work properly?
thanks for response,
gbaWIZ
#14086 - Lord Graga - Mon Dec 29, 2003 2:39 pm
I think that you should make all the GFX headers constant. If you get errors, post them here (in this thread), so that we can help you out.
#14097 - sajiimori - Mon Dec 29, 2003 8:47 pm
If you don't declare data const, the compiler will assume you might modify it, so it will be stored in RAM. What problems did you have by declaring your graphics const?
Anyway, headers should never contain data object definitions. You can get away with it for a simple program with only one module, but get out of the habit as soon as possible if you intend to move on to larger projects.
#14123 - gbawiz - Tue Dec 30, 2003 8:40 pm
thanks for your advice,
it turns out that when i was making my graphics headers 'const' i kept forgetting one (which i was leaving as non-constant). the result was that the space allocated to this forgotten header was being overwritten by other parts of the program. So now all my GFX headers are const and they seem to work properly, thanks.
Does that mean when I make them const, they are stored in rom only. as opposed to normal where there is both a copy in the rom and ram?
why should headers never contain data object definitions. what method is better to include my graphics data?
thanks again =)
GbaWIZ
#14124 - tepples - Tue Dec 30, 2003 9:36 pm
| gbawiz wrote: |
| Does that mean when I make them const, they are stored in rom only. as opposed to normal where there is both a copy in the rom and ram? |
Correct. If you don't make them const, they are stored in .data, which the startup code copies to IWRAM. If you make them const, they are stored in .rodata, which the startup code doesn't touch.
| Quote: |
| why should headers never contain data object definitions. what method is better to include my graphics data? |
Convert graphics data to .s or .c files and compile them separately instead of #include'ing them. Or use appended data.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#14127 - poslundc - Wed Dec 31, 2003 1:16 am
| tepples wrote: |
| Quote: | | why should headers never contain data object definitions. what method is better to include my graphics data? |
Convert graphics data to .s or .c files and compile them separately instead of #include'ing them. Or use appended data. |
To answer the question as to why, picture the following file as a header file:
mySprite.h:
| Code: |
| const unsigned int mySpriteData[] = {10, 20, 40, 30}; |
Now you #include this file in one of your C programs that accesses it, and it works.
Problem is, if it even accidentally gets #included in another file (and believe me, sooner or later it WILL happen) you will be defining the same variable twice, which is a big no-no, and will generate a bus error at the linking stage (something which has caused me a headache more than once).
If on the other hand you put the same data into a C file called mySprite.c, and then wrote mySprite.h as follows:
| Code: |
| extern const unsigned int mySpriteData[]; |
It is no longer attempting to define the variable, it's just declaring its existence. You can #include this file in as many C files as you like, and it won't attempt to connect any data to the actual variable until the linking stage. (You should also use #ifndefs to shield from multiple inclusion.)
Even if you're careful with your #include statements, the second way is the proper way to do things, because C files are meant to contain data and header files are meant to contain meta-data (data about data).
I personally think it's a big problem that so many tutuorials teach people to put their data in header files. Oh well.
Dan.
#14159 - Paul Shirley - Wed Dec 31, 2003 6:29 am
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:26 pm; edited 1 time in total
#14168 - tepples - Wed Dec 31, 2003 2:35 pm
| Paul Shirley wrote: |
| The only way you could get a bus error is if the linker itself is broken, you've been corrected on this point before. |
Perhaps a widely-distributed linker is in fact broken, and a duplicate symbol error shows up as a bus error.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#14170 - poslundc - Wed Dec 31, 2003 3:59 pm
| Paul Shirley wrote: |
| The only way you could get a bus error is if the linker itself is broken, you've been corrected on this point before. |
Sorry, but ld seems far from broken on my computer, you'll have to forgive me for not taking every possible explanation I hear on gbadev as gospel. "Your linker is broken" is where the responses began, not where they ended.
Dan.