#12906 - maximAL - Sun Nov 30, 2003 2:51 pm
one thing that puzzles me is the (non existent?) memory management of the GBA. i mean, what actually happens when i "new" an object? where is the memory allocated? and more important: what happens, when i delete the object? is the memory really available again? and what about memory fragmentation?
i read several times, that you'd have to right your one memory manager for that so i'm wondering what happens when you don't ?!
#12908 - NoMis - Sun Nov 30, 2003 3:10 pm
i just began with that stuff so i can't be sure that i'm right or not. If i use g++ the new and delete functions seems to work properly. if you use gcc i think you need to include the appropriate C libraries and initialize the heap, so the new and delete functions know where and how much memory they can allocate. if you use C instead of C++ use malloc. i know an article on the internet wich explains how to initialize the functions but the link is broken. But i downloaded the html file once so if you send me your email address i can send you this thing.
NoMis
#12909 - NoMis - Sun Nov 30, 2003 3:18 pm
and here is an intressting articel at gamasutra about memory and ressource managemend on the GBA.
http://www.gamasutra.com/features/20010509/baptista_01.htm
NoMis
#12912 - ampz - Sun Nov 30, 2003 4:04 pm
I recommend you use alloca whenever possible.
#12913 - maximAL - Sun Nov 30, 2003 4:08 pm
i think i allready read this article and as far as i can see it says that you have to implement your own memory manager...
#12919 - sajiimori - Sun Nov 30, 2003 7:01 pm
| Quote: |
memory management of the GBA
|
Memory management is not the responsibility of the GBA. It's the responsibility of the C library and the application.
| Quote: |
what actually happens when i "new" an object? where is the memory allocated?
|
Normally, IWRAM is allocated using malloc.
| Quote: |
what happens, when i delete the object? is the memory really available again?
|
Yup.
| Quote: |
and what about memory fragmentation?
|
Malloc will "try" to find the best fit for new allocations, but fragmentation can happen anyway. Sometimes you can reduce it greatly by allocating things in the right order. Figure out what will generally be freed first, and allocate those things last. If you use that scheme without fail, the heap will be a bit more like a stack (last in, first out).
Write your own allocator if you're dissatisfied with the results you get from using the standard one.
#12923 - tom - Sun Nov 30, 2003 10:31 pm
| sajiimori wrote: |
| If you use that scheme without fail, the heap will be a bit more like a stack (last in, first out). |
if you do this you can aswell write your own stack based memory manager. you can also implement kind of "save-points" that allow you to restore the heap to a certain state (that is, all memory allocated after that point is freed).
#12926 - ampz - Mon Dec 01, 2003 1:13 pm
... Or you can use the already available stack allocator alloca..
#12931 - Burton Radons - Mon Dec 01, 2003 3:32 pm
malloc allocates from EWRAM, not IWRAM, at least with DevKit Advance. The same recommendations as always apply; try to avoid many little allocations, make your program memory usage as stable and predictable as possible to avoid in-the-field crashing, and check the return value.
The stack is in IWRAM and grows from the end of it to the beginning. So, if you use too much of it and have too much permanent IWRAM usage, you'll overwrite the permanent IWRAM or even start writing into EWRAM. Here's a macro to sanity check it:
| Code: |
#define CheckStackUsage() \
do { \
extern char __bss_end; /* End of the IWRAM load area. */ \
char end [0]; /* Stack end pointer. */ \
\
Assert (end >= &__bss_end, "Stack overrun."); \
} while (0)
|
I would recommend putting that in all large-stack-usage functions for debug builds, just to be safe.
#12936 - sajiimori - Mon Dec 01, 2003 7:57 pm
| Quote: |
malloc allocates from EWRAM, not IWRAM
|
D'oh...I've been staying up too late.
#13008 - ampz - Wed Dec 03, 2003 2:16 pm
"malloc allocates from EWRAM, not IWRAM"
Uh, malloc allocates memory where you tell it to allocate memory. It's all in the linker script. The same goes for the stack.
#13025 - Touchstone - Wed Dec 03, 2003 10:25 pm
| ampz wrote: |
"malloc allocates from EWRAM, not IWRAM"
Uh, malloc allocates memory where you tell it to allocate memory. It's all in the linker script. The same goes for the stack. |
I'm sure the original post meant that malloc allocates from EWRAM by default in DevKit Advance.
_________________
You can't beat our meat
#13029 - sajiimori - Wed Dec 03, 2003 11:17 pm
Yeah, that's why he said "at least with DevKit Advance", because DevKit Advance provides a customized linkscript.
#20824 - hzx - Tue May 18, 2004 1:34 pm
Is it possible to use a C compiler (namely, DevKitAdvance) with the builtin memory management functions turned off? What I need is the pure compilation of my code (including my own memory management functions) into a raw binary, with the starting point at 0x0800000, just like Goldroad produces it.
_________________
.hzx
#20835 - Lupin - Tue May 18, 2004 3:49 pm
You can "turn them off" by not using them - it works :)
_________________
Team Pokeme
My blog and PM ASM tutorials
#20837 - hzx - Tue May 18, 2004 5:00 pm
No, no, you got me wrong. I mean I would like to have a compiler without any pre-run memory management, like code relocation, RAM fillup, etc. (crt0.S stuff). I would like to have a pure binary instead of an elf executable (just like the Goldroad assembler produces), as the result.
_________________
.hzx
#20845 - Miked0801 - Tue May 18, 2004 6:31 pm
Huh?
#20849 - sajiimori - Tue May 18, 2004 6:35 pm
Most of the tutorials tell you how to change an .elf to a raw binary:
objcopy -O binary game.elf game.gba
If you don't want crt0.o, then don't link it in. The gcc and g++ front ends link it in automatically, so use ld directly. Note that you'll have to replace some of its functionality. You might want to start with the complete crt0.S and remove the parts you don't want.