Re: Defined illegal instruction

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

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