On Wed, 25 Feb 2026 20:04:20 GMT, Ben Perez <[email protected]> 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
