Closed topperc closed 9 months ago
@nick-knight @Xinlong-Wu @aswaterman @ChunyuLiao
here is a related issue: https://github.com/rvkrypto/rvkrypto-fips/issues/11
LGTM, thanks.
I removed __riscv_clmulh_32
and __riscv_clmulr_32
from RV64 as the emulation is 4-6 instructions.
I fixed the number of arguments to the xperm intrinsics. And I reduce the rotate amount for __riscv_rol_64
and __riscv_ror_64
intrinsics to uint32_t
What about adding an intrinsic that reads seed
CSR defined in Zkr
?
What about adding an intrinsic that reads
seed
CSR defined inZkr
?
It's not guaranteed to be accessible to user level software. I don't think it belongs in this proposal.
What do we need to do to move this proposal forward?
We have discussed this in today's SIG toolchain call. We have positive feedback in the comments here and the PR had much time so everyone had much time to give comments. Therefore, I've reached out to the sig-toolchains list with a request for review with the intend to merge this PR in two weeks
The planned timeline is as follows:
Clang/llvm patch https://reviews.llvm.org/D155647
Are we adding new macros like __riscv_zbkb
? If so, is it important to add them to this document?
Are we adding new macros like
__riscv_zbkb
? If so, is it important to add them to this document?
We have a list in this repo, but it does not make sense to add each and every extension manually (which is the reason that nobody does it). Kito attempted to address this in https://github.com/riscv-non-isa/riscv-c-api-doc/pull/28, but the PR was not finished.
So instead of a PR that adds __riscv_zbkb
it would be great to get a more generic description of the test macros.
@pz9115 is working on the GCC patches. The work is tracked in an dev-partners issue: https://github.com/riscv-admin/dev-partners/issues/37
I think the public review period for this is over now. How do we proceed?
@pz9115 is there an ETA for the GCC patch?
Still WIP, plan to send patches within this month.
@cmuellner I would suggest moving forward this PR, I mean merge this first, I believe the proposal isn't come with complicated technical issue on the GCC side, just need few more time to implement.
Also I am happy to accept that on GCC 14 even it's not stage 1.
I kept it open, because I was not sure if this is still being work on. Now, that this has been confirmed in yesterday's SIG Toolchain call, it is probably the best to merge it.
Thanks @topperc for the PR and the patience!
This is a proposal for scalar crypto intrinsics for the Zk* extensions.
I've removed the recommendation to use 'long' for XLEN. There's nothing guaranteeing that 'long' is XLEN. For example, if we were to support ILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.
Other design decisions are spelled out in the document.
Some text has been copied from #23.
One open question is whether we should emulate 64-bit intrinsics on RV32 where it is feasible. This could be useful for the sha512 intrinsics and some others.
@cmuellner @kito-cheng @mjosaarinen