qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target-mips: remove wrong checks for recip.fmt


From: Petar Jovanovic
Subject: Re: [Qemu-devel] [PATCH] target-mips: remove wrong checks for recip.fmt and rsqrt.fmt
Date: Wed, 26 Aug 2015 00:40:17 +0200

-----Original Message-----
From: Leon Alrae [mailto:address@hidden 
Sent: Tuesday, August 25, 2015 7:58 PM
To: Petar Jovanovic <address@hidden>; address@hidden
Cc: address@hidden; address@hidden
Subject: Re: [Qemu-devel] [PATCH] target-mips: remove wrong checks for
recip.fmt and rsqrt.fmt

On 18/08/2015 18:35, Petar Jovanovic wrote:
> From: Petar Jovanovic <address@hidden>
> 
> Instructions recip.{s|d} and rsqrt.{s|d} do not require 64-bit FPU 
> neither they require any particular mode for its FPU. This patch 
> removes the checks that may break a program that uses these instructions.

> This seems to be correct starting from MIPS32R2, but I'm not sure about
older cores. Do we really want to remove the restrictions for them as well?

IMHO, this restriction is wrong. So, yes, I believe we should remove it.
Whether we need to add a different restriction is a good question, but I am
inclined to think we may not need any here.

> @@ -9839,7 +9837,6 @@ static void gen_farith (DisasContext *ctx, enum
fopcode op1,
>          opn = "movn.d";
>          break;
>      case OPC_RECIP_D:
> -        check_cp1_64bitmode(ctx);

> I think this needs check_cp1_registers() now, i.e. check for odd fpu
register access when Status.FR = 0.

This would raise a "reserved instruction" exception. I am not aware that any
MIPS CPU implementation would throw an exception for e.g. "recip.d
$f21,$f11" (let me know if that is not the case), and I do not think MIPS
documentation obliges us to throw an exception either.

We may do that to make this irregular case more transparent though.

Regards,
Petar




reply via email to

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