Hi,

This fix looks good and reasonable.  Besides, since it looks quite an
institute and a small document fix, I think it should be fine to commit for
now.

If you are interesting in further contributions, then it would be great and
convenient if you have the GNU copyright assignment.  Please see the
details as follow,

https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=tree;f=doc/Copyright

You can fill one of them (probably, seem like all three look the same ),
and then send it to assign@gnu.org, to get your copyright assignment.


Thanks

Nelson

On Mon, May 27, 2024 at 1:45 AM Javier Mora <cousteaulecommandant@gmail.com>
wrote:

> 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]`.


The simm20[19:0] is correct if the immediate is a constant.  If the
immediate is symbol/label, then with the use of
%hi/%pcrel_hi/%got_pcrel_hi/... will give you simm[31:12] of the symbol,
but that will also generate the corresponding relocation
R_RISCV_HI20/PCREL_HI20/GOT_PCREL_HI20/... for the instruction.


> > 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.
>

I can just apply the patch, not sure what happened.