summaryrefslogtreecommitdiff
path: root/opcodes/arc-opc.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2016-03-28 17:08:29 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2016-04-07 18:36:09 +0100
commit1328504b287b2c284419d989e0d05e7d6d3ffa59 (patch)
tree45a264789dd04357b0f0509139786c9e6ee368a7 /opcodes/arc-opc.c
parentb9b47ab79f7c3de0537cacfac061560d5811a84a (diff)
downloadbinutils-gdb-1328504b287b2c284419d989e0d05e7d6d3ffa59.tar.gz
gas/arc: Handle multiple arc_opcode chains for same mnemonic
This commit completes support for having multiple instructions with the same mnemonic in non-contiguous blocks within the arc_opcodes table. The commit adds an iterator mechanism for the arc_opcode_hash_entry structure, which is then used in find_opcode_match to consider all arc_opcode entries with the same mnemonic, even when these instructions are stored in non-contiguous blocks. I extend the comment on the arc_opcodes table to discuss how entries within the table are organised, and to mention how instructions can be split into multiple groups if needed, but that the table is still searched in table order. There should be no user visible changes after this commit. gas/ChangeLog: * config/tc-arc.c (struct arc_opcode_hash_entry_iterator): New structure. (arc_opcode_hash_entry_iterator_init): New function. (arc_opcode_hash_entry_iterator_next): New function. (find_opcode_match): Iterate over all arc_opcode entries referenced by the arc_opcode_hash_entry passed in as a parameter. opcodes/ChangeLog: * arc-opc.c (arc_opcodes): Extend comment to discus table layout.
Diffstat (limited to 'opcodes/arc-opc.c')
-rw-r--r--opcodes/arc-opc.c32
1 files changed, 31 insertions, 1 deletions
diff --git a/opcodes/arc-opc.c b/opcodes/arc-opc.c
index f1823188652..69c65fc017e 100644
--- a/opcodes/arc-opc.c
+++ b/opcodes/arc-opc.c
@@ -1453,7 +1453,37 @@ const unsigned arc_NToperand = FKT_NT;
The format of the opcode table is:
- NAME OPCODE MASK CPU CLASS SUBCLASS { OPERANDS } { FLAGS }. */
+ NAME OPCODE MASK CPU CLASS SUBCLASS { OPERANDS } { FLAGS }.
+
+ The table is organised such that, where possible, all instructions with
+ the same mnemonic are together in a block. When the assembler searches
+ for a suitable instruction the entries are checked in table order, so
+ more specific, or specialised cases should appear earlier in the table.
+
+ As an example, consider two instructions 'add a,b,u6' and 'add
+ a,b,limm'. The first takes a 6-bit immediate that is encoded within the
+ 32-bit instruction, while the second takes a 32-bit immediate that is
+ encoded in a follow-on 32-bit, making the total instruction length
+ 64-bits. In this case the u6 variant must appear first in the table, as
+ all u6 immediates could also be encoded using the 'limm' extension,
+ however, we want to use the shorter instruction wherever possible.
+
+ It is possible though to split instructions with the same mnemonic into
+ multiple groups. However, the instructions are still checked in table
+ order, even across groups. The only time that instructions with the
+ same mnemonic should be split into different groups is when different
+ variants of the instruction appear in different architectures, in which
+ case, grouping all instructions from a particular architecture together
+ might be preferable to merging the instruction into the main instruction
+ table.
+
+ An example of this split instruction groups can be found with the 'sync'
+ instruction. The core arc architecture provides a 'sync' instruction,
+ while the nps instruction set extension provides 'sync.rd' and
+ 'sync.wr'. The rd/wr flags are instruction flags, not part of the
+ mnemonic, so we end up with two groups for the sync instruction, the
+ first within the core arc instruction table, and the second within the
+ nps extension instructions. */
const struct arc_opcode arc_opcodes[] =
{
#include "arc-tbl.h"