#146368 - brave_orakio - Mon Dec 03, 2007 6:06 am
Is there any way to do it? or just use
| Code: |
#define CODE_EWRAM __attribute__((section(".ewram")))
#define CODE_IN_IWRAM __attribute__((section(".iwram"),long_call))
|
Another question would be, does the compiler put a function in RAM as needed when you add the above attribute or does it put it in RAM immediately whether or not the situation calls for it?
_________________
help me
#146369 - tepples - Mon Dec 03, 2007 6:13 am
If the source code specifies that a function shall go in a section, it goes in that section. The linker has no idea whether or not "the situation calls for it".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#146370 - brave_orakio - Mon Dec 03, 2007 6:23 am
I see. Which means that if you declare a function to be in RAM, it stays there?
Is there a way to make this dynamic? Say, I need a specific AI routine but I dont want it to be in RAM all the time. What I want is to put a routine in RAM only when I need it. Maybe remove it afterwards or just let it get overwritten by another routine.
_________________
help me
#146371 - tepples - Mon Dec 03, 2007 6:26 am
| brave_orakio wrote: |
I see. Which means that if you declare a function to be in RAM, it stays there?
Is there a way to make this dynamic? Say, I need a specific AI routine but I dont want it to be in RAM all the time. |
Then you get into "IWRAM overlays". I haven't gone there yet, and I don't think a lot of people understand that part of the devkitARM GBA link script.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#146373 - brave_orakio - Mon Dec 03, 2007 6:38 am
Well, not necessarily IWRAM. For IWRAM, I'll probably just place the most common and costly functions like collision and priority sorting.
I was thinking more on EWRAM. But would it be similar to this IWRAM overlaying?
_________________
help me
#146374 - tepples - Mon Dec 03, 2007 6:43 am
EWRAM has a set of overlays that I'm assuming work the same way. But on the GBA, what advantage would code in EWRAM have over code in ROM? They run at comparable speeds (2/2 wait in EWRAM, 3/1 in ROM), unless you're on a SuperCard or a really old Visoly card that only supports 4/2 ROM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#146376 - brave_orakio - Mon Dec 03, 2007 7:08 am
Whoops! That I didn't know.
So there is hardly any performance gained from code in EWRAM and code in ROM?
What would the main function of EWRAM be in that case? Only for variables then?
_________________
help me
#146387 - tepples - Mon Dec 03, 2007 1:52 pm
| brave_orakio wrote: |
| What would the main function of EWRAM be in that case? Only for variables then? |
That, and code that needs to run in RAM because of bus conflict issues (namely code that accesses certain kinds of GBA save chips), and code that needs to run on a machine without a Game Pak inserted (single-cart multiplayer), and code that needs to run from a cart with a "funny" mapper scheme (GBA Movie Player).
But I'm just waiting for wintermute, who knows the insides of devkitARM better than I do, to step in and clarify the whole overlay bit.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#146389 - kusma - Mon Dec 03, 2007 2:32 pm
| tepples wrote: |
| But I'm just waiting for wintermute, who knows the insides of devkitARM better than I do, to step in and clarify the whole overlay bit. |
I'm not sure what you need clarification on, but I've used IWRAM overlays with great success myself. It's a bit undocumented, perhaps I should submit an example to the devkitPro distribution?
#146403 - tepples - Mon Dec 03, 2007 8:26 pm
| kusma wrote: |
| I've used IWRAM overlays with great success myself. It's a bit undocumented, perhaps I should submit an example to the devkitPro distribution? |
That would be great.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#146411 - silent_code - Mon Dec 03, 2007 10:52 pm
second that!
#146413 - kusma - Mon Dec 03, 2007 11:03 pm
Here's an example for your own needs. I'll look into what I need to do to submit it to the dkp-project.
| Code: |
#include <gba_console.h>
#include <gba_video.h>
#include <gba_interrupt.h>
#include <gba_systemcalls.h>
#include <stdio.h>
void overlay1_test() __attribute__((section(".iwram1"), long_call));
void overlay2_test() __attribute__((section(".iwram2"), long_call));
void overlay1_test()
{
printf("inside %s\n", __func__);
}
void overlay2_test()
{
printf("inside %s\n", __func__);
}
extern unsigned char __iwram_overlay_start[];
extern unsigned char __load_start_iwram0[];
extern unsigned char __load_stop_iwram0[];
extern unsigned char __load_start_iwram1[];
extern unsigned char __load_stop_iwram1[];
extern unsigned char __load_start_iwram2[];
extern unsigned char __load_stop_iwram2[];
int main()
{
irqInit();
irqEnable(IRQ_VBLANK);
consoleInit(0, 4, 0, NULL, 0, 15);
BG_COLORS[0]=RGB8(58,110,165);
BG_COLORS[241]=RGB5(31,31,31);
SetMode(MODE_0 | BG0_ON);
/* verify that the overlays are indeed overlapping */
printf("overlay1_test: %p\noverlay2_test: %p\n", overlay1_test, overlay2_test);
/* set overlay 1 and run code from it */
memcpy(__iwram_overlay_start, __load_start_iwram1, (int)__load_stop_iwram1 - (int)__load_start_iwram1);
overlay1_test();
/* set overlay 2 and run code from it */
memcpy(__iwram_overlay_start, __load_start_iwram2, (int)__load_stop_iwram2 - (int)__load_start_iwram2);
overlay2_test();
/* back to normal */
memcpy(__iwram_overlay_start, __load_start_iwram0, (int)__load_stop_iwram0 - (int)__load_start_iwram0);
while(1);
}
|
#146434 - brave_orakio - Tue Dec 04, 2007 5:46 am
Ah I see. So it's ok to execute code from ROM then. Thanks for your response tepples and also thank you Kusma for the example of the IWRAM overlay. I'l try it out and experiment with it.
_________________
help me
#146495 - Miked0801 - Tue Dec 04, 2007 10:42 pm
BTW, don't run code from EWRAM unless you really have no other alternative. 2/2 wait states will run just about twice as slow as code in 3/1 land due to the linear way that most code is run. EWRAM also has a 16-bit bus like ROM so ARM code runs at half speed. Whenever we want a truely fast routine, we loaded it into IWRAM and compiled it as ARM (or hand asm coded the ARM.)
For a quick a dirty way to do this, just create a static IWRAM buffer (array) and memcopy the requested code into the buffer. In essence, this is what crt0 is doing on bootup for you.
#146571 - brave_orakio - Thu Dec 06, 2007 3:39 am
Ah yes thank you. By the way, could you guys point me to the document for the code execution wait states? I saw the copy wait states in cowbite specs but not the code execution wait states.
_________________
help me
#146586 - keldon - Thu Dec 06, 2007 11:30 am
#146587 - kusma - Thu Dec 06, 2007 12:22 pm
I got the impression that these questions were about GBA, and if so - here's the correct link: http://nocash.emubase.de/gbatek.htm#gbasystemcontrol
#146848 - brave_orakio - Mon Dec 10, 2007 2:46 am
Thanks guys! I only saw this version of GBATEK today! With both GBA and NDS too!
_________________
help me
#146862 - kusma - Mon Dec 10, 2007 11:18 am
By the way, this is the official GBAtek-site. Any other GBAtek mirror tend to be out-of-date, so update your links ;)