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

[Andrew Haley]

On Wed, 25 Feb 2026 20:04:20 GMT, Ben Perez <bperez at openjdk.org> wrote:

> 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);

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

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