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 > DevKitARM -> Code and Data in RAM

#26353 - funkeejeffou - Mon Sep 13, 2004 5:51 pm

Hi,

I haven't found any docs on how putting code and data in specific RAM, and even after suscribing to the DevKitARM group, the info were still not clear.

1)Do I have to create specific .C files for each group of functiuns defined in the same RAM or ROM?
2)Is the main functiun always in ROM?
3)How can I malloc dynamically in specifics RAM(IWRAM or EWRAM)?
4)www.devrs.com (although the FAQ is for DevkitAdv...) talks about #pragma long_calls, do I need this?
5)Do I only need putting the "-mlong-calls" in the CFLAGS for it to work, is there an LDFLAG to set too?
6)Is libgba absolutely necessary("gba_base.h")?
7)What is the correct syntax for declaring variables and arrays(declared globally) in RAM, I always get error using the attribute stuff?

I know this is a lot of questions :)
Thanks in advance !

Cheers, Jeff.

#26362 - tepples - Mon Sep 13, 2004 6:53 pm

  1. Assuming you've upgraded to devkitARM R8, the easiest way to get a function into IWRAM is by putting it in a separate file and calling the object file foo.iwram.o. Using a separate object file also gives you the chance to use ARM instructions. You can put all your ROM and EWRAM code into the same file; for that, you'd probably need to use the attribute.
  2. main() is in ROM unless you've declared it otherwise.
  3. malloc() goes to EWRAM. If you want to allocate IWRAM dynamically, you probably want to allocate from the stack.
  4. Pragmas are evil. When a function in ROM needs to call a function in IWRAM or EWRAM, just use the long_call attribute on the function's prototype:
Code:
__attribute__((long_call)) int gsm_decode(gsm, gsm_byte *, gsm_signal *);
  • I don't remember needing anything in the linker.
  • My GSM Player uses devkitARM R8 without libgba.
  • Global arrays will end up in IWRAM unless you either declare them const (putting them into ROM or EWRAM depending on the multiboot specs) or specify in an attribute that they end up in EWRAM.
    _________________
    -- Where is he?
    -- Who?
    -- You know, the human.
    -- I think he moved to Tilwick.

    • #26366 - funkeejeffou - Mon Sep 13, 2004 8:01 pm

    1) Yes I am using the R8 version. Is calling my file "file.iwram.c" enough?
    For the ARM instructiuns, you mean I can compile only this file with "-marm" so that I take advantage of the memory BUS related to IWRAM?
    3) What does allocate from the stack means?
    4)This is a sample from the group discussion :
    Code:
    void __attribute__((section(".iwram"), long_call)) Fn(parameters)

    if you want to call code in ROM or EWRAM from IWRAM you need to
    use-mlong-calls when compiling.

    The attribute stuff is placed before the return type of the functiun, and it also specifies where the functiun is placed in memory. It is clearly different from what you have said. Also, I tried it out(the one from the discussion group), but it doesn't work unless I place all functiuns in the same RAM or ROM... Weird...
    7)So if I have understood well :
    a) For ROM, declare global const variables
    b)For EWRAM, declare a global pointer and malloc it so it goes in EWRAM
    c)For IWRAM, declare a global array
    What about a global pointer allocated dynamically in IWRAM?
    And a global array in EWRAM(without using malloc)?

    From the discussion group :
    Code:
    #define IWRAM_DATA __attribute__(section(".iwram"))
    #define EWRAM_DATA __attribute__(section(".ewram"))
    #define EWRAM_BSS __attribute__(section(".sbss"))


    I couldn't manage to make this stuff compiled though...


    Thanks in advance, Jeff.

    #26369 - tepples - Mon Sep 13, 2004 8:54 pm

    funkeejeffou wrote:
    1) Yes I am using the R8 version. Is calling my file "file.iwram.c" enough?

    Yes, provided the link script supports it. The default GBA link scripts for DevKit Advance R5b3 and devkitARM R8 do.

    Quote:
    For the ARM instructiuns, you mean I can compile only this file with "-marm" so that I take advantage of the memory BUS related to IWRAM?

    Yes. In my makefiles, I have set %.iwram.o to use -marm and others to use -mthumb.

    Quote:
    What does allocate from the stack means?

    It means make a local variable using the default 'auto' allocation method:
    Code:
    void foo()
    {
      int x[1024];

      /*... */
    }

    Some versions of GCC may allow making the array size a variable. I haven't worked with this much.

    Quote:
    Code:
    void __attribute__((section(".iwram"), long_call)) Fn(parameters)

    if you want to call code in ROM or EWRAM from IWRAM you need to
    use-mlong-calls when compiling.

    The attribute stuff is placed before the return type of the functiun, and it also specifies where the functiun is placed in memory. It is clearly different from what you have said.

    GCC seems rather lenient about where you put the attribute. There's more than one way to do it; I just recommend what I've found comfortable.

    Quote:
    a) For ROM, declare global const variables
    b)For EWRAM, declare a global pointer and malloc it so it goes in EWRAM
    c)For IWRAM, declare a global array
    What about a global pointer allocated dynamically in IWRAM?

    IWRAM is too small for dynamic allocation except for local variables on the stack.

    Quote:
    And a global array in EWRAM(without using malloc)?

    I haven't used it because anything put in section .ewram takes ROM space, even if it's all zeroed, and I haven't had time to try section .sbss.

    If you want help with getting a specific example to compile, then please post your best effort along with the specific error messages it returns.
    _________________
    -- Where is he?
    -- Who?
    -- You know, the human.
    -- I think he moved to Tilwick.