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.

DS development > Heap or stack ? Which size ?

#149845 - nipil - Fri Jan 25, 2008 11:10 pm

About dynamic memory allocation. I ran into a problem after a debugging session, as i forgot to change one line and the rom crashed in the emulator. It led to allocate 15K of local variables, while the stack is (afaik) 16k. I just thought i could use new/malloc instead of local variable. But i just asked myself where the memory would go... And i wondered if there would be enough room. I happen to remember that on a PC, there are a stack and a heap. stacks is for local variables and arguments, heap for dynamic alloc. Is there any heap on the DS, and which size does it have ? Thanks in advance.
PS: both "new" and "malloc" just works with 15k.I'd still be happy to get some explanation on how dynamic alloc this works on the DS ;)

#149851 - Dwedit - Sat Jan 26, 2008 12:06 am

The stack is placed in DTCM (address 0x0b003d00), while the heap is located in main memory, starting after the end of the binary.
DTCM is only 16k large. You can move the stack if you really need to, or just use the heap.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#149857 - simonjhall - Sat Jan 26, 2008 1:17 am

The heap is the rest of the 4MB that's not taken by your code and static data. This is where new and malloc come from.
If you want to find out how much heap you've got (heh) keep allocating memory until it fails!
_________________
Big thanks to everyone who donated for Quake2

#149877 - nipil - Sat Jan 26, 2008 10:28 am

Thanks for the info

#149976 - PypeBros - Mon Jan 28, 2008 10:51 am

simonjhall wrote:
The heap is the rest of the 4MB that's not taken by your code and static data. This is where new and malloc come from.
If you want to find out how much heap you've got (heh) keep allocating memory until it fails!


Alternatively, you may get the size of your binary (bss included) using
Code:

extern char __text_start; // your very first byte of code (@0x02000000)
extern char __bss_end;  // your very last byte of (uninitialized) data

unsigned avlram=0x04000000 - (unsigned)(&__bss_end - &__text_start);


Don't take the result for granted: all memory allocation algorithms have overheads. E.g. if it says you have exactly 2MB free, you might be able to allocate 2044 blocks of 1KB, but 2048 blocks will certainly fail.
_________________
SEDS: Sprite Edition on DS :: modplayer

#149978 - nipil - Mon Jan 28, 2008 11:14 am

PypeBros wrote:
Don't take the result for granted: all memory allocation algorithms have overheads.
Thanks a bunch for this trick. I'll take some 5% out of it to be sure it won't overflow.

#149983 - PypeBros - Mon Jan 28, 2008 12:06 pm

Now, if you want to know the current amount of memory available (e.g. even after mallocs have been performed already), you might want to try a call to sbrk(0). I don't know to what extend this one has been ported to the devkit, but that should be the logical place to get the info at runtime.


(from linux manpage)
Quote:

sbrk() increments the program's data space by increment bytes. sbrk()
isn't a system call, it is just a C library wrapper. Calling sbrk()
with an increment of 0 can be used to find the current location of the
program break.

_________________
SEDS: Sprite Edition on DS :: modplayer

#149984 - elwing - Mon Jan 28, 2008 12:21 pm

PypeBros wrote:
simonjhall wrote:
The heap is the rest of the 4MB that's not taken by your code and static data. This is where new and malloc come from.
If you want to find out how much heap you've got (heh) keep allocating memory until it fails!


Alternatively, you may get the size of your binary (bss included) using
Code:

extern char __text_start; // your very first byte of code (@0x02000000)
extern char __bss_end;  // your very last byte of (uninitialized) data

unsigned avlram=0x04000000 - (unsigned)(&__bss_end - &__text_start);


Don't take the result for granted: all memory allocation algorithms have overheads. E.g. if it says you have exactly 2MB free, you might be able to allocate 2044 blocks of 1KB, but 2048 blocks will certainly fail.


that said, using a divide and conquer recursive algorithm that shouldn't take long to find out the exact amound of memory you can use with simon's method