Re: Defined illegal instruction

[jacob navia <jacob@jacob.remcomp.fr>]

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.

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