[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Inquiry, speed comparison on OS X, QEMU vs Virtual PC

From: Pierre d'Herbemont
Subject: Re: [Qemu-devel] Inquiry, speed comparison on OS X, QEMU vs Virtual PC
Date: Sat, 10 Jul 2004 15:23:37 +0200

Le 10 juil. 04, à 15:08, J. Mayer a écrit :

Le 9 juil. 04, à 22:07, Natalia Portillo a écrit :

I think that including support for the PowerPC swapping instructions
will break compatibility with host PowerPCs before G3, so that
should be used in a run-time capability detection scheme.

On Sat, 2004-07-10 at 14:47, Pierre d'Herbemont wrote:
Which PowerPC Implementations? According to The PowerPC Architecture
Book, all the implementation 601,603,604,620 should include support for
the lwbrx and stwbrx instructions.

I think all PPC include those instructions and gcc already uses them for
It seems to me that the feature which is discussed here is the presence
of IE bit in the machine state register.

you mean the LE bit? I first read the IE bit ;) Again according the this same book the LE bit should exits in the previous implementation.

I don't think using this bit could improve performances a lot. Because
there is only one bit to control the CPU and because most of the
problems are already solved using brx load and stores.
You would need to patch the kernel to use this bit (if it exists) and
need kernel calls when you ever want to change the access mode, which
seems not so great.

ok, thanks... I wonder if it can help the darwine project in some ways: having Wine compiled as LE/PowerPC, and running it in some kind of virtualizer which would only swap sycall... Anyway I was speaking at the begining of the thread of the *brx instructions which are not used in the Mac OS X build.

What could be more benefic would be a feature which exists in the PPC
405: one can define a memory area using big or little endian accesses.
But this seems to be very specific to the 405 and, once again, the win
would not be spectacular, imho.

In fact you can emulate this with mprotect-ing the region, and handle the conversion at signal catch, but it shouldn't be really performant.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]