qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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