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

[Jocelyn Mayer <l_indien@magic.fr>]

On Fri, 2007-11-23 at 19:10 +0000, Paul Brook wrote:
> > > The old code before the patch is obviously broken. It's mixing 64-bit
> > > (ppc_gpr_t) and 32-bit (target_ulong) values.
> >
> > It seems you do not understand that what was done was correct. It's not
> > mixing two different types. GPR are of ppc_gpr_t type and should be
> > displayed this way. 
> > It's not garbage. On 64 bits hosts, the 64 bits GPR dump is correct. GPR
> > _are 64 bits_ when compiling the ppcemb target and should be displayed
> > as 64 bits value. 
> 
> Really? Where exactly is the code that uses a 64-bit ppc_gpr_t ?
> I don't see any evidence that the high bits of the value is ever used.

Then I took a closer look to the code, to ensure I was not wrong.
The PowerPC 32 on 64 bits hosts is implemented the same way that the
specification says a PowerPC in 32 bits mode should be. Then higher bits
are not garbage. They are what the PowerPC specification say they should
be (apart if they are some bugs in the implementation). The fact that
they are or not used by computations is another point. The fact is the
registers values are correct.
And the fact is that printing a uint64_t on any 64 bits host (x86_64 or
any other) using PRIx64 is exactly what is to be done, according to ISO
C. Then, pretending that it would crash on any host is completelly
pointless.

> I see the SPE stuff that uses T0_64 et al, however this still uses
> stores the value in the low 32 bits of the {gpr,gprth} pair.

SPE dump is the case that does not work properly. Your patch does not solve anything here, just breaks the main stream case.