qemu-riscv
[Top][All Lists]
Advanced

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

Re: [Qemu-riscv] [Qemu-devel] [PATCH v4 12/35] target/riscv: Convert RV3


From: Bastian Koppelmann
Subject: Re: [Qemu-riscv] [Qemu-devel] [PATCH v4 12/35] target/riscv: Convert RV32F insns to decodetree
Date: Mon, 21 Jan 2019 10:06:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0


On 1/19/19 10:51 PM, Richard Henderson wrote:
On 1/19/19 12:14 AM, Bastian Koppelmann wrote:
+static bool trans_fsgnjn_s(DisasContext *ctx, arg_fsgnjn_s *a)
+{
+    REQUIRE_FPU;
+    if (a->rs1 == a->rs2) { /* FNEG */
+        tcg_gen_xori_i64(cpu_fpr[a->rd], cpu_fpr[a->rs1], INT32_MIN);
+    } else {
+        TCGv_i64 t0 = tcg_temp_new_i64();
+        tcg_gen_not_i64(t0, cpu_fpr[a->rs2]);
+        tcg_gen_deposit_i64(cpu_fpr[a->rd], t0, cpu_fpr[a->rs1], 0, 31);
+        tcg_temp_free_i64(t0);
+    }
+    return true;
+}
+
+static bool trans_fsgnjx_s(DisasContext *ctx, arg_fsgnjx_s *a)
+{
+    REQUIRE_FPU;
+    if (a->rs1 == a->rs2) { /* FABS */
+        tcg_gen_andi_i64(cpu_fpr[a->rd], cpu_fpr[a->rs1], ~INT32_MIN);
Not an issue with this patch set, since you are just moving existing code.

However, while I'm thinking about it:

It just occured to me that these uses of INT32_MIN are not ideal, in that they
are (signed) -0x80000000 and not 0x0000000080000000ull.

In particular, FNEG will remove the NaN-box of the 32-bit value.

Similarly with the construction of fsgnjn_s wrt not + deposit.  It might be
better to simply xor the sign bit rather than not the whole 64-bit value.

Have you tried using RISU to compare these sorts of results vs real hardware,
or spike?


No I haven't run it against spike or real hardware. My tests consist of 'does fedora still boot without errors' and running the riscv-tests.


Cheers,

Bastian




reply via email to

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