#7984 - mmajid - Sun Jun 29, 2003 10:19 pm
Hi,
I have a development environment where I can program flash cartridges. I have created a little bootstrap utility that allows me to download executables through the serial interface to WRAM, (0x2000000). The bootstrap utility then jumps to WRAM and starts execution. (Similar to Multiboot mode).
I would like to be able to create a library of classes and utilities and store them in ROM. (0x8000000). I would then like to be able to link to these utilities from an executable running in WRAM.
There might be a simple solution, but how do I get gcc/ld to create an executable starting at WRAM, but linking to libraries/utilities stored in ROM, without relocating all the libraries/utilities to the WRAM area ?
Any help would be greatly appreciated ...
#8007 - Jason Wilkins - Mon Jun 30, 2003 2:32 pm
One simple solution would be to have each of your downloadable images contain a vector table (array of pointers to functions) in a set location and have the download manager in ROM fill in that table before passing execution over to RAM.
_________________
http://devkitadv.sourceforge.net
#8008 - mmajid - Mon Jun 30, 2003 4:28 pm
Yes, that would work for C functions and data storage. I guess a similar way would be to parse the map file, and generate a .h header file that contains all the function addresses.
How would this work for generating objects from C++ classes ?
I'm trying a method that attaches __attribute__((section(".ewram")))
to all functions that I want to be located in EWRAM ...
... haven't quite got it working, yet
thanks
#8015 - Cyberman - Mon Jun 30, 2003 7:40 pm
You might have great difficulty with this and C++ classes.
It really depends on exporting information etc. A C++ object has the problem that Data and program are synonimous. So I do not recomend statically made C++ objects for example ( how do you control it's location of code versus data .. is the real issue). I believe you are safe though if you define all the C++ classes first THEN allocate them.
I think you are getting into an area close to how a DLL behaves when loaded in windows or Linux.
Cyb
#8150 - Jason Wilkins - Thu Jul 03, 2003 4:32 am
Even in windows, dynamically linking a DLL with C++ classes is not straightforward.
I was going to suggest that you use the facilities of the linker (partial linking and link scripts), but since I would have to figure that out for myself first and then report my results to you in detail I figured it probably was not worth it unless I wanted to do it myself.
What I am saying is, there are ways to do this which would allow really complicated things to work, but that if you can't figure them out yourself, then you aren't ready to do it (nice catch 22).
I say, keep it simple, make an array of functions to pointers at the end of ewram. Have the code in ROM fill in this array before branching to 0x02000000. Easy. You should be able to write wrappers for all your C++ functions:
| Code: |
extern "C" void *new_obj(int foo, int bar)
{
return new obj(foo, bar);
}
extern "C" int obj_foo(void* obj, int one, int two, int three)
{
return (myobj)obj->foo(one, two, three);
}
|
_________________
http://devkitadv.sourceforge.net
#8158 - mmajid - Thu Jul 03, 2003 11:55 am
Hi,
I have figured out a way to do this, that actually does use the linker. Basically, while compiling the ROM based utilities, I use the link script to "poke a hole" of exactly 100k bytes at the start of EWRAM (0x2000000). I then force the linker to place the RAM-based executable into this "hole".
It actually works quite well for both C and C++. The downloaded RAM-based executable can call utilities and instantiate classes that have been defined and are now resident in ROM.
If there is any interest, I can certainly provide more details ...
cheers,
Mike