https://sourceware.org/bugzilla/show_bug.cgi?id=26051
Jim Wilson <wilson at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2020-06-01
CC| |wilson at gcc dot gnu.org
--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
+@itemx I type for loads: .insn i opcode, func3, rd, simm12(rs1)
The .insn parsing code doesn't know whether we have a load or not, so this
syntax is actually valid both for loads and non-loads, likewise with the other
syntax. We should include this line, but I think the "for loads" part should
be dropped. None of the other descriptions have similar text mentioning
instruction type.
+@item S type: .insn s opcode, func3, rs2, simm12(rs1)
This looks right. For completeness we might want an alternate syntax that
accepts rs1 and simm12 as separate operands, as someone might want to use the S
type for a non-store, but no one has asked for that so I'm not worrying about
that for now.
+@item SB type: .insn sb opcode, func3, rs1, rs2, symbol
+@itemx SB type: .insn sb opcode, func3, rs1, rs2, simm12
+@itemx B type: .insn b opcode, func3, rs1, rs2, symbol
+@itemx B type: .insn b opcode, func3, rs1, rs1, simm12
The .insn parsing code doesn't allow the simm12 syntax here. Only pc-relative
symbols. So these lines should be dropped. You are right about changing the
regs from rd/rs1 to rs1/rs2. There is a typo on the last line with two rs1s,
but that line needs to be dropped anyways. Since we are modifying this, I
think we should promote B to @item and demote SB to @itemx, as B is the current
name and SB is the old name for this insn format.
Similarly we should promote J and demote UJ.
This patch is small enough and obvious enough that I believe we can accept it
without a copyright assignment. In general, if you want to contribute to GNU
packages, you need to go through the copyright assignment paperwork.
Otherwise, it is better to describe the change you want rather than send a
patch.
--
You are receiving this mail because:
You are on the CC list for the bug.
