<div dir="ltr">Once I have the PSP plugins working (which should hopefully be fairly soon), I wouldn't mind working on a generic ELF class-based extendable loader. I've already gone through the loader code and spent time learning about the ELF file format and loader scripts (as well as makefiles and gcc/ld options which I knew shamefully little about) so I might as well put that new knowledge to some more use. <br>
<br>Yotam<br><br>
<br>Can't really make the ARM or PPC version though -- <br><br><div class="gmail_quote">On Wed, Sep 2, 2009 at 5:49 PM, Max Horn <span dir="ltr"><<a href="mailto:max@quendi.de" target="_blank">max@quendi.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Am 20.08.2009 um 19:12 schrieb Andre Heider:<br>
<div><br>
> On Thu, Aug 20, 2009 at 4:49 PM, yotam barnoy<<a href="mailto:yotambarnoy@gmail.com" target="_blank">yotambarnoy@gmail.com</a>><br>
> wrote:<br>
>> While I'm at it, could the Wii developers tell me why they didn't<br>
>> manage to<br>
>> use this approach with the Wii? I'm guessing that it has to do with<br>
>> the<br>
>> PowerPC's instruction vs. data memory protection and not having<br>
>> kernel level<br>
>> access, but I'd be interested to know for sure so that if this<br>
>> method is not<br>
>> doable for the PSP I won't waste too much time on it.<br>
><br>
> There is no memory protection on the PPC side for the Wii, so using<br>
> the DC plugin approach for the Wii is possible without technical<br>
> difficulties. You can just write code to memory and jump there.<br>
> Its not that urgent because a ScummVM binary with all game engines<br>
> does works fine, we didn't yet hit the memory limit on any game. The<br>
> exception is the Gamecube port, which uses the same code as the Wii<br>
> port, and COMI runs out of memory there. I once tried various<br>
> implementation to realise plugins, but didn't finish it. I guess we do<br>
> hit the limit sooner or later, because the number of game engines grow<br>
> from release to release, and the size of the executable does matter.<br>
> Plugins provide a nice way to solve that problem. I'd rather implement<br>
> that than providing multiple binaries with a different game engines<br>
> compiled in.<br>
<br>
</div>This is also why it would be *very* nice to have plugin support on the<br>
Nintendo DS -- much more elegant to have loadable plugins than to have<br>
7+ versions of the executable, each with a different set. Also much<br>
more convenient for both developers *and* users.<br>
<div><br>
<br>
> It's possible to code a generic ELF plugin, which is reusable for<br>
> multiple ports.<br>
<br>
</div>Indeed. And having that would be absolutely fantastic (it's been on<br>
our GSoC task list, too but sadly no qualified person was interested<br>
in doing it).<br>
<br>
Anybody who wants to work on that is highly welcome :).<br>
<div><br>
<br>
> It just has to support the CPU architecture for the<br>
> port you want to use it for: You allocate memory for the plugin and<br>
> load the ELF sections in there, but you have to relocate it.<br>
> Relocating code fixes up things like jump instructions, which is<br>
> necessary because the code location in memory is unknown at the time<br>
> you compile the plugin.<br>
> There are multiple relocation types for every CPU architecture. The DC<br>
> has a SH CPU, and I think Marcus just needed to implement one<br>
> relocation type. But as is, its not reusable, because of the different<br>
> CPU type.<br>
<br>
</div>Besides SH (for DC) and PPC (for Wii/Gamecube), we could benefit from<br>
MIPS support (e.g. for the PSP), and most importantly, ARM support<br>
(which is used for the Nintendo DS, WinCE, and many other small<br>
devices). Ideally, we'd have a generic ELF loader which can be<br>
customized (via subclassing, or some other method) to handle<br>
relocation on various architectures.<br>
<div><br>
<br>
> Then, there's an option to compile code as PIC (position independent<br>
> code), but the plugin still needs to jump back to common function in<br>
> the main code - hence relocation in mandatory.<br>
><br>
> To port it for Wii/GC, one would have to implement the PPC relocation<br>
> types, and the reason I didn't finish is because there are so many:<br>
> <a href="http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/elf/ppc.h?rev=1.25&content-type=text/x-cvsweb-markup&cvsroot=src" target="_blank">http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/elf/ppc.h?rev=1.25&content-type=text/x-cvsweb-markup&cvsroot=src</a><br>
> I'm not sure how many of those are really required.<br>
<br>
</div>Can't we find out? I.e. generate a plugin, run over it, and see which<br>
relocations types are actually used. Then only implement those. If<br>
later on other types crop up (which would trigger an error in our<br>
relocator, of course), we could add support for them gradually.<br>
<br>
(BTW, ARM might be worse, as there are several major variants of it,<br>
e.g. regular vs. thumb etc. -- then again, we have our own local ARM<br>
guru who might be able to help... ;).<br>
<div><br>
<br>
> You should talk to Joost before working on plugin support for the PSP.<br>
> I think he once mentioned some platform specific feature that could be<br>
> used for plugins, and a full fledged plugin loader might not be<br>
> necessary. But it's possible I mix things up and that's just not true<br>
> ;)<br>
<br>
<br>
</div>A full fledged loader would still be nice for ARM architectures,<br>
though -- how about getting an NDS in addition to that PSP? :)<br>
<br>
<br>
Cheers,<br>
Max<br>
<br>
------------------------------------------------------------------------------<br>
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day<br>
trial. Simplify your report design, integration and deployment - and focus on<br>
what you do best, core application coding. Discover what's new with<br>
Crystal Reports now. <a href="http://p.sf.net/sfu/bobj-july" target="_blank">http://p.sf.net/sfu/bobj-july</a><br>
_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href="mailto:Scummvm-devel@lists.sourceforge.net" target="_blank">Scummvm-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/scummvm-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br>
</blockquote></div><br></div>