Open linsinan1995 opened 3 years ago
nds
means abbreviation of andes
, which used in Andestech internal only, P extension will become standard extension rather than Andestech specific extension, so I think nds
should gone in this implementation.
Hi @kito-cheng , I did not find a proper prefix for p ext operands, so keep 'nds' as prefix (since old spec also used it as a prefix for intrinsic functions). Prefixes like 'p', 'P', 'r' (rvp) and 'd' (dsp) are taken. I just filed an issue for this problem. Thanks.
I shouldn't have time to check the encoding, does the encoding conflicts are resolved in the v0.93 spec? If they are resolved, and the previous comments are also fixed, then the patches looks good to me. The operand naming doesn't really matter, just renamed to rps or others are fine to me, just avoid using the vendor prefixes since p is a standard extension. Thanks.
I shouldn't have time to check the encoding, does the encoding conflicts are resolved in the v0.93 spec? If they are resolved, and the previous comments are also fixed, then the patches looks good to me. The operand naming doesn't really matter, just renamed to rps or others are fine to me, just avoid using the vendor prefixes since p is a standard extension. Thanks.
I will check those encoding conflicts and then inform you. Thanks.
Some updates on the PR
bfd/elfxx-riscv.c
Also, I did not find any conflict with the encoding in B ext. Perhaps it has been resolved?
the new commit fixes an error that csr* instructions can't access RVP csr, and adds a test case.
Add p-ext support with spec v0.93