> > 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
