Defined illegal instruction

Defined illegal instruction

[jacob navia]

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 find an instruction called « unimp » . It generates something else (an attempt to write into a read only special register). Is that the « defined illegal instruction » for risk?

Thanks for any answers

Jacob

Re: Defined illegal instruction

[Peter Bergner]

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

Re: Defined illegal instruction

[Andrew Waterman]

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
>

Re: Defined illegal instruction

[jacob navia]

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

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

Re: Defined illegal instruction

[Jan Beulich]

On 10.02.2024 13:56, jacob navia 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.

Except that on RISC-V (and other architectures separating code from data
by special labels, like Arm) you want to use .insn. Iirc this also ensures
debug line info would be properly emitted, if enabled.

Jan

Re: Defined illegal instruction

[Jan Beulich]

On 12.02.2024 21:43, jacob navia wrote:
> In my machine, the code you proposed gives « unrecognized opcode. Are you sure ?
> 
> I just copy/pasted the exact code that you sent me.

I didn't send you any code. What I sent you was a reference to a directive,
which of course needs using with appropriate operands. Without you quoting
what you actually used, I can also only guess that maybe you omitted the
leading dot; else I couldn't explain "unrecognized opcode".

Further, two formal requests: Please don't send private mail on technical
matters. You started this thread on the binutils list. It should remain
there. I've therefore restored at least that Cc.

Second: Please don't top-post.

Jan

>> Le 12 févr. 2024 à 08:29, Jan Beulich <jbeulich@suse.com> a écrit :
>>
>> On 10.02.2024 13:56, jacob navia 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.
>>
>> Except that on RISC-V (and other architectures separating code from data
>> by special labels, like Arm) you want to use .insn. Iirc this also ensures
>> debug line info would be properly emitted, if enabled.
>>
>> Jan
> 
> 

Re: Defined illegal instruction

[jacob navia]

> Le 13 févr. 2024 à 08:20, Jan Beulich <jbeulich@suse.com> a écrit :
> 
> On 12.02.2024 21:43, jacob navia wrote:
>> In my machine, the code you proposed gives « unrecognized opcode. Are you sure ?
>> 
>> I just copy/pasted the exact code that you sent me.
> 
> I didn't send you any code. What I sent you was a reference to a directive,
Yes, I know, the .insn directive. 
> which of course needs using with appropriate operands. Without you quoting
> what you actually used, I can also only guess that maybe you omitted the
> leading dot; else I couldn't explain "unrecognized opcode".
> 
> Further, two formal requests: Please don't send private mail on technical
> matters. You started this thread on the binutils list. It should remain
> there. I've therefore restored at least that Cc.
> 
> Second: Please don't top-post.
> 
> Jan

OK Jan, this is just a misunderstanding. I thought you sent me an actual directive, without  looking into the the .insn directive again. I wrote the doc for that assembler directive some months ago, so I didn’t have the details in my memory. 

Besides, I can’t find the official doc for the 32 bit defined illegal instruction, I have made somewhere a mistake, since I do not find it in the official doc ( The RISC-V Instruction Set Manual: Volume I Dec 2022) 

There is only a 16 bit defined illegal instruction. For machines not supporting compressed instruction there is nothing as far as I can see, so the work around proposed (writing to a read only CSR) is OK.

In any case, we can drop the .long 0 proposal that I did, and I will write only the two existing instructions (unimp and c.unimp).

Thanks for your help and I promise not to top-post… I sent you my answer as a private message to avoid cluttering this group with too detailed technical discussions, but if you prefer I will always pass through the group, no problems with that.