#18140 - cpu1333mhz - Sun Mar 21, 2004 7:39 pm
Is there any way to check how much RAM you have left on the GBA? I have a few large arrays and would like to know how much more breathing room I have.
#18142 - DekuTree64 - Sun Mar 21, 2004 7:55 pm
To check how much IWRAM is used by code and stuff that you tell it to put there, have the linker generate a map file. Just use the -Map filename.map (or filename.txt, whatever you want) option when you call ld and it will tell you where everything is. Then you can tell how close you are to running out of stack space by taking the stack pointer minus the end of your IWRAM code and stuff. To check the stack pointer without using ASM, you could probably get away with just taking the address of the last local var you declared. Or use a handy debugging trick, put an infinite loop where you want to check it, open VBA's dissassembler, and look at r13 (which is the stack pointer).
Oh, and the stack grows downward from the end of IWRAM, so that's why the linker puts your permanent stuff at the start of it, so it's as far from the stack as possible. So then the area from the end of the IWRAM stuff to the current stack pointer is free space for the stack to grow down into.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#18144 - Lupin - Sun Mar 21, 2004 8:18 pm
where is the stack pointer actually been set up? In the crt0.s file, right? So, can't we just make the stack point to ewram? This would of course be slower but if you code most of your stuff in asm it won't really matter.
_________________
Team Pokeme
My blog and PM ASM tutorials
#18147 - poslundc - Sun Mar 21, 2004 9:08 pm
| Lupin wrote: |
| where is the stack pointer actually been set up? In the crt0.s file, right? So, can't we just make the stack point to ewram? This would of course be slower but if you code most of your stuff in asm it won't really matter. |
Using slower RAM for your variables defeats the purpose of coding in ASM.
Dan.
#18149 - Lupin - Sun Mar 21, 2004 9:21 pm
I don't really use the stack in asm code, because using the stack defeats the purpose of coding in ASM (because using stack is a slow down)
I hate these 1 line posts...
_________________
Team Pokeme
My blog and PM ASM tutorials
#18151 - DekuTree64 - Sun Mar 21, 2004 9:36 pm
You can initialize the stack to EWRAM in your Crt0 and then use C code like normal. It's just that most of the time the speed increase of having all your local vars in IWRAM is better than having more of it. Besides, you can do what I do and set up an EWRAM stack with a global var and use that whenever you need really big arrays. It's really very flexible. You can just push all your permanent things onto the stack at the start of the game, and then the rest is free for temporary use later on. Or you can have the linker put things at the start too, and as long as you use a downward growing EWRAM stack, it works just the same as the 'real' IWRAM stack.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#18158 - cpu1333mhz - Mon Mar 22, 2004 12:15 am
Im using C++ not ASM :/ (I know nothing about ASM... I should learn)
I tried the -map filename.txt in g++ and it didn't work.
Sorry if i'm being stupid, i've never changed any of the flags of the compiler and use a batch script from a tutorial (I think it was the Pern Project) to compile my code. I've just always coded and let the compiler/linker do its work :D
A quick side question: I found on other threads that you aren't supposed to put code in .h files but i've never seen it outlined exactly why. All of my functs and classes are in .h files and everything works right :P. Is this a slowdown/does it have some kind of penalty?
(LOL the main reason i'm using .h files relates to the fact that I have never edited the make batch file. For .c / .cpp files you need to add them to the batch file :D)
Again sorry if im being stupid
#18166 - DekuTree64 - Mon Mar 22, 2004 3:37 am
I think -map only works with ld, which is the GNU linker, so you'll have to compile your .c file to a .o file with g++ and then link it. Might as well copy my bit from the Crt0 thread in the beginner section...
gcc -o crt0.o crt0.S
g++ -o file.o file.cpp
ld -T lnkscript -o game.elf crt0.o file.o
objcopy -O binary game.elf game.bin
Put that in a batch file and everything should be ok. Get Crt0.S and lnkscript at http://www.devrs.com/gba/files/crtls.zip. Then you can compile additional files with gcc/g++ and put them in the list of files for the linker too, that way you won't have to do bad header stuff. The only reason you're not getting in trouble for that is because you're only using one C file, which means each header gets included only once. If you include all that stuff in multiple files, you'll get multiple definitions and stuff, which is bad. Basically, headers are for telling your C files that things will be declared somewhere, C files are for actually creating them.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#18167 - poslundc - Mon Mar 22, 2004 3:40 am
| DekuTree64 wrote: |
| gcc -o crt0.o crt0.S |
If this doesn't work, include the -c switch (which tells gcc to compile your files without linking them; specifying a .o output may also work, I haven't tried it).
Dan.
#18169 - Miked0801 - Mon Mar 22, 2004 6:00 am
The other half of your question: Why we don't put source in header files.
The short answer is if that file is included in 2 places, the code is included in 2 places which can and does confuse the linker.
The real answer is that when you place stuff in headers, you forget about it. Lets say that you put some function foo() in the header. Later you create the same function else where slightly different. If you're lucky, the compiler throws a warning/error. If not, you get functionality that you just can't seem to fix when you edit your local foo() function. Vars and tables declared to create memory are also a real bad idea as they tend to multiple allocate memory and makes it hard in general to track usage. Finally, it's against convention. I won't go looking in header files for C code. I get angry if I find it there and have to deal with it. This holds for most if not all experienced programmers. Headers are for declarations, prototypes, and if needed, externs - nothing else.
Other reasons welcome, but this is more than enough.
Mike
#18190 - poslundc - Mon Mar 22, 2004 3:07 pm
| Miked0801 wrote: |
| Other reasons welcome, but this is more than enough. |
Well, since you opened the floodgates... :P
It's more than just convention. The purpose of #include is so that multiple C modules can share common definitions, not common code. Definitions include things like structures, macros, constants, references to external variables and function prototypes.
The fact that C lets you get away with #including executable code or data is a big pitfall for new programmers. In fact, I've always thought it should generate a compiler warning, and I don't know why it doesn't.
C already has a mechanism for programs to share common code: the linker. The whole language is designed under the presumption that each function is defined only once, and then the linker connects them together. This makes it possible to make a program modular, which any computer science/engineering student will tell you is a good thing.
#including C files works a lot of the time to circumvent this step of modularity, because it is a quick and dirty way to make the code for a function visible to a module. But that's not what the #include directive was intended for, and programs that use it this way invite a world of hurt as they grow larger and the "quick and dirty" way no longer works.
Dan.