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

[J. Mayer]

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

OK. Maybe I did not properly said the fact: the spec says that if an
implementation (said "embedded"...) does not implement any 64 bits
operation, it could also optionally avoid using 64 bits GPR. And of
course this can lead to avoid any 64 bits computation to be implemented
on the silicium. But this is not defined as the normal behavior of a
PowerPC CPU.
But as you said, this does not change nothing when seen from the
execution environment, even if it's not architecturally correct.
SPE is not using separate registers. The specification actually says the
GPR are 64 bits even on 32 bits implementations if SPR is implemented.
SPE operations affect all 64 bits of the register and this can then be
seen with "standard" PowerPC operations.

I did take care of your remarks about the buggy prints and made a
general pass in all the target-ppc code (it seems they were even more
issues). I also made the SPE part of GPR available in CPU dumps.
This leads me to say that if we ever want to change the behavior of the
32 bits PowerPC emulation, it will only need a one line patch. For now I
would really like to keep the current behavior which is architecturally
correct and helps me debugging the 64 bits part; this is one of the
reasons why I first decided to do this way, the other one being the fact
it seems to lead to better code on my x86_64 host. When the 64 bits
emulation will be fully usable, I could imagine come back to "strict 32
bits" for the ppc-xxx target, as those target would become "not so
useful"...

-- 
J. Mayer <address@hidden>
Never organized