David Gibson <da...@gibson.dropbear.id.au> writes: > [ Unknown signature status ] > On Wed, Dec 14, 2016 at 02:14:26PM +0530, Nikunj A Dadhania wrote: >> David Gibson <da...@gibson.dropbear.id.au> 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 <da...@gibson.dropbear.id.au> >> >> 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 <nik...@linux.vnet.ibm.com> >> >> >> + 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
