[PATCH v2] gas/doc: RISC-V: Fix Type U instruction

[Javier Mora]

On second thought, I just realized that all the simmN/uimmN
instructions use the bit range explicitly, even when it's contiguous
(e.g. `simm12[11:0]`, not just `simm12`).  I guess this makes sense
because certain immediates don't take the range [N-1:0] but [N:1], and
one might even think that this .insn would get bits [31:12] of the
immediate value passed in the assembly instruction, when it's actually
bits [19:0] (e.g., `.insn u CUSTOM_0, a0, 0x00042000` will actually
become `0x4200050B`, not `0x0004250B`).

Sending amended patch with the correct `simm20[19:0]`.

El vie, 24 may 2024 a las 20:45, Javier Mora
(<cousteaulecommandant@gmail.com>) escribió:
>
> The RISC-V Type U instruction (.insn u) at
> https://sourceware.org/binutils/docs/as/RISC_002dV_002dFormats.html
> shows an incorrect format for the `simm20` immediate.  The bits should
> be sequentially arranged (simm20[19:0]) which is how `gas` treats
> them, but instead they appear in the Type J format
> (simm20[20|10:1|11|19:12]) in the documentation.
> Additionally, I changed all occurrences of `opcode6` to `opcode7`
> since the opcode has 7 bits, not 6.
>
> (This is my first patch on this project, so my apologies if the format
> is not correct!)
>
> As a side note, and speaking of off-by-one errors, I don't quite like
> the bit numbering in the instructions: the numbers appear in the ASCII
> box diagrams directly under the field boundaries; they should either
> appear slightly to the left (indicating that they refer to the first
> bit of the next field) or to the right in the case of the leftmost 31;
> otherwise it becomes a little confusing (especially since the leftmost
> field appears to have one bit less).
> Alternatively, you may go full "Python style limits" and
> systematically write the index of the bit to the left of the boundary
> -- i.e., replace all those 31 with 32 (and the 30 in Type J with 31).
> Otherwise the leftmost field is "different".
> A third, more explicit but maybe too verbose option is to include both
> boundaries in every field.
>
> Thanks in advance.
> Keep up the good work!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gas-doc-RISC-V-Fix-U-insn-replace-opcode6-7.patch
Type: text/x-patch
Size: 4952 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20240526/5bfcc8f2/attachment.bin>