From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IvjGB-000121-BH for qemu-devel@nongnu.org; Fri, 23 Nov 2007 19:52:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IvjG9-00011G-14 for qemu-devel@nongnu.org; Fri, 23 Nov 2007 19:52:38 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IvjG8-00011D-Ti for qemu-devel@nongnu.org; Fri, 23 Nov 2007 19:52:36 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IvjG8-0000a6-OZ for qemu-devel@nongnu.org; Fri, 23 Nov 2007 19:52:36 -0500 From: Paul Brook Subject: Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-... Date: Sat, 24 Nov 2007 00:52:29 +0000 References: <200711232223.54239.paul@codesourcery.com> <1195861001.24893.40.camel@rapid> In-Reply-To: <1195861001.24893.40.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711240052.31546.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: qemu-devel@nongnu.org Cc: "J. Mayer" > > 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. > > Not completelly. There are even some way to do 64 bits computations when > running in 32 bits mode... Some may see this as an architecture hack, > but this gives the only way to switch from 32 bits to 64 bits mode (as > the sixty-four MSR bits lies in the highest bits of the register). Anything that involves switching to 64-bit mode to see th results is irelevant because we don't implement that. You can't have it both ways. Either you need to implement the full 64-bit gpr for correctness, in which case I guess we're most of the way to scrapping ppc-softmmu and using ppc64-softmmu all the time, or the high bits are not part of the interesting CPU state. I can believe that on some hosts it's cheaper to use a 64-bit gpr_t, and the architecture/implementation is such that it gives the same results as a 32-bit gpr_t. However this is an implementation detail, and should not be exposed to the user. > To complicate the situation, it's also required that "standard" > implementation do all computations on 64 bit values Really? Are you sure? I can understand the architecture being defined in terms of 64-bit gprs. However if the high half of those registers is never visible to the application/OS then those aren't actually requirements, they're just a convenient shorthand for avoiding having to describe everything twice. > > I disagree. qemu is implementing ppc32. > > which does not exists. Well, I admit I've invented the term "ppc32", but there are dozens of 32-bit PowerPC chips. I'd be amazed if they do 64-bit computations or have 64-bit GPRs. SPE doesn't count as the high half is effectively a separate register file on 32-bit cores. Paul