qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 20/40] Add vs{l,r} instructions.


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH 20/40] Add vs{l,r} instructions.
Date: Mon, 5 Jan 2009 20:27:30 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Jan 05, 2009 at 10:29:56AM -0800, Nathan Froyd wrote:
> On Sat, Jan 03, 2009 at 10:26:55PM +0100, Aurelien Jarno wrote:
> > On Tue, Dec 30, 2008 at 07:10:02PM -0800, Nathan Froyd wrote:
> > > +#define VSHIFT(suffix, leftp)                                           \
> > > +    void helper_vs##suffix (ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)   \
> > > +    {                                                                   \
> > > +        int shift = b->u8[LO_IDX*0x15] & 0x7;                           \
> > > +        int doit = 1;                                                   \
> > > +        int i;                                                          \
> > > +        for (i = 0; i < ARRAY_SIZE(r->u8); i++) {                       \
> > > +            doit = doit && ((b->u8[i] & 0x7) == shift);                 \
> > > +        }                                                               \
> > 
> > According to the specification, the result is undefined in that case. I
> > think that always doing the computation is fine.
> 
> FWIW, doing the check has the nice property of delivering the same
> results as real hardware.  If you're using a comparison program like
> ppctester, reducing those spurious failures is a win.  (There's already
> spurious failures for div instructions in corner cases.)

Then I am fine with that. Could you please just add a comment that it is
not necessary according to the spec, but done to match real hardware?

-- 
  .''`.  Aurelien Jarno             | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   address@hidden         | address@hidden
   `-    people.debian.org/~aurel32 | www.aurel32.net




reply via email to

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