X86/PPC linking (was Re: [Darwine] Re: Wine Emulation: Swapping
m.hearn at signal.QinetiQ.com
Thu Aug 26 03:30:33 CDT 2004
>> b) TransGamings Cedega forked from Wine several years ago, back when
>> it was under the X11 license which allowed that. So they don't have to
>> contribute their code back.
>> c) That fork was what motivated the switch to LGPL.
> Well that makes sense. I couldn't make heads or tails of their
> licensing. Although it does say something about the Wine of WineX 2
> being LGPL. In any case it seemed clear that whatever they had is not
> free. Also I can't see why they would want to do any X86 emulation at
> all since games do usually need maximum performance. I have to figure
> that they are using Winelib.
Parts of it are LGPLd, parts are X11d and parts are under the AFPL. What
license things are under is pretty important you know.
> That was indeed true before OS X. Typically ironic/tragic of Apple that
> the machines most in need of WORA had lousy Java. Fortunately on OS X
> the Java is at least as good and in some cases (such as Swing
> performance) is better than on Windows.
No, TransGaming has only ever worked with OS X. I'm afraid these stories
were about quite recent behaviour (last two years or so).
> This is another area that integration opens up for innovation.
No it doesn't. If you want native theming you'd have to implement a
UXTHEME bridge to appearance manager. X11/Quartz is orthogonal to this
> Of course even so, as I said to begin with, such driver layering is
> devastating to performance and any hope of order-of-magnitude speed up.
The truly graphics performance critical parts for games and such go via
DGA/GL anyway, so I'm not convinced about that. It's like saying X11 on
Windows can't possibly beat X11 on Linux because it has to go via the
GDI, yet it can sometimes happen.
> The ideal method would be to handle this with a trick loader that can
> link to PPC code which is escaped from the X86 emulation. We can
> automatically generate X86 DLLs for the PPC dynamic libraries (and hence
> the OS X APIs) which have little emulation escape thunks in them. There
> is zero performance penalty since the emulator can compile such escapes
> as direct native calls. Callbacks use a similar sort of little thunk
> which calls the emulator with a given X86 address.
> I would really like to get away from having to write all the little
> wrappers to deal with the namespace problem. I believe we can solve
> that with a suitable naming convention as we began to do with the
> winegcc patch.
In order to write such thunks you would need a type description of the
entire Windows API, as pointed out by Rob. Generating this in a usable
form from the headers would be incredibly hard.
> Alternatively we could go with with dynamic binding as proposed by
> Alexandre and have a syscall (or emulation escape) to call PPC code.
> This is probably the easiest to implement but leaves us with extra call
> overhead (although apparently this is something that is currently done
> in Wine and is quite small).
Well more to the point it means you're emulating both the app and Wine,
which won't be performant.
> As for swapping functions, the preceding discussion reiterates my belief
> that we should confine such fussy business to the relatively small bit
> of code that calls into OS X, will be relatively stable over the long
> haul, and over which we have full control. And as for the concern over
> having Wine be X86 and hence incurring emulation overhead, this would be
> one of the first bits of code which would be a candidate for having its
> emulator-compiled code cached.
If you look at how many native imports Wine requires on Linux to get
full functionality I don't think you can say it's relatively small. It's
many thousands of functions, possibly more. It's hard to measure because
so much is dynamically loaded.
More information about the wine-devel