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
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
6th, 2013. If we are unable to confirm
> relicense from an author, changes from that author will be reverted.
Acked-by: Richard Sandiford
Richard
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
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
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
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
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
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
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
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
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
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
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
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
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
[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
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
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
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
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
21 matches
Mail list logo
