Defined illegal instruction
jacob navia
jacob@jacob.remcomp.fr
Tue Feb 13 09:05:01 GMT 2024
> 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.
More information about the Binutils
mailing list