Thiemo Seufer wrote:
> Paul Brook wrote:
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 a
On Sat, 2007-11-24 at 02:32 +0100, J. Mayer wrote:
> On Sat, 2007-11-24 at 00:52 +, 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.
> > >
>
On Sat, 2007-11-24 at 00:52 +, 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
> 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.
Indeed not. Valgrind implements the 32-bit PPC user-space instruction set
quite adequately using 32-bit computations throughout. No
> > 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 archi
J. Mayer wrote:
[snip]
> > Showing more than 32 bits of register
> > is completely bogus.
>
> No. It's showing the full CPU state, which can be more than what the
> application (or the OS, when running virtualized on a real CPU) could
> see. The OS cannot see the whole CPU state, but Qemu must i
On Fri, 2007-11-23 at 22:23 +, Paul Brook wrote:
> > > 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
> > > nothin
Paul Brook wrote:
> > > 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 dif
> > 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.
>
> PowerPC is a
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/11/23 22:16:59
Modified files:
hw : ppc_oldworld.c
target-ppc : cpu.h helper.c op_helper.c
Log message:
Revert foolish patch.
CVSWeb URLs:
http://cvs.savannah.gnu.org/vi
On Fri, 2007-11-23 at 21:36 +, Paul Brook wrote:
> > 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
> 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 (apar
On Fri, 2007-11-23 at 19:10 +, 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 a
On Fri, 2007-11-23 at 19:10 +, 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 a
> > 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
On Fri, 2007-11-23 at 19:42 +0100, Jocelyn Mayer wrote:
> On Fri, 2007-11-23 at 18:22 +, Paul Brook wrote:
> > > Furthermore this patch was made in a brainless way, it will be reverted
> > > asap.
> > > If you think there is a bug in someone else code, submit it a patch, if
> > > it's cleaver
On Fri, 2007-11-23 at 18:22 +, Paul Brook wrote:
> > Furthermore this patch was made in a brainless way, it will be reverted
> > asap.
> > If you think there is a bug in someone else code, submit it a patch, if
> > it's cleaver and addresses a real bug (which is not the case here) it
> > will
> Furthermore this patch was made in a brainless way, it will be reverted
> asap.
> If you think there is a bug in someone else code, submit it a patch, if
> it's cleaver and addresses a real bug (which is not the case here) it
> will be accepted and merged.
The old code before the patch is obviou
On Fri, 2007-11-23 at 17:33 +, Paul Brook wrote:
> CVSROOT: /sources/qemu
> Module name: qemu
> Changes by: Paul Brook 07/11/23 17:33:13
>
> Modified files:
> hw : ppc_oldworld.c
> target-ppc : cpu.h helper.c op_helper.c
>
> Log message:
> Fix
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/23 17:33:13
Modified files:
hw : ppc_oldworld.c
target-ppc : cpu.h helper.c op_helper.c
Log message:
Fix ppc32 register dumps on 64-bit hosts.
CVSWeb URLs:
http://cv
20 matches
Mail list logo
