RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v8]

[Ben Perez]

On Thu, 26 Feb 2026 09:20:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I was trying to use a similar structure to other `VSeq` methods, like `vs_addv` for example. Could you say a bit more about why this other approach would be preferable?
>
>> I was trying to use a similar structure to other VSeq methods, like vs_addv for example.
> 
> My comment applies to all such structures, not just these two.
> 
>> Could you say a bit more about why this other approach would be preferable?
> 
> There's the DRY principle: don't repeat yourself. We should be writing for the reader, who should not have to search to find out where the differences between two seemingly-identical are. That's where dangerous traps lie. These traps lead to failures in production.
> 
> More profoundly, there's the matter of trying to get to a fundamental truth, by abstracting details so that the code expresses the common structure.
> 
> Finally, there is the matter of the sheer number of lines of code. That's a burden to the maintainer. As Dijkstra put it, "we should not talk about the number of lines of code produced, but the number of lines of code used..." Think of poetry, rather than prose!
> 
> To give you a more concrete idea of what I'm talking about, his is an assembler example that works well. First, we express the common structure, then we point out the minor differences.
> 
> 
>  // Logical (immediate)
> #define INSN(NAME, decode, is32)                                \
>   void NAME(Register Rd, Register Rn, uint64_t imm) {           \
>     starti;                                                     \
>     uint32_t val = encode_logical_immediate(is32, imm);         \
>     f(decode, 31, 29), f(0b100100, 28, 23), f(val, 22, 10);     \
>     srf(Rd, 0), zrf(Rn, 5);                                     \
>   }
> 
>   INSN(andw, 0b000, true);
>   INSN(orrw, 0b001, true);
>   INSN(eorw, 0b010, true);
>   INSN(andr, 0b100, false);
>   INSN(orr,  0b101, false);
>   INSN(eor,  0b110, false);

This all makes sense. Perhaps we could do a larger `VSeq` refactor in a subsequent PR? @adinn also proposed some changes that would expand this functionality to GPRs as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2861442774