qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc <qemu-ppc@nongnu.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] mfocrf missing on e500v2
Date: Fri, 6 Mar 2015 17:20:58 +0000 (GMT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1503061643400.15786@eddie.linux-mips.org> (raw)
In-Reply-To: <54F9CFF5.4070800@suse.de>

On Fri, 6 Mar 2015, Alexander Graf wrote:

> I've finally managed to check out why my e500v2 automated tests fail to
> run. Apparently they break because autotest wants to execute target code
> and runs into an illegal instruction while doing that:
> 
> Program received signal SIGILL, Illegal instruction.
> 0xb57c84cc in ?? ()
> (gdb) x /i $pc
> => 0xb57c84cc:	mfocrf  r0,1
> 
> And lo and behold, I really couldn't find any reference to mfocrf in the
> e500v2 spec.

 Do real e500 processors trap on this operation as well?  Here's what 
the Power ISA [1] says on the mtocrf and mfocrf instructions:

"These forms of the mtcrf and mfcr instructions are intended to replace 
the old forms of the instructions (the forms shown in page 102), which 
will eventually be phased out of the architecture. The new forms are 
backward compatible with most processors that comply with versions of 
the architecture that precede Version 2.00.  On those processors, the 
new forms are treated as the old forms.

"However, on some processors that comply with versions of the 
architecture that precede Version 2.00 the new forms may be treated as 
follows:

mtocrf: may cause the system illegal instruction error handler to be 
        invoked

mfocrf: may place an undefined value into register RT"

So it looks to me like the ISA, for its extension, relies on partial 
instruction decoding here.

 Furthermore both the opcode and the extended opcode are the same for 
each of mtcrf/mtocrf and mfcr/mfocrf, and the instructions within these 
pairs only differ by the value of a single bit within a field used for 
RA by operations that use it.  That bit is specified as reserved (/) for 
mtcrf/mfcr by e500 processor documentation [2][3][4] and likely a "don't 
care" in real implementations.  Offhand I suspect this is what pre-2.00 
ISA revisions did too.

 So perhaps the partial decoding of mtcrf and mfcr has to be implemented 
in QEMU for the processors concerned instead then?  The answer will 
depend on what actual hardware does.

References:

[1] "Power ISA", IBM Corporation, Version 2.06 Revision B, July 23, 
    2010, Section 3.3.15.1 "Move To/From One Condition Register Field 
    Instructions", p. 103

[2] "PowerPC e500 Core Family Reference Manual", Freescale 
    Semiconductor, Document ID: E500CORERM, Rev. 1, 4/2005, Table D-1 
    "Instructions (Binary) by Mnemonic", p. D-17

[3] same, Table D-2 "Instructions (Decimal and Hexadecimal) by Opcode",
    p. D-32

[4] same, Table D-3 "Instructions (Binary) by Form", pp. D-37, D-48

  Maciej

  reply	other threads:[~2015-03-06 17:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-06 16:04 [Qemu-devel] mfocrf missing on e500v2 Alexander Graf
2015-03-06 17:20 ` Maciej W. Rozycki [this message]
2015-03-06 17:23   ` Alexander Graf
2015-03-06 17:25     ` Maciej W. Rozycki
2015-03-06 19:37 ` Richard Henderson

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=alpine.LFD.2.11.1503061643400.15786@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /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).