From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iw0r6-0002m4-6z for qemu-devel@nongnu.org; Sat, 24 Nov 2007 14:39:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iw0r3-0002iP-Uu for qemu-devel@nongnu.org; Sat, 24 Nov 2007 14:39:55 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iw0r3-0002i4-OG for qemu-devel@nongnu.org; Sat, 24 Nov 2007 14:39:53 -0500 Received: from sp604002mt.neufgp.fr ([84.96.92.61] helo=sMtp.neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iw0r3-0004Il-Ad for qemu-devel@nongnu.org; Sat, 24 Nov 2007 14:39:53 -0500 Received: from [84.102.211.65] by sp604002mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0JS000LXMZY3D2V1@sp604002mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Sat, 24 Nov 2007 20:39:39 +0100 (CET) Date: Sat, 24 Nov 2007 20:39:06 +0100 From: Fabrice Bellard Subject: Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-... In-reply-to: <20071123233611.GH9204@networkno.de> Message-id: <47487DDA.4050502@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200711232136.55819.paul@codesourcery.com> <1195855536.24893.21.camel@rapid> <200711232223.54239.paul@codesourcery.com> <20071123233611.GH9204@networkno.de> 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 Cc: "J. Mayer" , Paul Brook Thiemo Seufer wrote: > Paul Brook wrote: >>>> I think what you mean is that they work the way that ppc64 is defined, to >>>> remain compatible with ppc32. IMHO this is entirely irrelevant as we're >>>> emulating a ppc32. You could replace the high bits with garbage and >>>> nothing would ever be able to tell the difference. >>> PowerPC is a 64 bits architecture. PowerPC 32 on 32 bits host is >>> optimized not to compute the 32 highest bits, the same way it's allowed >>> to cut down the GPR when implementing a CPU that would not support the >>> 64 bits mode (but this is a tolerance, this is not the architecture is >>> defined). >> No. PowerPC is defined as a 64-bit archirecure. However there is a subset of >> this architecture (aka ppc32) that is a complete 32-bit architecture in its >> own right. By your own admission, we can get away with not calculating the >> high 32 bit of the register. If follows that the high bits are completely >> meaningless. > > This btw. also means that the ppc32 emulation on 32-bit hosts is needlessly > inefficient if the high bits are carried around. > >> The qemu ppc32 emulation is implemented in such a way that on 64-bit hosts it >> looks a lot like a ppc64 implementation. However this need not, and should >> not be exposed to the user. >> >>> OK. Those are real bugs to be fixed. I'll take a look.... But I'll try >>> not to break the GPR dump. In fact, GPR should always dumped as 64 bits, >>> even when runnig on 32 bits hosts. This would be more consistent with >>> the specification. >> I disagree. qemu is implementing ppc32. Showing more than 32 bits of register >> is completely bogus. Any differences between a 32-bit host and a 64-bit host >> are a qemu bug. If you display 64 bits, then those 64 bits had better be the >> same when run on 32-bit hosts. > > I strongly agree with Paul. I strongly agree too and I suggest to remove the type ppc_gpr_t and to replace it with target_ulong (and uint32_t for the high part of the SPE extensions). Regards, Fabrice.