From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ivi4G-0007AS-Ez for qemu-devel@nongnu.org; Fri, 23 Nov 2007 18:36:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ivi4F-00079s-LJ for qemu-devel@nongnu.org; Fri, 23 Nov 2007 18:36:15 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ivi4F-00079g-FF for qemu-devel@nongnu.org; Fri, 23 Nov 2007 18:36:15 -0500 Received: from relay01.mx.bawue.net ([193.7.176.67]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ivi4F-0000lX-4I for qemu-devel@nongnu.org; Fri, 23 Nov 2007 18:36:15 -0500 Date: Fri, 23 Nov 2007 23:36:11 +0000 From: Thiemo Seufer Subject: Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-... Message-ID: <20071123233611.GH9204@networkno.de> References: <200711232136.55819.paul@codesourcery.com> <1195855536.24893.21.camel@rapid> <200711232223.54239.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711232223.54239.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: "J. Mayer" , qemu-devel@nongnu.org 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. Thiemo