This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Support VU0 on MIPS R5900
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Jürgen Urban <JuergenUrban at gmx dot de>, <binutils at sourceware dot org>
- Date: Thu, 1 Aug 2013 14:54:10 +0100
- Subject: Re: [PATCH] Support VU0 on MIPS R5900
- References: <20130108234130 dot 27410 at gmx dot net> <87a9rrso6l dot fsf at talisman dot default> <trinity-c3dc44a3-27c5-482b-b113-ca0cae29d590-1375046137093 at 3capp-gmx-bs55> <87mwp39mfo dot fsf at talisman dot default>
On Wed, 31 Jul 2013, Richard Sandiford wrote:
> I'm close to finishing a series of patches to further rework the opcode
> table and free up more bits.
Thanks for this work, I look forward to seeing your change in. This will
hopefully let us make GAS handle delay-slot scheduling optimally for the
microMIPS instructions I had to pessimise due to the lack of free pinfo
bits (i.e. ALNV.PS, and the instructions using the INSN2_MOD_* macros).
In fact, to avoid missing ALNV.PS, would the change below be OK to apply,
i.e. does it not conflict/interfere with your impending rework?
I chose to refer to the register field as "rr" following Figure 4.2
"32-Bit Instruction Formats" from "MIPS Architecture for Programmers,
Volume II-B: The microMIPS64 Instruction Set" (doc #MD00594, rev. 3.06),
that refers to that field as "rr/fr" even though the description of
ALNV.PS itself uses "rs" instead. I think for instruction decoding
purposes, such as done by libopcodes, it makes sense to keep register
fields names consistent across all the instructions that make use of them,
even if individual instruction descriptions in architecture documentation
make use of different names, presumably for clarity. While no other
instruction uses that field in the "rr" sense, a couple does do it in the
"fr" sense, including their detailed descriptions, and that IMHO makes the
use of "rr" here consistent with the remaining register fields referred by
Figure 4.2, i.e. "rt/ft", "rs/fs" and "rd/fd".
No regressions in mips-linux-gnu testing.
2013-08-01 Maciej W. Rozycki <macro@codesourcery.com>
opcodes/
* micromips-opc.c (RD_r): New macro.
(micromips_opcodes): Use it for "alnv.ps", replacing NODS.
Maciej
binutils-umips-opcodes-alnv.diff
Index: binutils-fsf-trunk-quilt/opcodes/micromips-opc.c
===================================================================
--- binutils-fsf-trunk-quilt.orig/opcodes/micromips-opc.c 2013-07-25 01:01:40.000000000 +0100
+++ binutils-fsf-trunk-quilt/opcodes/micromips-opc.c 2013-08-01 14:25:43.538693623 +0100
@@ -216,6 +216,7 @@ decode_micromips_operand (const char *p)
#define RD_s INSN_READ_GPR_S
#define RD_b INSN_READ_GPR_S
#define RD_t INSN_READ_GPR_T
+#define RD_r INSN_NO_DELAY_SLOT /* No flag available for rr. */
#define RD_T INSN_READ_FPR_T
#define RD_S INSN_READ_FPR_S
#define RD_R INSN_READ_FPR_R
@@ -332,7 +333,7 @@ const struct mips_opcode micromips_opcod
{"addu", "t,r,I", 0, (int) M_ADDU_I, INSN_MACRO, 0, I1, 0, 0 },
/* We have no flag to mark the read from "y", so we use NODS to disable
delay slot scheduling of ALNV.PS altogether. */
-{"alnv.ps", "D,V,T,y", 0x54000019, 0xfc00003f, NODS|WR_D|RD_S|RD_T|FP_D, 0, I1, 0, 0 },
+{"alnv.ps", "D,V,T,y", 0x54000019, 0xfc00003f, WR_D|RD_S|RD_T|RD_r|FP_D, 0, I1, 0, 0 },
{"and", "mf,mt,mg", 0x4480, 0xffc0, 0, WR_mf|RD_mf|RD_mg, I1, 0, 0 },
{"and", "mf,mg,mx", 0x4480, 0xffc0, 0, WR_mf|RD_mf|RD_mg, I1, 0, 0 },
{"and", "d,v,t", 0x00000250, 0xfc0007ff, WR_d|RD_s|RD_t, 0, I1, 0, 0 },