[Scummvm-devel] Question regarding DC plugins

[yotam barnoy]

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.

Yotam


Can't really make the ARM or PPC version though --

On Wed, Sep 2, 2009 at 5:49 PM, Max Horn <max at quendi.de> wrote:

>
> 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
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090903/32dca439/attachment.html>