Re: Defined illegal instruction

[Jan Beulich <jbeulich@suse.com>]

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