Search the web
Sign In
New User? Sign Up
gbadev
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Real people. Real stories. See how Yahoo! Groups impacts members worldwide.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
Re: Can you Clarify ...   Message List  
Reply | Forward Message #8679 of 15019 |


owaincole@t... wrote:
> Hi, just wondered if you could clarify whether declaring the function
> as
>
> void fun(void) __attribute__((section(".iwram"),long_call));
>
> actually puts the function in iwram? Or do you need to do something
> else too (eg when you define it).
> All help much appreciated!
> Owain

right, i could be more precise... ;) i was assuming that people are
using devkitadvance gcc port whith jeff's linkscript and crt0.s and was
too lazy to write the details down.

the statement above is just telling compiler to assign the function code
to .iwram section and to assume that the function address is far away
and can't be reached by short calls (implies indirect calls by loading
the absolute 32bit address into register before calling it, samilar way
as c++ does when you are calling virtual methods.) if you are using
linkscript and crt file mentioned above, there is nothing more you have
todo. but.. just specifying the __attribute__ without telling to linker
what this is all about is of course not enough..

linker has to know where to put .iwram section actually, that's what the
linkscript is good for. for example, jeffs lnkscript has following
statement (i simplified it a bit):

__iwram_start = 0x3000000; // VMA
__iwram_lma = .; // LMA
.iwram __iwram_start: AT (__iwram_lma)
{
*(.iwram)
. = ALIGN(4);
} = 0xff
__iwram_end = . ;

this tells linker to collect all .iwram code from your object files and
merge it into a single .iwram section of your output .elf file. the code
is placed at the first available address in ROM(!) (so called 'load
memory address') and labeled as __iwram_lma. this also tells linker that
the section starts at virtual address 0x3000000 (gba internal ram), this
means that all symbolic references to code and data in .iwram section
will be resolved as if the code were placed in internal ram. (for more
information on linkscripts see the linker documentation on gnu.org)

linker can not load your code into internal ram, this is a job of your
startup code (jeffs crt0.s implements this.) at startup, the crt
initialisation routine copies the code from ROM starting at location
__iwram_lma and ending at __iwram_end to address 0x3000000. from this
point your iwram routines are ready to be called.

i hope i could clarify it a bit..

there is also a solution how to manage your iwram code dynamically, in
case you are running out of internal ram. to do that, you can use
.iwram0 - .iwram9 sections which are overlayed by the linkscript, i.e.
the same internal ram virtual memory address is assigned to all these
sections. you just have to copy the code at runtime manually before
calling methods or accessing data from overlayed sections. for details
just look at jeffs linkscript and crt0.s

Dima





Mon Dec 3, 2001 3:43 pm

dmitri_dev
Offline Offline
Send Email Send Email

Forward
Message #8679 of 15019 |
Expand Messages Author Sort by Date

... right, i could be more precise... ;) i was assuming that people are using devkitadvance gcc port whith jeff's linkscript and crt0.s and was too lazy to...
Dima
dmitri_dev
Offline Send Email
Dec 3, 2001
3:54 pm
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help