From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BjHcp-0001BQ-Ab for qemu-devel@nongnu.org; Sat, 10 Jul 2004 09:10:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BjHco-0001B6-E1 for qemu-devel@nongnu.org; Sat, 10 Jul 2004 09:10:42 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BjHco-0001B3-84 for qemu-devel@nongnu.org; Sat, 10 Jul 2004 09:10:42 -0400 Received: from [62.210.158.41] (helo=moscou.magic.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BjHaI-0001in-9W for qemu-devel@nongnu.org; Sat, 10 Jul 2004 09:08:06 -0400 Received: from [10.0.0.2] (ppp-181.net-555.magic.fr [62.210.255.181]) by moscou.magic.fr (8.11.6/8.10.1) with ESMTP id i6AD81X03242 for ; Sat, 10 Jul 2004 15:08:01 +0200 (CEST) Subject: Re: [Qemu-devel] Inquiry, speed comparison on OS X, QEMU vs Virtual PC From: "J. Mayer" In-Reply-To: <44F4591D-D26F-11D8-858B-000A2796D230@free.fr> References: <44F4591D-D26F-11D8-858B-000A2796D230@free.fr> Content-Type: text/plain; charset=iso-8859-15 Message-Id: <1089464888.29042.23012.camel@rapid> Mime-Version: 1.0 Date: Sat, 10 Jul 2004 15:08:08 +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 Le 9 juil. 04, =E0 22:07, Natalia Portillo a =E9crit : >=20 > > I think that including support for the PowerPC swapping instructions=20 > > in QEMU > > will break compatibility with host PowerPCs before G3, so that=20 > > instructions > > 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=20 > Book, all the implementation 601,603,604,620 should include support for= =20 > the lwbrx and stwbrx instructions. I think all PPC include those instructions and gcc already uses them for endian-swapping. It seems to me that the feature which is discussed here is the presence of IE bit in the machine state register. 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. 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. --=20 J. Mayer Never organized