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 <[EMAIL PROTECTED]> Never organized