qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 5/6] target-ppc: implement xxextra


From: Nikunj A Dadhania
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 5/6] target-ppc: implement xxextractuw instruction
Date: Mon, 19 Dec 2016 09:55:10 +0530
User-agent: Notmuch/0.21 (https://notmuchmail.org) Emacs/25.0.94.1 (x86_64-redhat-linux-gnu)

David Gibson <address@hidden> writes:

> [ Unknown signature status ]
> On Wed, Dec 14, 2016 at 02:14:26PM +0530, Nikunj A Dadhania wrote:
>> David Gibson <address@hidden> writes:
>> 
>> > [ Unknown signature status ]
>> > On Mon, Dec 12, 2016 at 09:31:11AM +0530, Nikunj Dadhania wrote:
>> >> On 12 December 2016 at 06:00, David Gibson <address@hidden> wrote:
>> >> > On Fri, Dec 09, 2016 at 05:47:24PM +0530, Nikunj A Dadhania wrote:
>> >> >> xxextractuw: VSX Vector Extract Unsigned Word
>> >> >>
>> >> >> Signed-off-by: Nikunj A Dadhania <address@hidden>
>> >> >> +        tcg_gen_movi_i64(cpu_vsrh(xT(ctx->opcode)), 0);         \
>> >> >> +        tcg_gen_movi_i64(cpu_vsrl(xT(ctx->opcode)), 0);         \
>> >> >> +        return;                                                 \
>> >> >
>> >> > So, I know the architecture says it is undefined.  But since you're
>> >> > testing for the bogus case anyway, why not turn this into an
>> >> > exception. That seems like it would be more helpful for debugging the
>> >> > guest than just setting the result to zero.  Or is this done to match
>> >> > actual hardware behaviour?
>> >> 
>> >> I havent had a change to run on the real hardware, but on the system
>> >> simulator, it happily
>> >> returns extracted content even if UIMM > 12.
>> >
>> > Hm.  Returns what exactly?
>> 
>> So for LE case extracting from 15 returns following, basically its
>> rounding up to 0.
>
>> xxextractuw: 15 - ooTSET a si sihT
>>                   ________ihTo____
>
> Ok.  IIRC your implementation did not do this - it set the
> "overflowed" bytes to 0 instead of wrapping round and taking them from
> the other end of the input.  If think we should either match hardware
> behaviour or simply trap here, rather than do something else.

Sure, will update and send the patch matching hardware behaviour.

Regards
Nikunj




reply via email to

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