qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Aurelien Jarno <aurelien@aurel32.net>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] tcg/mips: detect available host instructions at runtime
Date: Thu, 15 Aug 2013 19:38:16 +0200	[thread overview]
Message-ID: <20130815173816.GA10106@ohm.aurel32.net> (raw)
In-Reply-To: <alpine.DEB.1.10.1308151727230.8514@tp.orcam.me.uk>

On Thu, Aug 15, 2013 at 05:52:55PM +0100, Maciej W. Rozycki wrote:
> On Thu, 15 Aug 2013, Aurelien Jarno wrote:
> 
> > +    /* Probe for MIPS32 instructions. As no subsetting is allowed
> > +       by the specification, it is only necessary to probe for one
> > +       of the instructions. */
> > +#ifndef use_mips32_instructions
> > +    got_sigill = 0;
> > +    asm volatile(".set push\n"
> > +                 ".set mips32\n"
> > +                 "mult $zero, $zero\n"
> > +                 ".set pop\n"
> > +                 : : : );
> > +    use_mips32_instructions = !got_sigill;
> > +#endif
> 
>  Are you sure?  MULT is an ISA I instruction.  Perhaps you meant the 
> three-argument MUL?  But that might be slightly usafe as a MIPS32 ISA 
> detector because that instruction was also implemented on the earlier NEC 
> Vr5500 chips.  By the look at opcodes/mips-opc.c in binutils Vr5500 chips 
> implement most, but not all MIPS32 ISA instructions.  So the question is 
> -- how close the host has to be?

It's indeed a typo. It should be MUL and no MULT. 

>  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.

>  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.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

  reply	other threads:[~2013-08-15 17:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-15 15:58 [Qemu-devel] [PATCH 1/2] tcg/mips: detect available host instructions at runtime Aurelien Jarno
2013-08-15 15:58 ` [Qemu-devel] [PATCH 2/2] tcg/mips: only enable ext8s/ext16s ops on MIPS32R2 Aurelien Jarno
2013-08-15 16:52 ` [Qemu-devel] [PATCH 1/2] tcg/mips: detect available host instructions at runtime Maciej W. Rozycki
2013-08-15 17:38   ` Aurelien Jarno [this message]
2013-08-15 17:59     ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130815173816.GA10106@ohm.aurel32.net \
    --to=aurelien@aurel32.net \
    --cc=macro@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).