This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[PATCH] gas: sparc: allow ASR registers in the 0..31 range in V9 and later
- From: jose dot marchesi at oracle dot com (Jose E. Marchesi)
- To: binutils at sourceware dot org
- Date: Tue, 22 Mar 2016 13:53:11 -0700
- Subject: [PATCH] gas: sparc: allow ASR registers in the 0..31 range in V9 and later
- Authentication-results: sourceware.org; auth=none
In the V9 (and later) versions of the SPARC specification, the section
C.1.1 "Register Names" specifies that:
"asr_reg. An asr_reg is an Ancillary State Register name. It may have
one of the following values:
%asr16-%asr31"
The rationale of having this restriction was that the registers from 16
to 31 are reserved to implementations, and are therefore "non-V9". It
also assumes that the existing ASR registers in the range 0..31 will
have their own names such as %y, that can be used to access such
registers.
The Solaris assembler is lax and allows to assembly instructions
referring to %asr0 to %asr31. This patch makes the GNU assembler to
mimic that behavior.
Rationale for the change:
- When a new ASR register is introduced, such as %mcdper (%asr14), there
is a transition period when the new register name is not recognized by
the released GAS. Software developed in that period can now use
%asr14 and thus not need the latest assembler, nor ugly .byte hacks.
- This is a pure syntax issue: the instruction assembled from %asrN and
%NAME are exactly the same, and valid SPARC instructions provided N
corresponds to a valid ASR.
- The above mentioned restriction in section C.1.1 of the SPARC
specification is going to be modified in future editions to allow the
full range %asr0-%asr31 in the assembly syntax.
- The restriction, as currently implemented in GAS, doesn't work anyway:
as the `current_architecture' is bumped when instructions requiring a
later architecture are processed, in the following program only the
second `rd' instruction will trigger the error:
rd %asr14,%g1 ;; current arch is V6 => no error raised
ldx [%g1],%g1 ;; arch bumped to V9
rd %asr14,%g2 ;; error: %asr register must be in the range %asr16..%asr31
Tested in both sparcv9-*-linux-gnu and sparc64-*-linux-gnu.
No regressions.
Ok to commit?
diff --git a/gas/ChangeLog b/gas/ChangeLog
index 24cf393..9bd9682 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,8 @@
+2016-03-22 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * config/tc-sparc.c (sparc_ip): Remove the V9 restriction on ASR
+ registers to be in the 16..31 range.
+
2016-03-22 Alan Modra <amodra@gmail.com>
* write.c (record_alignment): Revert 2016-02-18 change.
diff --git a/gas/config/tc-sparc.c b/gas/config/tc-sparc.c
index cac5d18..b70c914 100644
--- a/gas/config/tc-sparc.c
+++ b/gas/config/tc-sparc.c
@@ -1841,22 +1841,11 @@ sparc_ip (char *str, const struct sparc_opcode **pinsn)
++s;
}
- if (current_architecture >= SPARC_OPCODE_ARCH_V9)
- {
- if (num < 16 || 31 < num)
- {
- error_message = _(": asr number must be between 16 and 31");
- goto error;
- }
- }
- else
- {
- if (num < 0 || 31 < num)
- {
- error_message = _(": asr number must be between 0 and 31");
- goto error;
- }
- }
+ if (num < 0 || 31 < num)
+ {
+ error_message = _(": asr number must be between 0 and 31");
+ goto error;
+ }
opcode |= (*args == 'M' ? RS1 (num) : RD (num));
continue;