Re: C.ADDI x0, 4: illegal instruction ?

[Alex Rocha Prado <alex dot prado at nxp dot com>]

  Hi Jim, Palmer,

  I have read all the info pointed by Jim and noticed that there is a significant difference between (doc1) "The RISC-V Instruction Set Manual Volume I: User-Level ISA Document Version 2.2" and (doc2) "The RISC-V Instruction Set Manual Volume I: Unprivileged ISA Document Version 20190621-draft".

  I will explain how I understand the issue:

  If we look at (doc1) page 82, the opcode 0x0011 does not match C.NOP because its opcode is uniquely 0x0001 and also does not match C.ADDI because it is stated clearly that bit range 11 to 7 must not be 0, thus it is an illegal instruction. From the other hand, if you take the same 0x0011 opcode and look at (doc2) page 111 it is clear that it matches C.NOP instruction.

  Do you agree on this understanding ?


Regards,
Alex Rocha Prado
NXP

===========================================================


On Wed, Jun 26, 2019 at 9:45 AM Alex Rocha Prado <alex.prado@nxp.com<mailto:alex.prado@nxp.com>> wrote:

>     I noticed binuntils 2.32 assembles the instruction c.addi x0, 4 without any error but from my understanding RISC-V spec defines that as an illegal instruction.

>     Latest official user-level  spec version is 2.2, on page 82, C.ADDI instruction are not allowed to have rs1/rd equal to 0 if nzimm field different from 0. If both rd/rs1 and nzimm are 0, then instruction is actually C.NOP. So, "c.addi x0, 4" is an illegal instruction and assembler should give an error.

>     Am I missing anything ?



What exactly is a c.nop and what exactly is a c.addi has been asked multiple times in multiple places and hasn't been decided yet.  I can't fix binutils until I get an official answer to this question.

See for instance

    https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Friscv%2Friscv-isa-manual%2Fissues%2F389&amp;data=02%7C01%7Calex.prado%40nxp.com%7Ca98e915666ca44052e2708d6fa73ac4c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636971772058668324&amp;sdata=bT6XbJWikm%2F%2FHGyzUfomYp4mpnU4eGbBlXsxjT537KI%3D&amp;reserved=0

and see also the full discussion at

    https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fgroups.riscv.org%2Fforum%2F%23!topic%2Fsw-dev%2F18ObEKnn4mE&amp;data=02%7C01%7Calex.prado%40nxp.com%7Ca98e915666ca44052e2708d6fa73ac4c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636971772058678326&amp;sdata=iUyp4m3HkgWwhVvWytjItVYJIaBHxQvTqtsVgXfNtl4%3D&amp;reserved=0



Technically it is a legal encoding because it is a valid hint instruction, but it isn't clear if it is supposed to be a c.nop hint or a c.addi hint.  The ISA documentation is ambiguous.  And so is the RISC-V reader.  The ISA docs for hint instructions were improved at one point, and they now have their own section instead of being hidden among other info.  If you have an old copy of the docs, you might not have the new hint docs.  See for instance

    https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Friscv%2Friscv-isa-manual%2Freleases%2Ftag%2Fdraft-20190626-e13c872&amp;data=02%7C01%7Calex.prado%40nxp.com%7Ca98e915666ca44052e2708d6fa73ac4c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636971772058678326&amp;sdata=Tp2Re%2BbvGFxyXP5Kyivr3UOAEGhJFGgBBLDLQuFyBa0%3D&amp;reserved=0

and see the Hint instruction section.  This says that this is a c.nop hint now, but I think that is different from the older text, and is different than what has been discussed in other places.



I don't think anyone really cares enough to fix the ISA spec and RISC V reader to make this unambiguous.  Meanwhile, I can't really fix binutils until the ISA spec is fixed, and even if the ISA spec is fixed I may not be able to fix binutils without breaking existing uses, so I think we are stuck with this indefinitely.



I suppose we could make this depend on the exact ISA version, and one can specify an ISA version via -march using the long form, but no one really does that yet, and it seems like overkilll for this c.nop/c.addi confusion problem.



Jim

==============================================================================


On Wed, 26 Jun 2019 09:45:31 PDT (-0700), alex.prado@nxp.com<mailto:alex.prado@nxp.com> wrote:

>

>     Hi all,

>

>     I noticed binuntils 2.32 assembles the instruction c.addi x0, 4 without any error but from my understanding RISC-V spec defines that as an illegal instruction.

>

>     Latest official user-level  spec version is 2.2, on page 82, C.ADDI instruction are not allowed to have rs1/rd equal to 0 if nzimm field different from 0. If both rd/rs1 and nzimm are 0, then instruction is actually C.NOP. So, "c.addi x0, 4" is an illegal instruction and assembler should give an error.

>

>     Am I missing anything ?



The ISA manual says



    C.ADDI adds the non-zero sign-extended 6-bit immediate to the value in register

    rd then writes the result to rd. C.ADDI expands into addi rd, rd, nzimm[5:0].

    C.ADDI is only valid when rd = x0.  The code point with both rd=x0 and nzimm=0

    encodes the C.NOP instruction; the remaining code points with either rd=x0 or

    nzimm=0 encode HINTs.  C.ADDIW is an RV64C/RV128C-only instruction that

    performs the same computation but pro-



Right now in binutils we handle the HINT instruction by just allowing the corresponding non-HINT instruction that would naturally encode as the same bits.  This is a bit of a historical artifact: the ISA used to describe hints as sub-types of other instructions, but now hints are described as explicit HINT instruction with many different encoding formats.  This behavior is all over the assembler, see the comments in opcodes/riscv-opc.c.



I don't think we can change the default behavior here, as that would be a backwards-incompatible change.  I wouldn't be opposed to adding an explicit HINT pneumonic that could encode all forms of hints and then something like "-mexplicit-hints", just like we have "-mno-aliases", but I don't think that's going to be high on anyone's priority list.



That said, if you (or someone else) wanted to start hacking on the RISC-V binutils port this could be a good project.

Alex