qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] ppc32 guests: fix computation of XER.{CA, OV} i


From: J. Mayer
Subject: Re: [Qemu-devel] [PATCH] ppc32 guests: fix computation of XER.{CA, OV} in addme, subfme, mullwo
Date: Thu, 19 Jun 2008 11:12:12 +0200

On Thu, 2008-06-19 at 04:36 -0400, Tristan Gingold wrote:
> On Jun 19, 2008, at 3:36 AM, Julian Seward wrote:
> 
> >
> >>> addme   00000000 XER.CA=1  = 00000000 (cr 00000000 xer 20000000)
> >>
> >> Did I miss the obvious, but why does 0 + 1 - 1 generate a carry ?
> >
> > Because (as per the docs) it's computing rA + XER.CA + 0xFFFF_FFFF,
> > which is 0 + 1 + 0xFFFF_FFFF == 0x1_0000_0000.  Which does indeed
> > carry.  I tested now on both a 7447 and a G5 and they both do that.
> 
> Ok thanks.  So addme set the carry unless both xer.ca and rA are 0.
> 
> Your expression is a little bit complex, especially the second part.
> If xer_ca = 1 then res == argL, right ?

OK, then I found the faulty change (from me) and reverting it should do
the trick and fix addme and subfme in 32 and 64 bits cases. I also added
some missing casts for addmeo. The fix is quite simple: the carry should
never be reseted by those instructions as xer_ca == 1 will always lead
to set the carry with the result (T0 + 1 -1 is always equal to T0,
whatever T0 value...)

For the mullw(o) issue, I guess the mullw seems faulty too, as it should
produce a 64 bits signed result when running in 64 bits mode. And I
guess this part of your patch is useless as res is already an int64_t :
-    if (likely((int32_t)res == res)) {
+    if (likely( ((int64_t)(int32_t)res) == ((int64_t)res) )) {
.
Can you confirm ?

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

Attachment: addme_subfme.diff
Description: Text Data


reply via email to

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