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 > memory management...

#5759 - lordmetroid - Thu May 08, 2003 4:57 am

I want to keep track of how much memory I got left in IWRAM...
It was quite easy before, before I added structures. As I could count the variables sizes... but now, one never know how big a structure is.

Is there a way to find out how much one has allready allocated?

I also wonder... is there a way of packing the structures, packing them so they don't take more memory then the variables inside... I saw one could do it for regular computer code but don't remember exactly but it was something like #pragma pack or something.
If I pack will accessing the variables inside the structure get slower?
_________________
*Spam*
Open Solutions for an open mind, www.areta.org

Areta is an organization of coders codeing mostly open source project, but there is alot of sections like GBA dev, Language learning communities, RPG communities, etc...

#5761 - niltsair - Thu May 08, 2003 5:46 am

structures takes more place than the size of its variables? Is it only due to each variable trying to be aligned?

#5765 - tepples - Thu May 08, 2003 6:59 am

lordmetroid wrote:
Is there a way to find out how much one has allready allocated?

You could always try picking through the output of nm -n foo.elf. Devkit Advance R5 will include a tool to do this for you.

Quote:
I also wonder... is there a way of packing the structures, packing them so they don't take more memory then the variables inside

The easiest method is to keep variables of similar size together (all u8:s and s8:s together, all u16:s and s16:s together). Or just lay out your structs on graph paper, making sure that all u16:s and s16:s fall on an even byte boundary and that all u32:s and s32:s fall on a 4-byte boundary.

Quote:
I saw one could do it for regular computer code

This requires accesses to unaligned memory addresses and thus won't work in ARM architecture. It works in x86 because x86 supports unaligned accesses.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#5766 - Quirky - Thu May 08, 2003 7:39 am

I keep track of IWRAM use through a combination of -Wl,-Map,game.map (as a gcc option, passed to ld) and watching IWRAM in VBA.

game.map (or whatever you call it) is a memory map created by the linker and it'll let you know exactly how much memory you use for global variables. VBA's memory viewer can be used to watch the stack, which starts at the end of IWRAM and works backwards.

#5769 - Touchstone - Thu May 08, 2003 8:46 am

The linker should output a couple of variables I think, which you can use to check how much variable-memory is used. They are called something like __BSS_START__ (start of the BSS, a.k.a variable section) and __BSS_END__ (well, end of BSS).

So to know how much variable memory you are using you can do:
Code:
extern char __BSS_START__;
extern char __BSS_END__;
int UsedBSS = (&__BSS_END__) - (&__BSS_START__);


I _think_ this is how it's done but it was three years since I did it the last time :) and at the time I did it for Playstation but I used gcc. Anyways, check out your memory-map to see what the variables that lies at the beginning and end of your variable section are called.
_________________
You can't beat our meat

#5770 - Sweex - Thu May 08, 2003 9:40 am

I wrote my own new and delete functions that keep track of allocated memory. If your not doing c++ you can probably write your own malloc and free functions.

Simply subtracting the allocated memory from 256k gives you the free memory (However, this is quite inaccurate as there's almost certainly not the full 256k available for your program.)

#5777 - niltsair - Thu May 08, 2003 2:29 pm

I was wondering, how reliable is the new/delete fucntion on the DevKitAdvance? Why did you do your own new/delete implementation, for fun or because it was needed? I am about to start a project with some peoples, and we were wondering about dynamic memory allocation.

#5782 - Touchstone - Thu May 08, 2003 4:07 pm

niltsair wrote:
I was wondering, how reliable is the new/delete fucntion on the DevKitAdvance? Why did you do your own new/delete implementation, for fun or because it was needed? I am about to start a project with some peoples, and we were wondering about dynamic memory allocation.


If you are going commercial, or starting a bigger project, I would really opt against using any existing libraries such as DevKit Advance. I haven't tried any of them so I can't say that they are bad, I'm just suggesting that if you are gonna write a bigger project you might want to know everything that is going on, where every cycle is spent, and most importantly have the possibility to rewrite code.

But then again it may just be the fact that I'm getting rather bored by Tepples constant plugging for DevKit Advance. Feels like forum.gbadev.org has turned into a recruitment/support-center for devkit advance. In fact, I'm so sure I'll get flamed for writing this I'm almost prepared to bet my E3 pass. :)

So, in the spirit of true gameboy advance programming. Bash the hardware directly! If you want to use libraries you can write PC games using DirectX.

Feel free to hate me now! :)

P.S. I take no responsibility for what I have written in this post.
_________________
You can't beat our meat

#5784 - niltsair - Thu May 08, 2003 4:39 pm

Your E3 pass eh......

(Hey guys, let's keep quiet and we'll have a draw for it amongs ourselves...) :-)

As for our little project, it's nothing commercial, it's a homebrew game :
www.gosg.org

And about DevKitAdvance, isn't only a gcc/as compiler tweaked to work for the Gba? I mean what are we supposed to use beside a C/C++ compiler if we don't want to hand code everything in Assmebly, doesn't seems really efficient. You code your main logic in C/C++ to get clarity of code, and the processor intensive code in Assembly.

When using DevKitAdvance, you still have access to the hardware and you're not using a lot of librairies.

#5789 - Touchstone - Thu May 08, 2003 5:58 pm

Well, that should teach me not to speak if I'm not exactly sure what I'm talking about. :) I thought devkit advance was a hardware abstraction library. That would really take the fun out of programming for the gba. :)

If it's just gcc then I won't stop anyone from using it. (Like I would otherwise :)

I'm sorry Tepples! Although I'm still not comfortable with all this devkit advance plugging, but maybe I'm just jealous. :)
_________________
You can't beat our meat

#5791 - niltsair - Thu May 08, 2003 6:18 pm

Ham is a bunch of librairies made to make the development easier. Never tried it.

DevKitAdv is really just a set of tools to compile in As, C, C++, already all configured.

Now, about that E3 pass.... ;-)

#5795 - tepples - Thu May 08, 2003 6:36 pm

Touchstone wrote:
Well, that should teach me not to speak if I'm not exactly sure what I'm talking about. :) I thought devkit advance was a hardware abstraction library.

In fact, Jason Wilkins has strongly argued against including anything like HAMlib in the Devkit Advance distribution. Devkit Advance R5 will include a text output library (for printf(), etc) similar to my AGBTTY, but the ANSI C standard mandates that anyway.

Quote:
Although I'm still not comfortable with all this devkit advance plugging, but maybe I'm just jealous. :)

What you see as "plugging" may just be explaining quirks of Devkit Advance R4, giving workarounds, and predicting how they will change in R5 based on my conversations with the maintainer and what I have observed of the betas.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#5799 - Touchstone - Thu May 08, 2003 7:57 pm

Ok.

Sometimes I get the feeling you Tepples are advertising Devkit Advance. Back when I thought it was a library (about an hour ago :) I got bothered cause I thought you where recommending people to use a hardware abstraction library. Anyways, I'm ok with it now when I know it's not. :)

And niltsair, I'm sorry but I'm gonna have to hang on to the pass, even though no flaming occured. I'm sorry about that. :)
_________________
You can't beat our meat

#5804 - Jason Wilkins - Thu May 08, 2003 9:41 pm

DevKit Advance is just a C/C++ tool chain for GBA based on GCC. If there is no disaster (like someone crashing a car into my house like they did Tuesday (NO JOKE!)), the next version should be out tommorow (Friday, May 9th, 2003).

Although I know you were not suggesting that someone do so, I will say rolling your own tool chain can be a full time project in and of itself. If you want to know everything that is going on, then you would still want to grab DevKit Advance. The next release will include simple projects for recompiling and installing the low level internals, or you can just rip all that out and use your own stuff easily. But, let me worry about building and fixing the compiler itself.

The only high level library which devkit advance will contain is a common framework library for use by example and test code.

I am glad that tepples is enthusiastic about DKA5, but I feel bad about promoting features which only exist on my laptop right now ^_^

The tool for reporting on memory usage which he mentioned is probably several weeks away. I stopped development of it until the DevKit stablizes some more.

Back to the original poster. You can tell how big a structure is by using 'sizeof(my_struct_t)' or 'sizeof(my_struct_var_name)'
_________________
http://devkitadv.sourceforge.net

#5806 - niltsair - Thu May 08, 2003 9:46 pm

You'll probably anwser yes to this one,

but we're about to start the programming part of a project, would you recommand using the new release? What would be the advantages compared to the previous version.

And can new/delete be used safely?

#5807 - Jason Wilkins - Thu May 08, 2003 9:47 pm

DevKit Advance is just a C/C++ tool chain for GBA based on GCC. If there is no disaster (like someone crashing a car into my house like they did Tuesday (NO JOKE!)), the next version should be out tommorow (Friday, May 9th, 2003).

Although I know you were not suggesting that someone do so, I will say rolling your own tool chain can be a full time project in and of itself. If you want to know everything that is going on, then you would still want to grab DevKit Advance. The next release will include simple projects for recompiling and installing the low level internals, or you can just rip all that out and use your own stuff easily. But, let me worry about building and fixing the compiler itself.

The only high level library which devkit advance will contain is a common framework library for use by example and test code.

I am glad that tepples is enthusiastic about DKA5, but I feel bad about promoting features which only exist on my laptop right now ^_^

The tool for reporting on memory usage which he mentioned is probably several weeks away. I stopped development of it until the DevKit stablizes some more.

Back to the original poster. You can tell how big a structure is by using 'sizeof(my_struct_t)' or 'sizeof(my_struct_var_name)'
_________________
http://devkitadv.sourceforge.net

#5808 - Jason Wilkins - Thu May 08, 2003 10:03 pm

This week I have been doing a lot of testing and as far as the basic lnkscript and crt0.S go, I think that DevKit Advance Beta 3 will be rock solid.

malloc appears to work with all combination of options, but it has not been tested extensively. If it works, then new/delete should work as well.

C++ should work as far as I know. Using main as your entry point, and libc, static constructors and destructors and atexit functions should all be called.

I do no think you would have any serious problems with Release 5, even its beta state.
_________________
http://devkitadv.sourceforge.net