From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IvkFT-0007Vq-IP for qemu-devel@nongnu.org; Fri, 23 Nov 2007 20:55:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IvkFR-0007Rc-OY for qemu-devel@nongnu.org; Fri, 23 Nov 2007 20:55:59 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IvkFR-0007RG-H1 for qemu-devel@nongnu.org; Fri, 23 Nov 2007 20:55:57 -0500 Received: from bangui.magic.fr ([195.154.194.245]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IvkFQ-0005aI-V3 for qemu-devel@nongnu.org; Fri, 23 Nov 2007 20:55:57 -0500 Received: from [192.168.0.2] (ppp-36.net-123.static.magiconline.fr [80.118.184.36]) by bangui.magic.fr (8.13.1/8.13.1) with ESMTP id lAO1tqef002068 for ; Sat, 24 Nov 2007 02:55:52 +0100 Subject: Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-... From: "J. Mayer" In-Reply-To: <1195867970.24893.66.camel@rapid> References: <200711232223.54239.paul@codesourcery.com> <1195861001.24893.40.camel@rapid> <200711240052.31546.paul@codesourcery.com> <1195867970.24893.66.camel@rapid> Content-Type: text/plain Date: Sat, 24 Nov 2007 02:55:54 +0100 Message-Id: <1195869354.24893.72.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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, 2007-11-24 at 02:32 +0100, J. Mayer wrote: > On Sat, 2007-11-24 at 00:52 +0000, Paul Brook wrote: > > > > 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. > > Yes, when running on a 64 bits host, we could avoid compiling > ppc-softmmu. It's still interresting to use it on 32 bits host, as an > optimisation, because it runs much faster than the ppc64-softmmu > version. > > > 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. I did forget one important point: it's not exposed to the qemu user. The qemu log is a qemu developper tool.Most of the trace involved has to be explicitally activated with specific defines in the Qemu code. The qemu log is not to be of any help for a end-user, it's a tool for Qemu development and bug reports. >>From the end-user side, the fact that GPR are implemented as 64 bits values is never visible, even from the gdb stub. Then... [...] -- J. Mayer Never organized