qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [2.4 PATCH] target-mips: add Config5.FRE support allowi


From: James Hogan
Subject: Re: [Qemu-devel] [2.4 PATCH] target-mips: add Config5.FRE support allowing Status.FR=0 emulation
Date: Tue, 17 Mar 2015 15:08:58 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 17/03/15 13:08, Leon Alrae wrote:
> Hi James,
> 
> On 17/03/2015 10:55, James Hogan wrote:
>> Hi Leon,
>>
>> On 17/03/15 09:56, Leon Alrae wrote:
>>> +    case 5:
>>> +        /* FRE Support - clear Config5.FRE bit */
>>> +        if (!((env->active_fpu.fcr0 & (1 << FCR0_FREP)) && (rt == 0))) {
>>> +            return;
>>> +        }
>>
>> If rt != 0, is it really desired for a Config5 bit (which is privileged
>> state) to be modified? Assuming these behave similarly to UFR/UNFR, the
>> behaviour is architecturally UNPREDICTABLE when rt != $0, not UNDEFINED
>> (and at least UNFR is required to produce an RI exception in r5
>> implementations).
> 
> Hmm, I believe the code above is correct and is doing exactly what you
> described :) Note that "&& (rt == 0)" is inside parenthesis following
> the logical NOT operator. It is no-op if rt != 0.

Yep, my apologies. Stupid brackets :-).

>>>  /* Floating point register moves. */
>>> -static void gen_load_fpr32(TCGv_i32 t, int reg)
>>> +static void gen_load_fpr32(DisasContext *ctx, TCGv_i32 t, int reg)
>>>  {
>>> +    if (ctx->hflags & MIPS_HFLAG_FRE) {
>>> +        generate_exception(ctx, EXCP_RI);
>>
>> Maybe return to avoid generating dead code?
> 
> The reason is to avoid leaving the TCG temp marked as TEMP_VAL_DEAD
> which would cause assertion failures in TCG as we still generate code
> using this temp after returning from gen_load_fpr().

Okay, fair enough.

Cheers
James

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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