The Ed25519 SVP64 implementation needs documentation (similar to the existing chacha20 SVP64 cookbook entry). done see URL Field
commit 8ad172c480d989b191027840d7b8a7ca2cf48df0 (HEAD -> master, origin/master, origin/HEAD) Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> Date: Sun May 26 15:04:08 2024 +0100 https://bugs.libre-soc.org/show_bug.cgi?id=1166 add documentation of ed25519 on horizontal and vertical first algorithms covering ed25519_mul
received under the (private) RFP system, copied here Thanks for the additional information. BTW: are you aware of https://nlnet.nl/project/lib25519 - this is the most optimised version I'm aware of, overseen by Dan Bernstein himself ...
(In reply to Luke Kenneth Casson Leighton from comment #2) > BTW: are you aware of https://nlnet.nl/project/lib25519 - this is the most > optimised version I'm aware of, overseen by Dan Bernstein himself ... let's have a look https://lib25519.cr.yp.to/lib25519-20240321/crypto_mGnP/ed25519/ref10/fe_mul.c.html *massively* loop-unrolled algorithm. precisely and exactly the antithesis of the benefits of Simple-V multi-dimensional assembler! it also is not useful in that it uses entire 64-bit computations to calculate a single carry-bit, where the underlying POWER ISA has carry flags that can be CHAINED. a big-integer add is therefore a single instruction! sv.adde! looking at this - it contains no notes. https://lib25519.cr.yp.to/lib25519-20240321/crypto_pow/inv25519/amd64-mxaa/fe25519_mul.S.html unfortunately therefore it is far beyond scope to assess, although useful in the large number of instructions as a comparative point
movq %r8,0(%rdi) movq %r9,8(%rdi) movq %r10,16(%rdi) movq %r11,24(%rdi) that would become 2 instructions, one to set length to 4, the other sv.movq *r8,8(*rdi) which would step by 0 8 16 24 on rdi but it is more subtle than that, as the carry-flag typically replaces 3 instructions i believe?