From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BjIWW-0004cX-AU for qemu-devel@nongnu.org; Sat, 10 Jul 2004 10:08:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BjIWT-0004cL-HU for qemu-devel@nongnu.org; Sat, 10 Jul 2004 10:08:16 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BjIWT-0004cI-EK for qemu-devel@nongnu.org; Sat, 10 Jul 2004 10:08:13 -0400 Received: from [62.210.190.9] (helo=brazzaville.magic.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BjITr-000830-Dx for qemu-devel@nongnu.org; Sat, 10 Jul 2004 10:05:31 -0400 Received: from [10.0.0.2] (ppp-181.net-555.magic.fr [62.210.255.181]) by brazzaville.magic.fr (8.11.6/8.11.6) with ESMTP id i6AE5F415679 for ; Sat, 10 Jul 2004 16:05:21 +0200 Subject: Re: [Qemu-devel] Inquiry, speed comparison on OS X, QEMU vs Virtual PC From: "J. Mayer" In-Reply-To: <59AF2458-D274-11D8-858B-000A2796D230@free.fr> References: <44F4591D-D26F-11D8-858B-000A2796D230@free.fr> <1089464888.29042.23012.camel@rapid> <59AF2458-D274-11D8-858B-000A2796D230@free.fr> Content-Type: text/plain; charset=iso-8859-15 Message-Id: <1089468317.26832.23200.camel@rapid> Mime-Version: 1.0 Date: Sat, 10 Jul 2004 16:05:18 +0200 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Sat, 2004-07-10 at 15:23, Pierre d'Herbemont wrote: > Le 10 juil. 04, =E0 15:08, J. Mayer a =E9crit : > > 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=20 > >> for > >> the lwbrx and stwbrx instructions. > > > > I think all PPC include those instructions and gcc already uses them=20 > > for > > endian-swapping. > > It seems to me that the feature which is discussed here is the presen= ce > > of IE bit in the machine state register. >=20 > you mean the LE bit? I first read the IE bit ;) Again according the=20 > this same book the LE bit should exits in the previous implementation. Yes, you're right, my confusion came from the ILE bit :-) > > I don't think using this bit could improve performances a lot. Becaus= e > > 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. >=20 > ok, thanks... I wonder if it can help the darwine project in some ways:= =20 > having Wine compiled as LE/PowerPC, and running it in some kind of=20 > virtualizer which would only swap sycall... Anyway I was speaking at=20 > the begining of the thread of the *brx instructions which are not used=20 > in the Mac OS X build. Oh, well, so you're right, using those instructions will boost the emulation. I just check: PPC601, 602, 603e and 604 user manuals claim those instructions are available.=20 I doubt that some PPC don't implement those instr because they are very useful for IO accesses: many devices and busses are designed for use with Intel CPU/busses. So OSes need that feature ! > > 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 wi= n > > would not be spectacular, imho. >=20 > In fact you can emulate this with mprotect-ing the region, and handle=20 > the conversion at signal catch, but it shouldn't be really performant. Yes, this could only be used if the memory controler can manage it by itself. I'm sure emulating this feature would be less performant than using *brx instructions. The only drawback of *brx instructions is that only one addressing mode is available, so it needs an extra register load to emulate an register + offset access. --=20 J. Mayer Never organized