Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-...

[Paul Brook <paul@codesourcery.com>]

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