This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [EXT] Re: C.ADDI x0, 4: illegal instruction ?
Yeah, 0x0011 is definitely a HINT, so it should execute as a no-op
rather than trapping.
On Thu, Jun 27, 2019 at 2:17 PM Alex Rocha Prado <alex.prado@nxp.com> wrote:
>
> Hi All,
>
> Actually my main point is to ask what the hardware must do when trying to execute opcode 0x0011.
>
> I think the safest decision is to implement that as a HINT rather than an illegal opcode (from the hardware point of view those two behaviors are very different from each other).
>
> Do you agree ?
>
> best regards,
> Alex Rocha Prado
> NXP
>
> -----Original Message-----
> From: Jim Wilson <jimw@sifive.com>
> Sent: Thursday, June 27, 2019 5:46 PM
> To: Alex Rocha Prado <alex.prado@nxp.com>
> Cc: Palmer Dabbelt <palmer@sifive.com>; binutils@sourceware.org; Joe Circello <joe.circello@nxp.com>
> Subject: [EXT] Re: C.ADDI x0, 4: illegal instruction ?
>
> Caution: EXT Email
>
> On Thu, Jun 27, 2019 at 9:51 AM Alex Rocha Prado <alex.prado@nxp.com> wrote:
> > 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”.
>
> You are making multiple errors here.
>
> First of all, you are assuming that the assembler should exactly implement the ISA, but it doesn't because that isn't useful. The assembler for instance will accept "mv a0,a1" even though there is no mv instruction, and no a0 or a1 register. The assembler is more useful when it accepts aliases like these. The assembler still accepts scall even though it was renamed to ecall a while ago. Etc.
>
> You are also pointing at current docs, claiming it says one thing, while ignoring the fact that yesterday's docs said something different, and last year's docs said something even more different.
> You are also ignoring the fact that there are other docs, like the RISC-V Reader, that also say other different things. There are people who wrote code against old versions of the docs and other docs that were ambiguous. It would be cruel to deliberately break their code just because we changed some text in the ISA docs, text changes that don't actually change any instruction encodings.
>
> You haven't stated any clear reason why the assembler should stop accepting c.addi x0,4. This harms no one. And dropping this support clearly harms people who wrote code following old and other doc versions. So the reasonable choice is to continue supporting it.
>
> As has already been stated by myself and Palmer, there are ways to fix this, but they all require a lot of work for very little gain. We can add explicit support for hints which we currently don't have, and then you could disable hint support if you don't want it. We could add new assembler syntax for hints instead of re-using existing instruction syntax like c.addi and c.nop. We could add explicit ISA version support, so for instance if someone asks for User ISA 2.3, then we don't allow c.addi x0,4, but we do allow it if the user asks for User ISA 2.2. This would be more sensible if we used the C spec version number, except I don't think that the C spec version changed when this problem was resolved, as there was no actual ISA change just some text changes, and no one considered it important enough to deserve a C spec number change.
>
> If your actual complaint is that c.addi x0,4 should disassemble as c.nop 4 instead, then we already have a way to fix that. The disasembler will accept -Mno-aliases as an option, and then we just need to make sure that c.addi and c.nop have the aliases properly marked. But when I try this, I see that the instruction already disassemble as c.nop 4 instead of c.addi x0,4, so no change seems to be necessary and no -Mno-aliases option is necessary.
>
> Jim