[Scummvm-devel] Question regarding DC plugins

[Max Horn]

Am 20.08.2009 um 19:12 schrieb Andre Heider:

> On Thu, Aug 20, 2009 at 4:49 PM, yotam barnoy<yotambarnoy at gmail.com>  
> wrote:
>> While I'm at it, could the Wii developers tell me why they didn't  
>> manage to
>> use this approach with the Wii? I'm guessing that it has to do with  
>> the
>> PowerPC's instruction vs. data memory protection and not having  
>> kernel level
>> access, but I'd be interested to know for sure so that if this  
>> method is not
>> doable for the PSP I won't waste too much time on it.
>
> There is no memory protection on the PPC side for the Wii, so using
> the DC plugin approach for the Wii is possible without technical
> difficulties. You can just write code to memory and jump there.
> Its not that urgent because a ScummVM binary with all game engines
> does works fine, we didn't yet hit the memory limit on any game. The
> exception is the Gamecube port, which uses the same code as the Wii
> port, and COMI runs out of memory there. I once tried various
> implementation to realise plugins, but didn't finish it. I guess we do
> hit the limit sooner or later, because the number of game engines grow
> from release to release, and the size of the executable does matter.
> Plugins provide a nice way to solve that problem. I'd rather implement
> that than providing multiple binaries with a different game engines
> compiled in.

This is also why it would be *very* nice to have plugin support on the  
Nintendo DS -- much more elegant to have loadable plugins than to have  
7+ versions of the executable, each with a different set. Also much  
more convenient for both developers *and* users.


> It's possible to code a generic ELF plugin, which is reusable for
> multiple ports.

Indeed. And having that would be absolutely fantastic (it's been on  
our GSoC task list, too but sadly no qualified person was interested  
in doing it).

Anybody who wants to work on that is highly welcome :).


> It just has to support the CPU architecture for the
> port you want to use it for: You allocate memory for the plugin and
> load the ELF sections in there, but you have to relocate it.
> Relocating code fixes up things like jump instructions, which is
> necessary because the code location in memory is unknown at the time
> you compile the plugin.
> There are multiple relocation types for every CPU architecture. The DC
> has a SH CPU, and I think Marcus just needed to implement one
> relocation type. But as is, its not reusable, because of the different
> CPU type.

Besides SH (for DC) and PPC (for Wii/Gamecube), we could benefit from  
MIPS support (e.g. for the PSP), and most importantly, ARM support  
(which is used for the Nintendo DS, WinCE, and many other small  
devices). Ideally, we'd have a generic ELF loader which can be  
customized (via subclassing, or some other method) to handle  
relocation on various architectures.


> Then, there's an option to compile code as PIC (position independent
> code), but the plugin still needs to jump back to common function in
> the main code - hence relocation in mandatory.
>
> To port it for Wii/GC, one would have to implement the PPC relocation
> types, and the reason I didn't finish is because there are so many:
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/elf/ppc.h?rev=1.25&content-type=text/x-cvsweb-markup&cvsroot=src
> I'm not sure how many of those are really required.

Can't we find out? I.e. generate a plugin, run over it, and see which  
relocations types are actually used.  Then only implement those. If  
later on other types crop up (which would trigger an error in our  
relocator, of course), we could add support for them gradually.

(BTW, ARM might be worse, as there are several major variants of it,  
e.g. regular vs. thumb etc. -- then again, we have our own local ARM  
guru who might be able to help... ;).


> You should talk to Joost before working on plugin support for the PSP.
> I think he once mentioned some platform specific feature that could be
> used for plugins, and a full fledged plugin loader might not be
> necessary. But it's possible I mix things up and that's just not true
> ;)


A full fledged loader would still be nice for ARM architectures,  
though -- how about getting an NDS in addition to that PSP? :)


Cheers,
Max