Defined illegal instruction

[Andrew Waterman]

On Sat, Feb 10, 2024 at 4:56 AM jacob navia <jacob@jacob.remcomp.fr> wrote:
>
> OK. So now we have:
>
> unimp and
> c.unimp
>
> Both generate 16 bit zeroes if the C extension is present.
>
> If the C extension is not present,
> unimp generates
>
> csrw cycle, x0
>
> If we want to generate the defined unimplemented instruction in 32 bis we write
>
> .long 0
>
> As in the power PC.

Sounds like an accurate summary.

>
> I am going through each one of the instructions because I am writing a full documentation for the gas assembler for riscv. It has now approx 200 pages, with explanations about the riscv encoding, the software, its history, etc.
>
>
> Thanks for your help.
> Jacob
>
>
> > Le 10 févr. 2024 à 01:03, Andrew Waterman <andrew@sifive.com> a écrit :
> >
> > If memory serves, the reason we didn't define unimp to be 0x00000000
> > is that 0x0000 is a 16-bit-long instruction (because the two LSBs are
> > zero).  When targeting RISC-V variants that lack support for 16-bit
> > instructions (via the C extension), the inclusion of a 16-bit-long
> > instruction (or, I suppose, a pair of 16-bit-long instructions) can
> > confuse both humans and disassemblers.  unimp does map to 0x0000 when
> > the C extension is provided; it only maps to the
> > illegal-write-of-read-only-CSR when the C extension is not provided.
> >
> > On Fri, Feb 9, 2024 at 9:48 AM Peter Bergner <bergner@linux.ibm.com> wrote:
> >>
> >> On 2/9/24 11:03 AM, jacob navia wrote:
> >>> The riscv processor defines an illegal instruction (all zeroes). I do not
> >>> find the mnemonic used by gas for this. As far as I remember, the x86 also
> >>> has a defined illegal instruction.
> >>
> >> I can't speak for riscv or x86, but Power also defines a 32-bit all zero
> >> instruction as an illegal instruction.  We do not have a mnemonic for it
> >> though.  When we want to emit that into the instruction stream, we just
> >> emit a ".long 0" assembler directive.  Maybe the other architectures do
> >> the same thing?
> >>
> >> Peter
> >>
>