From: "Maciej W. Rozycki" <macro@imgtec.com>
To: <binutils@sourceware.org>
Subject: [committed] MIPS16: Remove "extended" BREAK/SDBBP handling
Date: Fri, 23 Dec 2016 21:15:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.00.1612201319230.6743@tp.orcam.me.uk> (raw)
Remove special casing for the `6' operand code used for the embedded
trap code of the BREAK and the SDBBP instructions to support supposedly
extended forms of these instructions.
According to all versions of the MIPS16 ASE specifications these
instructions are not extensible [1][2][3][4][5][7][8][10][11], and as
from revision 2.50 of the MIPS16e ASE specifications it has been further
clarified what was previously implied, that non-extesiable instructions
when preceded with an EXTEND prefix must cause a Reserved Instruction
exception [5][6][9][10].
Therefore supposedly extended BREAK and SDBBP instructions do not serve
their purpose anymore as they do not cause a Bp and a Debug exception
respectively and supporting these forms in disassembly only causes
confusion.
References:
[1] "Product Description, MIPS16 Application-Specific Extension",
Version 1.3, MIPS Technologies, Inc., 970130, Table 3. "MIPS16
Instruction Set Summary", p. 5
[2] same, Table 5 "RR Minor Opcodes (RR-type instructions)", p.10
[3] same, Table 18. "Extendable MIPS16 Instructions", p. 24
[4] "MIPS32 Architecture for Programmers, Volume IV-a: The MIPS16e
Application-Specific Extension to the MIPS32 Architecture", MIPS
Technologies, Inc., Document Number: MD00076, Revision 2.63, July
16, 2013, Table 3.8 "MIPS16e Special Instructions", p. 38
[5] same, Section 3.11 "MIPS16e Extensible Instructions, p. 41
[6] same, Table 3.15 "MIPS16e Extensible Instructions", p. 41
[7] same, Table 3.24 "MIPS16e RR Encoding of the Funct Field", p. 49
[8] "MIPS64 Architecture for Programmers, Volume IV-a: The MIPS16e
Application-Specific Extension to the MIPS64 Architecture", MIPS
Technologies, Inc., Document Number: MD00077, Revision 2.60, June
25, 2008, Table 1.8 "MIPS16e Special Instructions", p. 39
[9] same, Section 1.11 "MIPS16e Extensible Instructions", p. 42
[10] same, Table 1.15 "MIPS16e Extensible Instructions", pp. 42-43
[11] same, Table 1.24 "MIPS16e RR Encoding of the Funct Field", p. 50
gas/
* config/tc-mips.c (match_mips16_insn): Remove the `6' operand
code special case and its associated comment.
opcodes/
* mips16-opc.c (decode_mips16_operand) <'6'>: Remove extended
encoding support.
---
binutils-mips16-opcode-format-6.diff
Index: binutils/gas/config/tc-mips.c
===================================================================
--- binutils.orig/gas/config/tc-mips.c 2016-12-16 01:00:34.865811996 +0000
+++ binutils/gas/config/tc-mips.c 2016-12-16 03:31:53.423098944 +0000
@@ -8188,14 +8188,7 @@ match_mips16_insn (struct mips_cl_insn *
if (!operand)
abort ();
- /* '6' is a special case. It is used for BREAK and SDBBP,
- whose operands are only meaningful to the software that decodes
- them. This means that there is no architectural reason why
- they cannot be prefixed by EXTEND, but in practice,
- exception handlers will only look at the instruction
- itself. We therefore allow '6' to be extended when
- disassembling but not when assembling. */
- if (operand->type != OP_PCREL && c != '6')
+ if (operand->type != OP_PCREL)
{
ext_operand = decode_mips16_operand (c, TRUE);
if (operand != ext_operand)
Index: binutils/opcodes/mips16-opc.c
===================================================================
--- binutils.orig/opcodes/mips16-opc.c 2016-12-16 01:00:34.964660479 +0000
+++ binutils/opcodes/mips16-opc.c 2016-12-16 03:31:53.509611972 +0000
@@ -50,6 +50,7 @@ decode_mips16_operand (char type, bfd_bo
switch (type)
{
case '0': MAPPED_REG (0, 0, GP, reg_0_map);
+ case '6': UINT (6, 5);
case 'L': SPECIAL (6, 5, ENTRY_EXIT_LIST);
case 'M': SPECIAL (7, 0, SAVE_RESTORE_LIST);
@@ -81,7 +82,6 @@ decode_mips16_operand (char type, bfd_bo
case '4': SINT (15, 0);
case '5': SINT (16, 0);
- case '6': SINT (16, 0);
case '8': SINT (16, 0);
case 'A': PCREL (16, 0, TRUE, 0, 2, FALSE, FALSE);
@@ -109,7 +109,6 @@ decode_mips16_operand (char type, bfd_bo
case '4': SINT (4, 0);
case '5': UINT (5, 0);
- case '6': UINT (6, 5);
case '8': UINT (8, 0);
case 'A': PCREL (8, 0, FALSE, 2, 2, FALSE, FALSE);
reply other threads:[~2016-12-23 21:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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.DEB.2.00.1612201319230.6743@tp.orcam.me.uk \
--to=macro@imgtec.com \
--cc=binutils@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).