Hi Jerry, (Just so you know, you still need to fix your email configuration. Your emails have a bogus Reply-To header, which makes replies not be sent to you by default. I had to manually set the "To:" address when replying.) On Tue, Oct 31, 2023 at 10:17:11AM +0800, Jerry Shih wrote: > > The RISC-V vector crypto OpenSSL pr[1] is merged. > And we also sent the vector-crypto patch based on Heiko's and OpenSSL > works. > Here is the link: > https://lore.kernel.org/all/20231025183644.8735-1-jerry.shih@xxxxxxxxxx/ > > [1] > https://github.com/openssl/openssl/pull/21923 Awesome, thanks! > > > I'm also wondering about riscv.pm and the choice of generating the crypto > > instructions from .words instead of using the assembler. It makes it > > significantly harder to review the code, IMO. Can we depend on assembler > > support for these instructions, or is that just not ready yet? > > > > - Eric > > There is no public assembler supports the vector-crypto asm mnemonics. > We should still use `opcode` for vector-crypto instructions. But we might > use asm for standard rvv parts. > In order to reuse the codes in OpenSSL as much as possible, we still use > the `riscv.pm` for all standard rvv and vector-crypto instructions. If the asm > mnemonic is still a better approach, I will `rewrite` all standard rvv parts > with asm mnemonics in next patch. Tip-of-tree gcc + binutils seems to support them. Building some of the sample code from the riscv-crypto repository: $ riscv64-linux-gnu-as --version GNU assembler (GNU Binutils) 2.41.50.20231021 $ riscv64-linux-gnu-gcc --version riscv64-linux-gnu-gcc (GCC) 14.0.0 20231021 (experimental) $ riscv64-linux-gnu-gcc -march=rv64ivzvkned -c riscv-crypto/doc/vector/code-samples/zvkned.s And tip-of-tree clang supports them experimentally: $ clang --version clang version 18.0.0 (https://github.com/llvm/llvm-project 30416f39be326b403e19f23da387009736483119) $ clang -menable-experimental-extensions -target riscv64-linux-gnu -march=rv64ivzvkned1 -c riscv-crypto/doc/vector/code-samples/zvkned.s It would be nice to use a real assembler, so that people won't have to worry about potential mistakes or inconsistencies in the perl-based "assembler". Also keep in mind that if we allow people to compile this code without the real assembler support from the beginning, it might end up staying that way for quite a while in order to avoid breaking the build for people. Ultimately it's up to you though; I think that you and others who have been working on RISC-V crypto can make the best decision about what to do here. I also don't want this patchset to be delayed waiting for other projects, so maybe that indeed means the perl-based "assembler" needs to be used for now. - Eric
