qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Brook
Subject: Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-...
Date: Fri, 23 Nov 2007 21:36:55 +0000
User-agent: KMail/1.9.7

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

AFAICS the high bits are never used by anything.

I think what you mean is that they work the way that ppc64 is defined, to 
remain compatible with ppc32.  IMHO this is entirely irrelevant as we're 
emulating a ppc32. You could replace the high bits with garbage and nothing 
would ever be able to tell the difference.

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

We weren't printing a 64-bit value. We were passing a 32-bit target_ulong with 
a PRIx64 format. Some concrete examples:
translate.c:6052:
    cpu_fprintf(f, "MSR " REGX FILL " HID0 " REGX FILL "  HF " REGX FILL
                env->msr, env->hflags, env->spr[SPR_HID0],

All these values are 32-bit tagret_ulong. Using a 64-bit format specifierfor 
ppc32 targets is just nonsense.

And at line 6069 we even have an explicit cast to a 32-bit type:

        cpu_fprintf(f, " " REGX, (target_ulong)env->gpr[i]);

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

I agree that SPE register dumping does not work, however I also assert that it 
was never even close to working, and if REGX is supposed to be the solution 
then most of the uses of REGX are incorrect.

Please give a concrete example of something that worked before and does not 
now.

Paul




reply via email to

[Prev in Thread] Current Thread [Next in Thread]