[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/2] tcg/mips: detect available host instruction
From: |
Maciej W. Rozycki |
Subject: |
Re: [Qemu-devel] [PATCH 1/2] tcg/mips: detect available host instructions at runtime |
Date: |
Thu, 15 Aug 2013 18:59:43 +0100 |
User-agent: |
Alpine 1.10 (DEB 962 2008-03-14) |
On Thu, 15 Aug 2013, Aurelien Jarno wrote:
> > The MIPS32 instructions missing from Vr5500 are the EJTAG stuff (DERET
> > and SDBBP), JR.HB/JALR.HB (hmm, weird -- these are actually not guaranteed
> > to work on all MIPS32 chips either, e.g. the 4Kc didn't support these
> > encodings and trapped), SYNC, three-argument MFCx/MTCx instructions (CP0,
> > CP2, CP3 register set selection) and two-argument BC2* instructions (extra
> > CP2 condition bits).
>
> So far the only use case of detecting the MIPS32 ISA is actually to use
> MUL instead of MULT. All the others instructions not supported by the
> Vr5500 are not used by QEMU, which uses only non-privileged instructions.
> JR.HB/JALR.HB seems anyway to be supported only on MIPS32R2.
Great!
> > All it looks like pretty obscure stuff to me as far as QEMU is concerned,
> > so perhaps checking for MUL is good enough. But I'm not the QEMU expert
> > here, so I'm just raising the issue in hope that you or someone else
> > knows.
>
> The question is to know if there are other chips which implement MUL,
> but not the other MIPS32 non-privileged (and non-FPU) instructions? For
> example MOVN and MOVZ is implemented on MIPS4 and Loongson that's why
> there is another test for them.
The only other processor that supports the MIPS32 MUL instruction is the
IDT R4650 chip, but that does not have a TLB MMU and therefore I think can
be safely disregarded. It won't run Linux or any such OS.
NEC Vr5400 chips (the Vr5432 is the only variant that's been actually
taped out) support a MUL instruction that has the same semantics but a
different encoding. It shouldn't be a problem though as this assembly
piece uses .set mips32r2 and therefore the MIPS32 encoding should be
produced instead. You may want to double check it with -march=vr5400 and
a small assembly source with code extracted from this piece though.
Maciej