qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-ope


From: Aleksandar Markovic
Subject: Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU
Date: Sun, 28 Oct 2018 19:43:26 +0000

> From: Richard Henderson <address@hidden>
> Sent: Tuesday, October 16, 2018 8:37 PM
> Subject: Re: [PATCH] target/mips: Support Toshiba specific three-operand MADD 
> and MADDU
> 
> On 10/16/18 11:19 AM, Fredrik Noring wrote:
> > /* global register indices */
> > static TCGv cpu_gpr[32], cpu_PC;
> > static TCGv cpu_HI[MIPS_DSP_ACC], cpu_LO[MIPS_DSP_ACC];
> > 
> > One option is to create a new array such as
> > 
> > static TCGv_i64 mmi_gpr[32];
> > 
> > that represents the upper 64 bits of each GPR. Then cpu_gpr must be of
> > a 64-bit type too, even when QEMU runs in 32-bit user mode. The R5900
> > does not implement CP0.Status.UX in hardware, though, so system mode is
> > 64 bits, regardless.
> 
> I would not implement r5900 for mips32 in that case,
> I would implement it only for TARGET_MIPS64.
> 
> r~

Hello, Richard.

I truly need your help here. As you can conclude from the discussion, R5900 
folks (anybody correct me if I am wrong) have some problems using any ABI other 
than O32. (For example, the standard gcc switch are "-mabi=32 -march=r5900".) 
Other similar CPUs, for example R4000, are built with TARGET_MIPS64, both user 
and system mode. R5900 would not have TARGET_MIPS64 in such arrangement. This 
looks outlandish to me. Given that R5900 is a 64-bit MIPS III-like processor, 
is there any anomaly in this arrangement, or this should work and is OK?

Thanks,
Aleksandar 


reply via email to

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