#13649 - sgeos - Fri Dec 19, 2003 6:35 pm
Can I use either of these to have DKA compile a multiboot game?
| Code: |
int __gba_multiboot = 0;
void __gba_multiboot(void)
{
} |
-Brendan
#13650 - tepples - Fri Dec 19, 2003 8:20 pm
DKA will compile a multiboot program if you have a global variable called __gba_multiboot. Your program will look like this:
| Code: |
int __gba_multiboot;
int main(void)
{
/* init */
while(1)
{
/* loop */
}
} |
I've never heard of anybody having a function called __gba_multiboot.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#13673 - sgeos - Sat Dec 20, 2003 7:37 am
I was wondering if __gba_multiboot had to be in the namespace somewhere, or if it had to be a global variable. Not that it really matters, but is an int's worth of RAM set aside for __gba_multiboot?
It seems to me that a function would have a higher chance of being optimized out-- not using up any space. On the otherhand, it may take up more than an int's worth of ROM, which is really RAM in a multiboot program....
(On second thought, this probably should have been posted to coding...)
-Brendan
#13674 - sajiimori - Sat Dec 20, 2003 7:48 am
You're spending waaay too much time thinking about %0.001 of available RAM. :-)
#13675 - sgeos - Sat Dec 20, 2003 9:16 am
| sajiimori wrote: |
| You're spending waaay too much time thinking about %0.001 of available RAM. :-) |
I realize that. =) Mutliboot programs only have (288 - program size - stack space) KB available though. Admittedly, pushing so close to limits that one int will make or break the program is probably a bad thing. To a certain extent I'm not asking how to get things to work, but rather how things work in general.
Does it matter where this global variable is listed in the source code? Can it be the very last line? (How things work question.)
It does not have to be an int, just a global variable? Could it be a struct, a void pointer, or an array? If so it seems to me that, with the help a macro, this space does not need to be wasted. =)
For example, it could be used for the state of the (an?) RNG.
| Code: |
#ifdef MULTIBOOT
#define rng_state __gba_multiboot
unsigned long __gba_multiboot = 0xA054FE33;
#else
unsigned long rng_state = 0xA054FE33;
#endif /* MULTIBOOT */ |
-Brendan
#13679 - poslundc - Sat Dec 20, 2003 3:50 pm
If you are so concerned about 4 bytes of RAM, then just go into the lnkscript and change it to always link for multiboot, regardless of the variable's presence.
Or, you could always actually use the __gba_multiboot variable to store a value in your program. To my knowledge, lnkscript only checks to see if it's defined, and doesn't care what the value is or what it's used for.
As was already mentioned, though, if 4 bytes of IWRAM (out of the 32,768 available) are that critical to you, then there is probably something wrong with your program.
Or how about this: if you can make your program work within 32,772 bytes of memory, then I will be happy to review your code for you and optimize out the four bytes of memory you need to get within the GBA's limits. :P
Dan.
#13687 - sgeos - Sat Dec 20, 2003 6:24 pm
| poslundc wrote: |
| If you are so concerned about 4 bytes of RAM, then just go into the lnkscript and change it to always link for multiboot, regardless of the variable's presence. |
Clearly I still don't know enough about link scripts. I should fix that. Feel free to just tell me to read up on linkscripts, but could I get it to link for multiboot if something like __GBA_MULTIBOOT is #defined?
| poslundc wrote: |
| Or, you could always actually use the __gba_multiboot variable to store a value in your program. To my knowledge, lnkscript only checks to see if it's defined, and doesn't care what the value is or what it's used for. |
See above with the rng_state example. Thats what I'm doing. I may go this route.
| poslundc wrote: |
| Or how about this: if you can make your program work within 32,772 bytes of memory, then I will be happy to review your code for you and optimize out the four bytes of memory you need to get within the GBA's limits. :P |
Then we might just need you to optimize out a little bit more so we can add a new feature. =P Of course, all of this would be silly. =)
-Brendan
#13700 - poslundc - Sun Dec 21, 2003 12:03 am
| sgeos wrote: |
| Clearly I still don't know enough about link scripts. |
Neither do I, but just from glancing through the DKA lnkscript file, it isn't very difficult to read or understand. Just look for sections where it checks to see if __gba_multiboot is defined and alter them to remove the conditional aspects.
Dan.
#13715 - AcidGame - Sun Dec 21, 2003 7:52 am
I think the HAM uses a simpler method..
:P - But with DKA? No clue. :X
#13725 - poslundc - Sun Dec 21, 2003 4:49 pm
I've never looked at HAM, but I reckon MULTIBOOT is just a macro defined for int __gba_multiboot.
Correct me if I'm wrong.
Dan.
#13782 - tom - Mon Dec 22, 2003 7:46 pm
| sgeos wrote: |
| Clearly I still don't know enough about link scripts. I should fix that. Feel free to just tell me to read up on linkscripts, but could I get it to link for multiboot if something like __GBA_MULTIBOOT is #defined? |
no, that __gba_multiboot thing needs to be a symbol (not necessarily a variable, it could aswell be a function. haven't checked that, though) that the linker gets to see.
just defining a macro, like
| Code: |
#define __gba_multiboot
|
won't work. but as already explained, __gba_multiboot just needs to exist (so the linkscript knows you want to create a multiboot program), but isn't used for anything else, so you can use it for anything you want.
#14330 - sgeos - Mon Jan 05, 2004 4:27 am
| tom wrote: |
| that __gba_multiboot thing needs to be a symbol (not necessarily a variable, it could aswell be a function. haven't checked that, though) that the linker gets to see. |
Does a function prototype (without a function to back it) create a symbol?
| Code: |
| void __gba_multiboot(void); |
-Brendan
#14331 - sajiimori - Mon Jan 05, 2004 4:40 am
No, the linker never sees that. It's only information for the compiler.
#14334 - dagamer34 - Mon Jan 05, 2004 4:13 pm
I doubt you will get close to the ~256kb mark in a mulitboot program. Its either over it or not.
Simplest thing to do in your code
| Code: |
#define MULITBOOT int __gba_multiboot = 0;
|
And just use it like this
| Code: |
// At the top of the file
#include "gba.h"
MULTIBOOT
int main (void)
{...}
|
AND I am 100% sure if you are worrying about this, then you have 100% optimized all your other code. You haven't? ....Get to work!
_________________
Little kids and Playstation 2's don't mix. :(
#14361 - sajiimori - Mon Jan 05, 2004 8:49 pm
| Quote: |
Simplest thing to do in your code
|
...would be to leave out your extrenuous line.
Anyway, as Brendan mentioned earlier, he is not so much interested in saving memory as understanding the way the compiler toolchain works.
#14414 - sgeos - Tue Jan 06, 2004 4:45 am
| sajiimori wrote: |
| Anyway, as Brendan mentioned earlier, he is not so much interested in saving memory as understanding the way the compiler toolchain works. |
I am also trying to ask these questions so that another individual doesn't have to. Thats what forums are all about.
-Brendan
#14418 - sajiimori - Tue Jan 06, 2004 6:58 am
Well I hope everybody doesn't start asking every question they think anyone might ever ask -- it could get mighty noisy!
It makes a bit more sense for people to ask about what they want to know.
#14471 - sgeos - Wed Jan 07, 2004 5:26 am
| sajiimori wrote: |
| It makes a bit more sense for people to ask about what they want to know. |
Of course, and I did want to know what I asked. I did not have to ask my qustion in public. The alternatives to asking in public are to ask in private, research or experiment. Research and experimentation take time, and the results are not helpful to anybody else unless and until they are reported.
Asking in private is much like asking in public, only fewer people can offer input and the aswer can not be used by anyone else.
-Brendan