When will Wine integrate an x86 CPU emulator?

[Francois Gouget]

On Wed, 20 Aug 2003, Ulrich Weigand wrote:
[...]
> The only reason for wanting to integrate an emulator into Wine is that this
> would allow to run the Wine components natively, and only switch to the
> emulator for executing Windows binaries.
[...]

Not only it would be extremely complex but I am not even sure it would
be more efficient.

The situation would be similar to what happens to DIBs. Whenever we are
asked to perform an operation on a DIB such as draw a line, we convert
it to a pixmap and invoke X to perform the operation. This allows us to
reuse X's highly optimized and potentially hardware accelerated
routines. That should be optimal, right?

The problem is that if the application then accesses the image directly,
which is often the goal behind DIBs, then we have to convert the pixmap
back to the DIB format. Enough of this ping-pong between the DIB and the
pixmap format will completely kill performance (10x slowdown or more
depending on the size of the DIB and the frequency of th eping-pong,
hence the various calls for a DIB engine).

How does that apply to the emulator case? Well, let's take InflateRect:

BOOL InflateRect(LPRECT lprc, int dx, int dy);

lprc points to this structure:

typedef struct {
  LONG left;
  LONG top;
  LONG right;
  LONG bottom;
} RECT;

Obviously Winelib applications are going to assume the structure fields
use the platform's native byte ordering, big endian for instance. And so
will Wine's code.

So for each call to InflateRect we will need a wrapper that:
 1 - copies the structure pointed to by the lprc pointer fixing
the byte order
 2 - fixes the byte ordering of dx and dy
 3 - calls Wine's native (big endian) InflateRect implementation
 4 - copies the resulting rect structure back to the location pointed
by lprc, fixing the byte ordering again

Now, will the overhead of the 2 copies and byte-swapping operations be
lower than simply running the little endian version of InflateRect in
the emulator? I'm not sure it will be the case.

This is not a fringe case. Copying stuff back and forth will be the norm
more than the exception and with much bigger structures too. For
instance PolyLineTo takes an array of POINT structures which will need
to be entirely copied and byte swapped before the native implementation
can use it. Same thing for DIBs: Winelib applications (and thus native
Wine code) may expect 16 and 32 bit DIBs to be in big endian format
while Windows applications will expect them to be in little endian
format. Now we're talking about converting kilobytes of data back and
forth with each call...

In other words, not only integrating an emulator in Wine is going to be
awfully complex, but it may turn out to provide lower performance than
simply running Wine plus the Windows application in an emulated x86
environment.

-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
                            1 + e ^ ( i * pi ) = 0