Michael means about scary conflicts. The code
in the 1.4 branch looks different from both the code at the time the
patch was submitted and the code at the time the patch was applied.
Here's one fix, but maybe Aurelien has a better idea.
Richard
>From 61b79e34bc57df0aa0c8086bd86f4c8818618d0e
6th, 2013. If we are unable to confirm
> relicense from an author, changes from that author will be reverted.
Acked-by: Richard Sandiford
Richard
Turn MADD.fmt, MSUB.fmt, NMADD.fmt and NMSUB.fmt from fused to unfused
operations, so that they behave in the same way as a separate multiplication
and addition. The instructions were only fused in early MIPS IV processors.
Signed-off-by: Richard Sandiford
---
target-mips/op_helper.c | 25
Richard Sandiford writes:
> BTW, I'm not sure it's right to be using *_muladd for MIPS. MADD.fmt &
> co. were fused operations in the early MIPS IV processors, but they've
> had an intermediate rounding step since then (i.e. they're equivalent
> to a separat
Honour float_muladd_negate_c in the case where the product is zero and
c is nonzero. Previously we would fail to negate c.
Seen in (and tested against) the gfortran testsuite on MIPS.
Signed-off-by: Richard Sandiford
---
fpu/softfloat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Peter Maydell writes:
> On 21 January 2013 21:32, Richard Sandiford
> wrote:
>> Honour float_muladd_negate_c in the case where the product is zero and
>> c is nonzero. Previously we would fail to negate c.
>>
>> Seen in (and tested against) the gfortran testsuit
BTW, I'm not sure it's right to be using *_muladd for MIPS. MADD.fmt &
co. were fused operations in the early MIPS IV processors, but they've
had an intermediate rounding step since then (i.e. they're equivalent
to a separate multiplication and addition). I'm not feeling brave
enough to tackle th
Honour float_muladd_negate_c in the case where the product is zero and
c is nonzero. Previously we would fail to negate c.
Seen in (and tested against) the gfortran testsuite on MIPS.
Signed-off-by: Richard Sandiford
---
fpu/softfloat.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
nt field (bits 14 and 15).
Passing the accumulator register is probably an over-generalisation
for division and 64-bit multiplication, which never access anything
other than HI and LO, and which always pass 0 as the new argument.
Separating them felt a bit fussy though.
Signed-off-by: Richard S
Make RESTORE use sign-extending rather than zero-extending loads.
Signed-off-by: Richard Sandiford
---
target-mips/translate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 47528d7..623edd0 100644
--- a/target-mips
seems easier to implement.
Previously the code used:
(oldval & (0xfffe << (31 - bitshift))) | (newval >> bitshift)
which zeroed the upper bits of the register, losing any previous sign
extension in the unaligned cases.
Signed-off-by: Richard Sandiford
---
target-mips
nt field (bits 14 and 15).
Passing the accumulator register is probably an over-generalisation
for division and 64-bit multiplication, which never access anything
other than HI and LO, and which always pass 0 as the new argument.
Separating them felt a bit fussy though.
Signed-off-by: Richard S
The FS input to CVT.PS.S is the high half and FT is the low half.
tcg_gen_concat_i32_i64 takes the low half first, so the operands
were in the wrong order.
Signed-off-by: Richard Sandiford
---
target-mips/translate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a
Read the second input operand of RECIP2.S and RECIP2.PS from FT rather
than FD. RECIP2.D is already correct.
Signed-off-by: Richard Sandiford
---
target-mips/translate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-mips/translate.c b/target-mips
There's some dodgy application of De Morgan's law in the emulation
of the MIPS BC1ANY[24]F instructions: they end up branching only
if all CCs are false, rather than if one CC is.
Tested on mips64-linux-gnu, where it fixes the GCC MIPS3D tests.
Signed-off-by: Richard Sandiford
---
t
Thiemo Seufer <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> What should the patch do instead for MIPS IV? Enable them unconditionally?
>
> Given that it is currently theoretical, as the only MIPS IV CPU
> supported is the VR5432: Add a comment to the MIPS
Thiemo Seufer <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> All MIPS COP1X instructions currently require the FPU to be in 64-bit
>> mode. My understanding is that this is too restrictive, and that the
>> base conditions are different for different revision
All MIPS COP1X instructions currently require the FPU to be in 64-bit
mode. My understanding is that this is too restrictive, and that the
base conditions are different for different revisions of the ISA:
MIPS IV:
COP1X instructions are available when the XX (CU3) bit of the
status regi
MIPS64R2-generic implements the MIPS-3D ASE, so I assume it should
also have a 64-bit FPU. Please apply if OK.
Richard
Index: target-mips/translate_init.c
===
RCS file: /sources/qemu/qemu/target-mips/translate_init.c,v
retrieving re
[Sorry if this is a dup. Wasn't sure if the list was subscribers-only.]
Running the libjava testsuite for -mabi=64 on a x86_64-linux-gnu-x-mips64
QEMU causes the emulator to exit with an FPE. The problem is that we use
lldiv for ddiv, and lldiv is undefined for both divisions by zero and for
div
Running the libjava testsuite for -mabi=64 on a x86_64-linux-gnu-x-mips64
QEMU causes the emulator to exit with an FPE. The problem is that we use
lldiv for ddiv, and lldiv is undefined for both divisions by zero and for
divisions whose result is not representable. We special-case divisions
in th
21 matches
Mail list logo
