Skip to contentSkip to conversation

target-alpha: squashed fpu qualifiers patch

PATCH New Richard Henderson 5 participants 18 messages Dec 18, 2009 – Feb 28, 2010

lore
Share & tools
lore

Richard Henderson

author
#0 lore raw

PATCH 1/1 target-alpha: squashed fpu qualifiers patch

This is a squashed version of the 3 or 4 incremental patches that I had sent out for implementing the alpha fpu instruction qualifiers.

r~

commit 572164702dd83955fc8783c85811ec86c3fb6e4a

Author: Richard Henderson <[email protected]>
Date:   Fri Dec 18 10:50:32 2009 -0800

target-alpha: Implement fp insn qualifiers.

Adds a third constant argument to the fpu helpers, which contain the unparsed qualifier bits. The helper functions use new begin_fp/end_fp routines that extract the rounding mode from the qualifier bits, as well as raise exceptions for non-finite inputs and outputs also as directed by the qualifier bits.

cpu_alpha_load/store_fpcr modified to load/store the majority of the bits from env->fpcr. This because we hadn't been saving a few of the fpcr bits in the fp_status field: in particular DNZ.

Re-implement cvttq without saturation of overflow results, to match the Alpha specification.

Signed-off-by Richard Henderson <[email protected]>
target-alpha/cpu.h +7 -3
index c0dff4b..c1c0470 100644
@@ -430,9 +430,13 @@ enum {
 };
 
 /* Arithmetic exception */
-enum {
-    EXCP_ARITH_OVERFLOW,
-};
+#define EXC_M_IOV	(1<<16)		/* Integer Overflow */
+#define EXC_M_INE	(1<<15)		/* Inexact result */
+#define EXC_M_UNF	(1<<14)		/* Underflow */
+#define EXC_M_FOV	(1<<13)		/* Overflow */
+#define EXC_M_DZE	(1<<12)		/* Division by zero */
+#define EXC_M_INV	(1<<11)		/* Invalid operation */
+#define EXC_M_SWC	(1<<10)		/* Software completion */
 
 enum {
     IR_V0   = 0,
target-alpha/helper.c +15 -35

74 lines not on this page · raw message

target-alpha/helper.h +30 -30

78 lines not on this page · raw message

target-alpha/op_helper.c +496 -89

906 lines not on this page · raw message

target-alpha/translate.c +138 -110

397 lines not on this page · raw message

author
#1 lore raw

cover target-alpha: fpu qualifiers, round 2

I've split up the FPCR as requested by Aurelien. We no longer set anything in FP_STATUS after the execution of the operation, only copy data from FP_STATUS to some env->fpcr field.

I have totally rewritten the patch to be more along the line that Laurent was suggesting, in that the rounding mode and other qualifiers are totally parsed within the translator. I no longer pass the FN11 field to the helper functions.

Unlike Laurent's prototype, I do not set the rounding mode at every FP instruction; I remember the previous setting of the rounding mode within a TB. Similarly for the flush-to-zero field.

I do not handle VAX instructions at all. The existing VAX support is mostly broken, and I didn't feel like compounding the problem.

r~

--
Richard Henderson (6):
target-alpha: Fix gdb access to fpcr and unique.
target-alpha: Split up FPCR value into separate fields.
target-alpha: Reduce internal processor registers for user-mode.
target-alpha: Clean up arithmetic traps.
target-alpha: Mark helper_excp as NORETURN.
target-alpha: Implement IEEE FP qualifiers.

author
#2 lore raw

PATCH 2/6 target-alpha: Split up FPCR value into separate fields.

The fpcr_exc_status, fpcr_exc_mask, and fpcr_dyn_round fields are stored in <softfloat.h> format for convenience during regular execution.

Revert the addition of float_exception_mask to float_status, added in ba0e276db4b51bd2255a5d5ff8902c70d32ade40.

Signed-off-by Richard Henderson <[email protected]>
---
 fpu/softfloat.h       |    1 -
 target-alpha/cpu.h    |   24 ++++++--
 target-alpha/helper.c |  167 +++++++++++++++++++++++++++++++++----------------
 3 files changed, 131 insertions(+), 61 deletions(-)
fpu/softfloat.h +0 -1
index 9d82694..636591b 100644
@@ -187,7 +187,6 @@ typedef struct float_status {
     signed char float_detect_tininess;
     signed char float_rounding_mode;
     signed char float_exception_flags;
-    signed char float_exception_mask;
 #ifdef FLOATX80
     signed char floatx80_rounding_precision;
 #endif
target-alpha/cpu.h +19 -5
index c0dff4b..4722415 100644
@@ -145,6 +145,10 @@ enum {
 #define FPCR_UNFD		(1ULL << 61)
 #define FPCR_UNDZ		(1ULL << 60)
 #define FPCR_DYN_SHIFT		58
+#define FPCR_DYN_CHOPPED	(0ULL << FPCR_DYN_SHIFT)
+#define FPCR_DYN_MINUS		(1ULL << FPCR_DYN_SHIFT)
+#define FPCR_DYN_NORMAL		(2ULL << FPCR_DYN_SHIFT)
+#define FPCR_DYN_PLUS		(3ULL << FPCR_DYN_SHIFT)
 #define FPCR_DYN_MASK		(3ULL << FPCR_DYN_SHIFT)
 #define FPCR_IOV		(1ULL << 57)
 #define FPCR_INE		(1ULL << 56)

@@ -341,17 +345,27 @@ struct pal_handler_t {
 
 struct CPUAlphaState {
     uint64_t ir[31];
-    float64  fir[31];
-    float_status fp_status;
-    uint64_t fpcr;
+    float64 fir[31];
     uint64_t pc;
     uint64_t lock;
     uint32_t pcc[2];
     uint64_t ipr[IPR_LAST];
     uint64_t ps;
     uint64_t unique;
-    int saved_mode; /* Used for HW_LD / HW_ST */
-    int intr_flag; /* For RC and RS */
+    float_status fp_status;
+    /* The following fields make up the FPCR, but in FP_STATUS format.  */
+    uint8_t fpcr_exc_status;
+    uint8_t fpcr_exc_mask;
+    uint8_t fpcr_dyn_round;
+    uint8_t fpcr_flush_to_zero;
+    uint8_t fpcr_dnz;
+    uint8_t fpcr_dnod;
+    uint8_t fpcr_undz;
+
+    /* Used for HW_LD / HW_ST */
+    uint8_t saved_mode;
+    /* For RC and RS */
+    uint8_t intr_flag;
 
 #if TARGET_LONG_BITS > HOST_LONG_BITS
     /* temporary fixed-point registers
target-alpha/helper.c +109 -52

188 lines not on this page · raw message

Signature · 1 line
1.6.5.2
author
#3 lore raw

PATCH 3/6 target-alpha: Reduce internal processor registers for user-mode.

In reply to Richard Henderson

The existing set of IPRs is totally irrelevant to user-mode emulation. Indeed, they most are irrelevant to implementing kernel-mode emulation, and would only be relevant to PAL-mode emulation, which I suspect that no one will ever attempt.

Reducing the set of processor registers reduces the size of the CPU state.

Signed-off-by Richard Henderson <[email protected]>
---
 linux-user/main.c        |    4 +---
 target-alpha/cpu.h       |    6 ++++++
 target-alpha/translate.c |   45 +++++++++++++++++++++++++++------------------
 3 files changed, 34 insertions(+), 21 deletions(-)
linux-user/main.c +1 -3
index a0d8ce7..91e5009 100644
@@ -3050,10 +3050,8 @@ int main(int argc, char **argv, char **envp)
         for(i = 0; i < 28; i++) {
             env->ir[i] = ((abi_ulong *)regs)[i];
         }
-        env->ipr[IPR_USP] = regs->usp;
-        env->ir[30] = regs->usp;
+        env->ir[IR_SP] = regs->usp;
         env->pc = regs->pc;
-        env->unique = regs->unique;
     }
 #elif defined(TARGET_CRIS)
     {
target-alpha/cpu.h +6 -0
index 4722415..3728d83 100644
@@ -193,6 +193,11 @@ enum {
 /* Internal processor registers */
 /* XXX: TOFIX: most of those registers are implementation dependant */
 enum {
+#if defined(CONFIG_USER_ONLY)
+    IPR_EXC_ADDR,
+    IPR_EXC_SUM,
+    IPR_EXC_MASK,
+#else
     /* Ebox IPRs */
     IPR_CC           = 0xC0,            /* 21264 */
     IPR_CC_CTL       = 0xC1,            /* 21264 */

@@ -306,6 +311,7 @@ enum {
     IPR_VPTB,
     IPR_WHAMI,
     IPR_ALT_MODE,
+#endif
     IPR_LAST,
 };
target-alpha/translate.c +27 -18

58 lines not on this page · raw message

Signature · 1 line
1.6.5.2
#4 lore raw

Re: [Qemu-devel] [PATCH 3/6] target-alpha: Reduce internal processor registers for user-mode.

Quoted 4 lines · Richard Henderson

The existing set of IPRs is totally irrelevant to user-mode emulation. Indeed, they most are irrelevant to implementing kernel-mode emulation, and would only be relevant to PAL-mode emulation, which I suspect that no one will ever attempt.

Interesting, that's the approach I used to emulate an es40 (ie full emulation of 21264). This had the advantage to be able to use the genuine ROM.

Tristan.

author
#5 lore raw

Re: [Qemu-devel] [PATCH 3/6] target-alpha: Reduce internal processor registers for user-mode.

Quoted 7 lines · Tristan Gingold
Quoted 4 lines

The existing set of IPRs is totally irrelevant to user-mode emulation. Indeed, they most are irrelevant to implementing kernel-mode emulation, and would only be relevant to PAL-mode emulation, which I suspect that no one will ever attempt.

Interesting, that's the approach I used to emulate an es40 (ie full emulation of 21264). This had the advantage to be able to use the genuine ROM.

Heh. Well, far be it for me to disuade. There's surely room for wanting to emulate at that level.

However, since (1) ROMs other than the few supported by MILO are probably not redistributable and (2) I have the sense that generic kernel stuff would go faster emulating the PALcode specification, I think there's also a reason to do it that way too.

All that said, there's currently nothing that distinguishes between anything but user-mode and system-mode.

I would be delighted to see your es40 patches...

r~

#6 lore raw

Re: [Qemu-devel] [PATCH 3/6] target-alpha: Reduce internal processor registers for user-mode.

Am 06.01.2010 um 17:29 schrieb Richard Henderson:

Quoted 1 line

since (1) ROMs other than the few supported by MILO are probably not redistributable

Tristan's trick here was to provide a way for the user to extract a non-distributable ROM. I fear the controversy of whether this should be in qemu-system-alpha or not kept the patch series from being committed.

Quoted 1 line

I would be delighted to see your es40 patches...

v4: http://lists.nongnu.org/archive/html/qemu-devel/2009-03/msg01541.html

See also http://repo.or.cz/w/qemu/es40.git

Since that series added devices necessary for system emulation I assume that parts of it need to be converted to the new qdev infrastructure.

Andreas

#7 lore raw

Re: [Qemu-devel] [PATCH 3/6] target-alpha: Reduce internal processor registers for user-mode.

Quoted 6 lines · Andreas Färber

Am 06.01.2010 um 17:29 schrieb Richard Henderson:

Quoted 1 line

since (1) ROMs other than the few supported by MILO are probably not redistributable

Tristan's trick here was to provide a way for the user to extract a non-distributable ROM. I fear the controversy of whether this should be in qemu-system-alpha or not kept the patch series from being committed.

No. This point was not discussed. It is always possible to use another ROM. I didn't continue this work because I hadn't had the time.

The ROM is indeed an issue. MILO is a possible solution, but is not available on 21264 and can only boot linux. I am not even sure it is still supported.
As I was mostly interested in Tru64 and VMS, I took the SRM way. Note that a SRM rescue files are available from hp.com site (which doesn't mean it is legal) and was already used in another es40 free emulator.

I really don't plan to write a ROM for Alpha!

Although for performance it can make sense to emulate PAL when the OS is running.

Quoted 7 lines
Quoted 1 line

I would be delighted to see your es40 patches...

v4: http://lists.nongnu.org/archive/html/qemu-devel/2009-03/msg01541.html

See also http://repo.or.cz/w/qemu/es40.git

Since that series added devices necessary for system emulation I assume that parts of it need to be converted to the new qdev infrastructure.

Right. This is not very recent.
IIRC, I could reach a bash prompt, but I don't remember which kernel (2.2 or 2.6) I use. SRM was working, as well as AlphaBIOS.
VMS bootloader crash very early. Maybe your alpha cpu fix could improve the situation. Tru64 crashed during boot. IOTLB was not supported in qemu.
Windows crashed during boot too.

Tristan.

#8 lore raw

Re: [Qemu-devel] [PATCH 3/6] target-alpha: Reduce internal processor registers for user-mode.

Am 07.01.2010 um 12:54 schrieb Tristan Gingold:

Quoted 11 lines · Andreas Färber
Quoted 7 lines

Am 06.01.2010 um 17:29 schrieb Richard Henderson:

Quoted 1 line

since (1) ROMs other than the few supported by MILO are probably not redistributable

Tristan's trick here was to provide a way for the user to extract a non-distributable ROM. I fear the controversy of whether this should be in qemu-system-alpha or not kept the patch series from being committed.

No. This point was not discussed.

I was referring to this thread:

http://lists.nongnu.org/archive/html/qemu-devel/2009-03/msg00795.html

But I see now that it was discussed on v1, not v4.

Anyway, part of the series was actually applied, just not the core es40 system emulation part.

Andreas

#9 lore raw

PATCH 1/6 target-alpha: Fix gdb access to fpcr and unique.

In reply to Richard Henderson

cpu_gdb_read/write_register need to access the fpcr via the cpu_alpha_load/store_fpcr functions.

The unique register is number 66 in the gdb remote protocol.

Signed-off-by Richard Henderson <[email protected]>
---
 gdbstub.c |   88 +++++++++++++++++++++++++++++++++++++-----------------------
 1 files changed, 54 insertions(+), 34 deletions(-)
gdbstub.c +54 -34
index 6180171..4877103 100644
@@ -1307,52 +1307,72 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t *mem_buf, int n)
 }
 #elif defined (TARGET_ALPHA)
 
-#define NUM_CORE_REGS 65
+#define NUM_CORE_REGS 67
 
 static int cpu_gdb_read_register(CPUState *env, uint8_t *mem_buf, int n)
 {
-    if (n < 31) {
-       GET_REGL(env->ir[n]);
-    }
-    else if (n == 31) {
-       GET_REGL(0);
-    }
-    else if (n<63) {
-       uint64_t val;
+    uint64_t val;
+    CPU_DoubleU d;
 
-       val = *((uint64_t *)&env->fir[n-32]);
-       GET_REGL(val);
-    }
-    else if (n==63) {
-       GET_REGL(env->fpcr);
-    }
-    else if (n==64) {
-       GET_REGL(env->pc);
-    }
-    else {
-       GET_REGL(0);
+    switch (n) {
+    case 0 ... 30:
+        val = env->ir[n];
+        break;
+    case 32 ... 62:
+        d.d = env->fir[n - 32];
+        val = d.ll;
+        break;
+    case 63:
+        val = cpu_alpha_load_fpcr(env);
+        break;
+    case 64:
+        val = env->pc;
+        break;
+    case 66:
+        val = env->unique;
+        break;
+    case 31:
+    case 65:
+        /* 31 really is the zero register; 65 is unassigned in the
+           gdb protocol, but is still required to occupy 8 bytes. */
+        val = 0;
+        break;
+    default:
+        return 0;
     }
-
-    return 0;
+    GET_REGL(val);
 }
 
 static int cpu_gdb_write_register(CPUState *env, uint8_t *mem_buf, int n)
 {
-    target_ulong tmp;
-    tmp = ldtul_p(mem_buf);
+    target_ulong tmp = ldtul_p(mem_buf);
+    CPU_DoubleU d;
 
-    if (n < 31) {
+    switch (n) {
+    case 0 ... 30:
         env->ir[n] = tmp;
+        break;
+    case 32 ... 62:
+        d.ll = tmp;
+        env->fir[n - 32] = d.d;
+        break;
+    case 63:
+        cpu_alpha_store_fpcr(env, tmp);
+        break;
+    case 64:
+        env->pc = tmp;
+        break;
+    case 66:
+        env->unique = tmp;
+        break;
+    case 31:
+    case 65:
+        /* 31 really is the zero register; 65 is unassigned in the
+           gdb protocol, but is still required to occupy 8 bytes. */
+        break;
+    default:
+        return 0;
     }
-
-    if (n > 31 && n < 63) {
-        env->fir[n - 32] = ldfl_p(mem_buf);
-    }
-
-    if (n == 64 ) {
-       env->pc=tmp;
-    }
-
     return 8;
 }
 #elif defined (TARGET_S390X)
Signature · 1 line
1.6.5.2
author
#10 lore raw

PATCH 4/6 target-alpha: Clean up arithmetic traps.

In reply to Richard Henderson

Replace the EXCP_ARITH_OVERFLOW placeholder with the complete set of bits from the EXC_SUM IPR. Use them in the existing places where we raise arithmetic exceptions.

Signed-off-by Richard Henderson <[email protected]>
---
 target-alpha/cpu.h       |   10 +++++++---
 target-alpha/op_helper.c |   12 ++++++------
 2 files changed, 13 insertions(+), 9 deletions(-)
target-alpha/cpu.h +7 -3
index 3728d83..eda1b4a 100644
@@ -450,9 +450,13 @@ enum {
 };
 
 /* Arithmetic exception */
-enum {
-    EXCP_ARITH_OVERFLOW,
-};
+#define EXC_M_IOV       (1<<16)         /* Integer Overflow */
+#define EXC_M_INE       (1<<15)         /* Inexact result */
+#define EXC_M_UNF       (1<<14)         /* Underflow */
+#define EXC_M_FOV       (1<<13)         /* Overflow */
+#define EXC_M_DZE       (1<<12)         /* Division by zero */
+#define EXC_M_INV       (1<<11)         /* Invalid operation */
+#define EXC_M_SWC       (1<<10)         /* Software completion */
 
 enum {
     IR_V0   = 0,
target-alpha/op_helper.c +6 -6
index b2abf6c..48245dd 100644
@@ -78,7 +78,7 @@ uint64_t helper_addqv (uint64_t op1, uint64_t op2)
     uint64_t tmp = op1;
     op1 += op2;
     if (unlikely((tmp ^ op2 ^ (-1ULL)) & (tmp ^ op1) & (1ULL << 63))) {
-        helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+        helper_excp(EXCP_ARITH, EXC_M_IOV);
     }
     return op1;
 }

@@ -88,7 +88,7 @@ uint64_t helper_addlv (uint64_t op1, uint64_t op2)
     uint64_t tmp = op1;
     op1 = (uint32_t)(op1 + op2);
     if (unlikely((tmp ^ op2 ^ (-1UL)) & (tmp ^ op1) & (1UL << 31))) {
-        helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+        helper_excp(EXCP_ARITH, EXC_M_IOV);
     }
     return op1;
 }

@@ -98,7 +98,7 @@ uint64_t helper_subqv (uint64_t op1, uint64_t op2)
     uint64_t res;
     res = op1 - op2;
     if (unlikely((op1 ^ op2) & (res ^ op1) & (1ULL << 63))) {
-        helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+        helper_excp(EXCP_ARITH, EXC_M_IOV);
     }
     return res;
 }

@@ -108,7 +108,7 @@ uint64_t helper_sublv (uint64_t op1, uint64_t op2)
     uint32_t res;
     res = op1 - op2;
     if (unlikely((op1 ^ op2) & (res ^ op1) & (1UL << 31))) {
-        helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+        helper_excp(EXCP_ARITH, EXC_M_IOV);
     }
     return res;
 }

@@ -118,7 +118,7 @@ uint64_t helper_mullv (uint64_t op1, uint64_t op2)
     int64_t res = (int64_t)op1 * (int64_t)op2;
 
     if (unlikely((int32_t)res != res)) {
-        helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+        helper_excp(EXCP_ARITH, EXC_M_IOV);
     }
     return (int64_t)((int32_t)res);
 }

@@ -130,7 +130,7 @@ uint64_t helper_mulqv (uint64_t op1, uint64_t op2)
     muls64(&tl, &th, op1, op2);
     /* If th != 0 && th != -1, then we had an overflow */
     if (unlikely((th + 1) > 1)) {
-        helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+        helper_excp(EXCP_ARITH, EXC_M_IOV);
     }
     return tl;
 }
Signature · 1 line
1.6.5.2
author
#11 lore raw

PATCH 5/6 target-alpha: Mark helper_excp as NORETURN.

In reply to Richard Henderson
Signed-off-by Richard Henderson <[email protected]>
---
 target-alpha/op_helper.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
target-alpha/op_helper.c +1 -1
index 48245dd..a322f12 100644
@@ -24,7 +24,7 @@
 
 /*****************************************************************************/
 /* Exceptions processing helpers */
-void helper_excp (int excp, int error)
+void QEMU_NORETURN helper_excp (int excp, int error)
 {
     env->exception_index = excp;
     env->error_code = error;
Signature · 1 line
1.6.5.2
author
#12 lore raw

PATCH 6/6 target-alpha: Implement IEEE FP qualifiers.

In reply to Richard Henderson

IEEE FP instructions are split up so that the rounding mode coming from the instruction and exceptions (both masking and delivery) are handled external to the base FP operation. FP exceptions are properly raised for non-finite inputs to instructions that do not indicate software completion.

A shortcut is applied if CONFIG_SOFTFLOAT_INLINE is defined at the top of translate.c: data is loaded and stored into FP_STATUS directly instead of using the functional interface defined by "softfloat.h".

Signed-off-by Richard Henderson <[email protected]>
---
 target-alpha/helper.h    |   21 ++-
 target-alpha/op_helper.c |  261 +++++++++++++++++++++--
 target-alpha/translate.c |  521 ++++++++++++++++++++++++++++++++++++++--------
 3 files changed, 688 insertions(+), 115 deletions(-)
target-alpha/helper.h +18 -3
index bedd3c0..79cf375 100644
@@ -83,7 +83,6 @@ DEF_HELPER_2(cpyse, i64, i64, i64)
 
 DEF_HELPER_1(cvtts, i64, i64)
 DEF_HELPER_1(cvtst, i64, i64)
-DEF_HELPER_1(cvttq, i64, i64)
 DEF_HELPER_1(cvtqs, i64, i64)
 DEF_HELPER_1(cvtqt, i64, i64)
 DEF_HELPER_1(cvtqf, i64, i64)

@@ -91,9 +90,25 @@ DEF_HELPER_1(cvtgf, i64, i64)
 DEF_HELPER_1(cvtgq, i64, i64)
 DEF_HELPER_1(cvtqg, i64, i64)
 DEF_HELPER_1(cvtlq, i64, i64)
+
+DEF_HELPER_1(cvttq, i64, i64)
+DEF_HELPER_1(cvttq_c, i64, i64)
+DEF_HELPER_1(cvttq_svic, i64, i64)
+
 DEF_HELPER_1(cvtql, i64, i64)
-DEF_HELPER_1(cvtqlv, i64, i64)
-DEF_HELPER_1(cvtqlsv, i64, i64)
+DEF_HELPER_1(cvtql_v, i64, i64)
+DEF_HELPER_1(cvtql_sv, i64, i64)
+
+DEF_HELPER_1(setroundmode, void, i32)
+DEF_HELPER_1(setflushzero, void, i32)
+DEF_HELPER_0(fp_exc_clear, void)
+DEF_HELPER_0(fp_exc_get, i32)
+DEF_HELPER_2(fp_exc_raise, void, i32, i32)
+DEF_HELPER_2(fp_exc_raise_s, void, i32, i32)
+
+DEF_HELPER_1(ieee_input, i64, i64)
+DEF_HELPER_1(ieee_input_cmp, i64, i64)
+DEF_HELPER_1(ieee_input_s, i64, i64)
 
 #if !defined (CONFIG_USER_ONLY)
 DEF_HELPER_0(hw_rei, void)
target-alpha/op_helper.c +237 -24

294 lines not on this page · raw message

target-alpha/translate.c +433 -88

650 lines not on this page · raw message

Signature · 1 line
1.6.5.2
author
#13 lore raw

Re: [Qemu-devel] [PATCH 0/6] target-alpha: fpu qualifiers, round 2

In reply to Richard Henderson

Ping?

r~

Quoted 31 lines · Richard Henderson

I've split up the FPCR as requested by Aurelien. We no longer set anything in FP_STATUS after the execution of the operation, only copy data from FP_STATUS to some env->fpcr field.

I have totally rewritten the patch to be more along the line that Laurent was suggesting, in that the rounding mode and other qualifiers are totally parsed within the translator. I no longer pass the FN11 field to the helper functions.

Unlike Laurent's prototype, I do not set the rounding mode at every FP instruction; I remember the previous setting of the rounding mode within a TB. Similarly for the flush-to-zero field.

I do not handle VAX instructions at all. The existing VAX support is mostly broken, and I didn't feel like compounding the problem.

r~

--
Richard Henderson (6):
target-alpha: Fix gdb access to fpcr and unique.
target-alpha: Split up FPCR value into separate fields.
target-alpha: Reduce internal processor registers for user-mode.
target-alpha: Clean up arithmetic traps.
target-alpha: Mark helper_excp as NORETURN.
target-alpha: Implement IEEE FP qualifiers.

author
#14 lore raw

Re: [Qemu-devel] [PATCH 0/6] target-alpha: fpu qualifiers, round 2

In reply to Richard Henderson

Ping 2.

r~

Quoted 31 lines · Richard Henderson

I've split up the FPCR as requested by Aurelien. We no longer set anything in FP_STATUS after the execution of the operation, only copy data from FP_STATUS to some env->fpcr field.

I have totally rewritten the patch to be more along the line that Laurent was suggesting, in that the rounding mode and other qualifiers are totally parsed within the translator. I no longer pass the FN11 field to the helper functions.

Unlike Laurent's prototype, I do not set the rounding mode at every FP instruction; I remember the previous setting of the rounding mode within a TB. Similarly for the flush-to-zero field.

I do not handle VAX instructions at all. The existing VAX support is mostly broken, and I didn't feel like compounding the problem.

r~

--
Richard Henderson (6):
target-alpha: Fix gdb access to fpcr and unique.
target-alpha: Split up FPCR value into separate fields.
target-alpha: Reduce internal processor registers for user-mode.
target-alpha: Clean up arithmetic traps.
target-alpha: Mark helper_excp as NORETURN.
target-alpha: Implement IEEE FP qualifiers.

#15 lore raw

Re: [Qemu-devel] [PATCH 0/6] target-alpha: fpu qualifiers, round 2

In reply to Richard Henderson
Quoted 9 lines · Richard Henderson

I've split up the FPCR as requested by Aurelien. We no longer set anything in FP_STATUS after the execution of the operation, only copy data from FP_STATUS to some env->fpcr field.

I have totally rewritten the patch to be more along the line that Laurent was suggesting, in that the rounding mode and other qualifiers are totally parsed within the translator. I no longer pass the FN11 field to the helper functions.

What's the benefit of doing that? I don't say it's wrong, I just want to understand. Otherwise the patch looks good, so it can probably be applied without any change.

In the meanwhile, I have applied patches 1 to 5.

Signature · 2 lines
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net
author
#16 lore raw

Re: [Qemu-devel] [PATCH 0/6] target-alpha: fpu qualifiers, round 2

Quoted 8 lines · Aurelien Jarno
Quoted 4 lines

I have totally rewritten the patch to be more along the line that Laurent was suggesting, in that the rounding mode and other qualifiers are totally parsed within the translator. I no longer pass the FN11 field to the helper functions.

What's the benefit of doing that? I don't say it's wrong, I just want to understand. Otherwise the patch looks good, so it can probably be applied without any change.

I seem to recall Laurent opining that doing the interpretation of the opcode in two different places was less than clean, and in the end I agree with him.

FWIW, this configuration would also be compatible with a future TCG enhancement to generate fp code, whereas the first config would not.

r~

#17 lore raw

Re: [Qemu-devel] [PATCH 0/6] target-alpha: fpu qualifiers, round 2

Quoted 10 lines · Richard Henderson
Quoted 8 lines · Aurelien Jarno
Quoted 4 lines

I have totally rewritten the patch to be more along the line that Laurent was suggesting, in that the rounding mode and other qualifiers are totally parsed within the translator. I no longer pass the FN11 field to the helper functions.

What's the benefit of doing that? I don't say it's wrong, I just want to understand. Otherwise the patch looks good, so it can probably be applied without any change.

Quoted 7 lines

I seem to recall Laurent opining that doing the interpretation of the opcode in two different places was less than clean, and in the end I agree with him.

FWIW, this configuration would also be compatible with a future TCG enhancement to generate fp code, whereas the first config would not.

I have applied the patch, but in order to avoid doing the same for all targets, it might be a good idea to directly provide TCG functions to modify FP_STATUS instead of using the interface from softfloat.h. This would also have the advantage of clearly defining this interface, and make sure that the alpha target is not broken by a change in softfloat.h.

Signature · 2 lines
Aurelien Jarno                          GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net