Re: RISC-V: mapping symbols vs "unimpl"

[Andrew Waterman <andrew@sifive.com>]

On Mon, Feb 14, 2022 at 12:27 AM Jan Beulich via Binutils
<binutils@sourceware.org> wrote:
>
> Nelson,
>
> with your introduction of mapping symbols I have trouble expressing
> certain spec-conforming deliberately illegal 32-bit instructions (low
> 16 bits all zero). I can't use "unimpl" itself, as that for whichever
> reason resolves to "csrrw x0, cycle, x0"

I just wanted to remark on this seemingly arbitrary choice: we chose
it because it's both architecturally guaranteed to be 32 bits wide and
architecturally guaranteed to trap.  (The CSR in question is
definitionally read-only, and writing a read-only CSR must trap.)  I
realize it's of no help to your query, but I figured it was best not
to leave this point dangling.

> (and oddly enough using that
> form as input goes through without even a warning, but that's just a
> side note). I also can't use .insn, as that places requirements on
> the low two bits of the main opcode. And now I also can't use .word
> anymore, as that will cause mapping symbols to be inserted, which
> therefore - by a disassembler honoring the mapping symbols - won't
> disassemble as an instruction anymore.
>
> Do you have any suggestion how to encode a spec-conforming "unimpl",
> which I want to be part of my own disassembler's test cases (in
> particular the 0xffff0000 form)? Since the commit introducing the
> mapping symbols refers to Arm, I'd like to point out that their .insn
> equivalents allow to encode entirely arbitrary instruction forms. But
> of course I understand that RISC-V's insn length encoding scheme is
> somewhat in conflict with this.
>
> Two further remarks: Even ".insn ci ..." cannot be used, not even for
> forms with the high 16 bits not all set (which again the main opcode
> restriction would get in the way of): Already just temporarily
> enabling RVC causes the RVC bit to be set in the ELF header flags.
> Yet with that bit set 0xffff0000 is actually a 16-bit insn 0x0000
> followed by a wider insn with the low 16 bits all set. IOW this
> conflicts with the spec's wording of "minimal length insn with the
> low 16 bits all zero".
>
> And then I'm puzzled by the main opcode restriction related error
> being raised a whopping 6 times for ".insn i 0, 0, x0, x30, ~0",
> and still twice instead of just once for ".insn ci 3, 7, x31, ~0".
>
> Jan
>