The intent is to make a minimal implementation possible which can decode the first slot easily while simultaneously reformatting the packet to expose the B slot for interpretation by the same decoder on the next step. But also to make compressed code more digestible for wide, multi-issue implementations.

Not to imply that performance cores want compressed code. Merely that if they’re stuck with it as a compatibility constraint then it shouldn’t be so painful.

It’s still not a fully defined thing. Just a thought experiment gone a little too far.

This takes 1/4 of the total instruction coding space, meaning it steals 1/3 of the space occupied by RVC. It’s assumed that the remaining 2/3 of RVC won’t be used in conjunction with this as that would undermine the objectives given below.

Why?

To make compressed code less of an impediment to high-end cores, while teasing a couple of side benefits. In particular:

• To avoid the problems of unaligned 32-bit instructions
• To avoid the other problems with mixed-size instructions
• To exploit inter-opcode redundancies
• To use much less opcode space
• To dress up like a CISC architecture in order to gain its powers
• To maintain the conventional 2-source, 1-destination data flow model by executing 32-bit packets sequentially as two separate instructions
• To expose macro-op fusion opportunities within a 32-bit word when executing whole packets at once

Basically, I saw too many complaints about the various consequences of 16-bit aligned instructions mixed with 32-bit aligned instructions, and so I started thinking about it myself, and did some very rough hacking to see how I might solve it, and now I’m at the stage which I present here, which I hope is good enough to get the general idea across and demonstrate that the compression can work under the given constraints.

If you’re coming to this from the point of view of out-of-order wide multi-issue pipelines then I’m hoping you’ll be able to just chuck whole 32-bit packets through the front end as single instructions and then do µ-op fission in the usual way. Control flow only changes between whole packets.

Status

This is just an exploration, not a formal RISC-V proposal. All things are subject to change and much needs to be solidified before it can be implemented.

The results here are intended to establish the viability of the compression and to give a view on mindset and intent which motivated decisions, compromises, and blind hope.

Most of this document focuses on the cheap end, and how it might minimise the cost of implementation. Performance cores just get the occasional hint here and there about shortcuts they might take to avoid pain.

Some features here fall in the “totally unacceptable” category, and that’s OK. They just fill in gaps and highlight what needs further work. Some things have turned out to be less untenable than I expected.

Packet structure

A packet comprises two instructions compressed into a 32-bit instruction word. There are four register fields (the three standard ones, plus one more in part of funct7) which are shared between two regular RISC-V instructions:

The mapping of fields to different instruction operands is described by a frame. Different frames and different opcode pairs within each frame are currently enumerated in the ten free bits in opcode, funct3, and two bits of funct7 (two bits of opcode are reserved to identify this encoding scheme). More on “enumeration” and its decoder implications later.

No new instruction semantics are introduced; some optional instructions are included. A frame merely compressed two consecutive instructions into one 32-bit packet. The first instruction (generally) has its source register fields aligned to the source register fields of 32-bit opcodes, but the usual destination register field is (generally) the register written by the second instruction. Other fields are recycled and repurposed according to the specific frame structure they follow.

For example, a frame may designate a source register as also the destination register to save encoding space, or elide the destination register slot the first instruction and a source register slot of the second instruction and hard-code them as a temporary register.

Immediates are 5-bit by default, aliasing with a register index. When this is insufficient the frame may repurpose another register field to make a ten-bit immediate. When ten bits is too many (e.g., the index for bit shifts on a 64-bit platform) the immediate-consuming instruction is duplicated in the list of opcodes the frame supports, and the choice between the two (or four, or eight) copies of the same instruction serves as an extra bit (or two or three).

For chain rules, temporary storage is used and not encoded in the packet at all. It’s left to the implementation to decide what kind of path this data takes, with the caveat that it must be exposed architecturally for exceptions. The possibility is held open for the decoder to hard-code the temporary register as x31 or x7 if this does not impede optimisation (see Exceptions and interrupts).

Frame structures are signalled by the opcode field. Each frame has a number of opcode pair configurations it supports, and these are enumerated and rounded up to a power of two.

Instruction pairs only allow control flow changes in the second slot. Branch targets are always 32-bit aligned.

A frame might pose a question like “how do we implement load with base address write-back?” and then encapsulate the two instructions which implement that (load and addi) by re-using operands from the first instruction in the second (rbase -> rdest, rbase -> rs1, offset -> immediate), and then unroll that across all the opcodes (lb, lbu, lh, etc..) it needs to complete the set.

Typical savings come from sharing rd and rs1 (as rsd) encoding, and from ‘chain’ rules where the first result is used only by the second operation before being discarded, and so neither the destination register nor its reference in the next op need to be encoded explicitly. Implicit sp is used a lot as well, but that saving is usually spent on a longer offset for large stack frames.

Decoding and execution

In the simplest implementation an instruction decoder would decode the first slot normally (with the caveat that the destination register is not in the usual location), while also preparing another conventional 32-bit instruction word to feed back to the same instruction decoder for the next decode step.

Alternatively, an implementation might ingest the packet as a single instruction and split it into µ-ops at a more convenient stage in the pipeline. A more aggressively optimised implementation could fuse them into a single operation when practical.

Regardless of the implementation a valid packet has the architectural effect of two ordinary RISC-V instructions executed sequentially, each consuming its operands and producing its normal architectural result in turn, with slot B observing the effects of slot A. Some combinations may have to be excluded from permitted encodings if they have problematic implications in high-performance implementations. The intent is to capture such cases explicitly if they’re common but not to leave them as performance landmines if they’re rare.

Similarly, some packets, like rsd-alu-pair, specify separate destination registers for each slot, meaning they’re able to encode cases where the second slot must use the result of the first. This might offer code density gains but could raise pipeline headaches, so encoding such dependencies should probably be prohibited. If it remains legal then it must still behave as if sequential.

At present there’s no optimisation for ease of decode, other than an attempt to align the operand fields consistently. The remaining ten bits are a naive enumeration of all the allowed permutations, with little organisation into bits. That’s to be addressed later, but ten bits is at least better than 32.

Exceptions and interrupts

If an exception occurs inside a packet then the architectural state must be properly resolved such that execution can resume at the appropriate slot within a packet, as needed. If the first slot did not cause the exception then architectural state must be updated accordingly, as if the two slots execute sequentially.

Since a restart needs to distinguish which instruction caused the fault, bit 1 of the PC can be used to signal slot B (dressing up as if we’re executing two 16-bit instructions). This mechanism is only required for restarts and doesn’t have to have optimal performance. Normal branch and jump targets are always 32-bit aligned, and for all purposes outside of exception and interrupt handling PC can safely be assumed to be 32-bit aligned.

Interrupts are assumed to follow the same protocol as exceptions. It is hoped (TBD) that an implementation would be able to meet the architectural model while deferring interrupts until completion of the whole packet in order to avoid complexity.

The other obvious state needed for a restart is the temporary value used in chain operations.

Logically one could hard-code this temporary during instruction decode as x31 (which doesn’t exist on RV32-E, so maybe x7 instead?) so it’s automatically saved; but some implementations may not appreciate this constraint, and it would be preferable for such a named register to not be guaranteed to retain a particular value after chain packets in normal operation. The intermediate value should only be considered reliably written back when forced by an exception or interrupt.

Alternatively, just expose it in a CSR. I’m not sure what’s best for the most economical implementations.

Another alternative for exceptions, if an implementation doesn’t want to deal with the complexity at all and has the necessary machinery, could be to cancel the whole packet (reversing the effects of slot A where necessary) and for the exception handler to simulate the pair of instructions one at a time.

Breakpoints

I assume these can be handled much the same way as exceptions, in the case of hardware breakpoints, or with a couple more rounds of rewriting in-place using standard 32-bit instructions.

The encoding (provisional)

Here’s what I came up with. Opcodes are enumerated simply to demonstrate that they can actually be encoded into 32 bits while the frames continue to evolve. The current assignment of the bit values is not how it should be done, just something expedient.

Bits marked p below are the bits used to enumerate the opcode combinations available in each frame. The values for the integer stored in the p bits are given in the tables following the frame structure. It’s just a provisional assignment and hasn’t been tuned for a realistic decoder.

Where the enumeration jumps by more than one, and where instructions are marked “×n”, that’s where bits of the opcode enumeration have been taken to extend the immediate range. The plan, here, is to align the bits which choose between duplicate opcodes to always land in the same positions in every frame, so that immediates decode consistently (give or take masking to the proper length).

frame layouts

alu-alu-chain

Two ALU operations, the second consuming the first’s result.

index-mem-chain

Scaled-index addressing: compute base + i*width and access it.

pre-inc-pair

Advance a pointer, then access through it (pre-increment).

Notes and observations (mostly AI)

• The addi rows access AT the bumped pointer: at genuine (non- prologue) surviving-sum sites the memory offset is zero 68-78% of the time, so the rows spend no immb and give the bump the freed column instead – a 10-bit width-scaled imma, which the op declares at no extra codepoints. Even so the bump population is structurally wide (record-sized walks: 10-bit scaled fit is 39-59%); this is the affordable ceiling, not full coverage.
• The shXadd rows keep the 5-bit scaled immb: their stride is the register, so the offset field still earns its column.
• The shXadd form is the scaled POINTER WALK, shXadd rsda, rs1a, rsda (Zba: rd = rs2 + (rs1 « X)) – the pointer advanced by a scaled stride, which is what “advance a pointer” means and the form the corpus emits (its in-place-scaling sibling shXadd a, a, x measured 69 scheduled pairs on sqlite-rv64 against this form’s 210; one row decodes one operand binding, so rules.py admits only this one). The row is drawn at the STANDARD Zba read ports: the shifted stride rs1a in the rs1 column, the pointer rsda in rs2 – Zba’s rs2 position. B needs no port for its base at all: a pre-increment accesses through the UPDATED pointer, which is A’s result, forwarded inside the packet – so nothing competes with A for the columns and the operand-position discipline holds without a trade.

  post-inc-pair

  Access through a pointer, then advance it (post-increment).

Notes and observations (mostly AI)

• Timing oddity here because reg in rd field is written in first cycle not second.
• No shXadd clusters: a post-increment by a register-held stride is a real idiom, but neither clang nor GCC emits it adjacent to the access (zero scheduled pairs on every corpus).
• Both fields earn their columns, unlike pre-inc: the access offset imma is the position inside an unrolled window (small, 67-74% within +/-16) and the stride immb is the window size (wide). They decouple under unrolling – stride = offset + width holds at only 3-19% – so neither a zero offset nor a delta encoding works here.

  mem-sp-pair

  Two adjacent stack accesses one word apart – a spill or reload pair.

Notes and observations (mostly AI)

• both opcodes in a pair must be identical operations
• offsets differ by one data width, as in mem-base-pair

  mem-base-pair

  Two adjacent accesses through one base register, one data width apart.

Notes and observations (mostly AI)

• both opcodes in a pair must be identical operations
• No lb, lh or lwu: they account for 12 of 37816 scheduled slots across musl-rv32 and sqlite-rv64.

  load-alu-chain

  Load a value and immediately compute with it.

alu-store-chain

Compute a value and store it.

addi-store-chain

Form a value – constant, copy or sp-relative address – and store it.

Notes and observations (mostly AI)

• The data width comes from the op list (sb/sh/sw/sd), as in the other memory frames, rather than a width field – 4 codepoints is cheaper than two bits of layout, and it matches existing convention. sh captures nothing on this corpus but only 3 sites carry it, which is too thin to conclude it never would.
• A covers li (rs1a = x0), mv (imma = 0) and addi4spn (rs1a = sp) as register/immediate choices, so they need no opcodes of their own.

  addi-store-off-chain

  Compute a value from one base and store it at an offset from another.

Notes and observations (mostly AI)

• immb is width-scaled and unsigned; imma is signed – and that asymmetry is the frame’s whole shape. A memory offset carries an access width, so five bits of immb reach 4x or 8x further; an addi addend is pointer arithmetic and carries none, so its bits are bytes. load5-load5-chain gets a symmetric split because BOTH its immediates are scaled offsets; this frame cannot, and scaling A by the store’s k would not help – the addends are 93% ODD, only 28.8% are aligned to their own store’s width, and for sw (65% of the population) it is 5 of 295. The stored value is the chain temporary and is not encoded.
• THE WIDTH BELONGS TO B, measured 2026-08-04. The row draws five bits per column, so a sixth costs a doubling. Over 455 scheduled pairs on sqlite-rv32/rv64 and cpp-rv32/rv64: A’s addend fits FIVE bits 97% of the time and two bits 95% of the time, while B’s scaled offset fits five only 33% of the time and six 100%. So A was paying 8 codepoints for the 2% that need a sixth bit. Dropped to 5+6: 16 codepoints to 8, at a cost of 5 pairs on sqlite-rv32 and 4 on sqlite-rv64. Narrowing B too (5+5, 4cp) costs a further 135 and 130 – that bit is real.
• This is a SQLITE-shaped frame: 212 hits on sqlite-rv32 against 12 on cpp-rv32. A cpp-only reading makes it look like the worst frame in the encoding; it is not.
• rules.py EXCLUDES the li form (rs1a = x0) here even though the row draws rs1a and could encode it: li + store belongs to the frames that price it (addi-store-chain at offset zero, alu-store-chain up to a 5-bit offset). The residue – li + store at an offset only this frame’s sixth bit reaches – stays solo.

  load-store-chain

  Copy a value from one memory location to another.

Notes and observations (mostly AI)

• Both offsets are width-scaled and unsigned; the loaded value is the chain temporary and is not encoded.

  load0-load10-chain

  Pointer chase: bare first load, the second carries a wide offset.

Notes and observations (mostly AI)

• The A slot spends ONE opcode, not seven. must_chain_base makes A’s loaded value B’s base address, and a byte or halfword is not an address – so A is the natural word by construction. Measured over every chain the pairer can form, all 11583 of them across the suite, A is lw on RV32 and ld on RV64 100.0% of the time, with no exception on or off the axes. That is what lx names, and it takes the block from 7x7=49 codepoints to 1x7=7.
• immb gets the full ten bits – five from funct5, five from rs2, fields the pair leaves free because tmp is implicit and A’s offset is pinned at zero. This single form is 59.9% of all chases.
• Split from a frame that drew BOTH this row and its sibling’s over one 49-codepoint op-select, with nothing selecting between them: a decoder holding the word could not tell whether the field was the first load’s offset or the second’s. That frame’s standing TODO – balance imma against immb – is answered in results/corpus/CHAINS.md.

  load5-load5-chain

  Pointer chase with BOTH loads offset: a pointer in a slot, then indexed.

Notes and observations (mostly AI)

• The offset-bearing sibling of load0-load10-chain, on the pattern of addi-store-off-chain. It replaces an earlier deref-load-chain, whose population (offset on the FIRST load, second at zero) is the immb=0 column here – 2397 of its 2425 chases, the 28 lost being those needing more than five bits of imma.
• The ten free bits are split evenly because the corpus says so, not for symmetry. load0-load10-chain has already absorbed the whole imma=0 row, so what is left to catch is diagonal mass, and it is spread: measured corpus totals are 5+5 505255, 6+4 505073, 4+6 505032, 7+3 504522, 3+7 504635. Eleven bits (5+6) would reach ~10977 chases and cost an opcode doubling for ~154 pairs.
• rs1a = sp is what makes this frame necessary rather than a rounding error. An sp-based chase – a pointer read out of a stack slot, then indexed – is 58% both-offsets-nonzero and 1% B-only, against 20% and 60% for a non-sp chase. The slot displacement is an A offset by construction.
• The two frames are disjoint by construction: this one demands imma be nonzero and its sibling demands it be zero, so no chase is encodable both ways and neither shadows the other.

  load-base-branch-pair

  Load a value and branch on whether it is zero; the value survives.

Notes and observations (mostly AI)

• immb is the branch displacement, a 5-bit field. Displacements are unresolved labels in the corpus, so their fit is unmeasured.

  load-sp-branch-pair

  Load a stack slot and branch on whether it is zero; the value survives.

Notes and observations (mostly AI)

• immb as in load-base-branch-pair: unresolved, fit unmeasured.

  inc-branch-pair

  Step a loop counter by one and branch on the comparison.

Notes and observations (mostly AI)

• The step is +/-1, implied by the opcode (inc/dec = addi rsda, rsda, +/-1): 88% of adjacent counter-branch sites compare against a REGISTER, so the immediate column goes to rs2b instead of a step field; rs2b = x0 gives every vs-zero form for free. Full XLEN width only – there are no w forms.
• _r marks the operand-reversed spelling (the counter in rs2). The two clusters are the best sixteen JOINT direction x mode cells of the adjacent-site census, not a mode product: down-loops are bltu/bgeu-heavy (pointer-vs-limit, both operand orders), up-loops beq/bne with bge/bgeu sum-first. Joint enumeration covers 98.7% of adjacent sites against ~79% for the best 4-mode x 2-direction product at the same sixteen entries.
• The scheduler also matches addiw rsd, rsd, +/-1 and bills it here. That is optimistic for unsigned int counters on rv64 (defined wrap is not width-equivalent) in the same spirit as RVC- eligibility; signed counters are provably width-equivalent (overflow is UB), so a packet-targeted compiler emits addi.
• immb is the branch displacement in packets. Displacements are unresolved labels in the corpus, so pairwise fit is unmeasured; the label-distance study puts 10-bit fit near 100%.

  bit-test-branch-chain

  Test a bit or bit-field and branch on the result.

Notes and observations (mostly AI)

• The shift forms are the E1/E2 rewrite targets (low-mask and high-mask zero tests); a single-bit sign test via slli + blt tmp, zero is equivalence E5, a candidate this frame does NOT yet encode – its b list has no blt/bge – and rules.py matches accordingly.

  li-branch-chain

  Compare a register against a constant and branch.

Notes and observations (mostly AI)

• imma is a 5-bit register column; li declares 8 bits, bought by three opcode doublings (census li fit 66.9% -> 85.3% of 2293, ~13 pairs/codepoint for the extra 32).
• The row spells the constant in rs2. A site with the constant on the LEFT of an asymmetric compare (blt tmp, rs) is still encodable via the dead-tmp rewrite bXX K, rs -> bYY rs, K+1 (blt<->bge, bltu<->bgeu) – tmp carries only the comparison constant and dies at B, so changing its value is licensed. rules.py accepts those sites and rejects the two edge cases the rewrite cannot reach: K at the top of the field (K+1 overflows) and K = -1 under an unsigned compare (the predicate flips).
• TODO: could replace li with alu op and compare result with zero (mostly?).

  li-czero-chain

  Materialise a constant and conditionally zero it – one arm of a select.

czero-or-chain

Finish a conditional select: merge the surviving arm into the result.

macro-op-pair

Both halves of ONE computation over the same operands (mul/mulh, div/rem), declared as a pair so an implementation can fuse them.

Notes and observations (mostly AI)

• CARRY-OUT, measured (2026-08-04). cpp-rv32 holds 156 carry-shaped adjacencies, godot 36, everything else under five. The cluster takes the frame from 59 hits to 167 on cpp-rv32, but the corpus total rises by 29. The difference is NOT another frame losing the same pairs – alu-alu-chain cannot encode (add, sltu) at all, since sltu appears only in its A sets. It is greedy DISPLACEMENT: claiming the add denies it to whatever was pairing with it from the left, so alu-alu-chain drops 74 elsewhere in the stream. Report the frame’s worth as 29, not 108.
• THE REST OF THE FRAME IS KEPT DESPITE A NEAR-ZERO SCORE. Do not cut the mul/div clusters on pairing-rate evidence; they are not there to earn pairs.
• Every cluster is two halves of ONE computation over the same operands: the low and high words of a multiply, the quotient and remainder of a divide, the sum and difference, the min and the max. Encoding them as a declared pair tells the implementation both results are wanted, so it can FUSE – one pass of the multiplier or divider producing both halves – instead of issuing the operation twice and discarding half of each result. That is a hardware invitation, and it is worth a codepoint block whether or not today’s compilers accept it.
• They mostly do not, yet. Measured over four corpora: 70 scheduled pairs. The ceiling is no higher – adjacent tuple matches with positionally shared operands number 31 on musl-rv32, 25 on cpp- rv32, 2 on sqlite-gcc-rv64, 0 on sqlite-rv64 – so nothing is suppressing it. Notably the frame is NOT register-window constrained: this row draws four full 5-bit fields, so every register encodes.
• ORDER IS NOT ARBITRARY, and it is not a dependency either. The two ops read the same two sources and neither consumes the other’s result, so they commute – but the RISC-V M extension names one sequence as THE fusion idiom, and a microarchitecture told to detect fusable pairs is looking for that one: MULH[[S]U] rdh, rs1, rs2 ; MUL rdl, rs1, rs2 DIV[U] rdq, rs1, rs2 ; REM[U] rdr, rs1, rs2 high half first, quotient first, “source register specifiers must be in the same order and rdh cannot be the same as rs1 or rs2” – that last clause because the fused unit still needs both sources intact when it delivers the second result. _reject_dependence already enforces exactly that (a.rd not in b.uses_regs), so rules.py gets it for free.
• The clusters are listed in the spec’s sequence and the compiler already emits it (hi-first outnumbers lo-first 22:9 on musl-rv32, div-first is universal, and every measured occurrence satisfies the rdh-not-a-source rule). rules.py canonicalises, so both directions still pair; the canonical direction also gets the lighter dependence test, so keep it spec-ordered.
• The gap is a toolchain one – a compiler that knew this pairing were available would emit the two halves adjacently and in order. Treat the low score as a measurement of clang and GCC, not of the frame.

  rsd-alu-pair

  Two in-place ALU updates, each rewriting its own source register.

Notes and observations (mostly AI)

• The four register operands occupy the four 5-bit columns – 20 bits, the whole operand budget – so registers here are a FULL 5-bit field, x0..x31. An earlier draft anticipated cutting them to 4 bits; that is not needed and was never adopted.
• The two slots declare DIFFERENT op sets, and deliberately. Range past the row’s five drawn bits is bought in opcode entries – an op declaring N bits occupies 2^(N-5) of them – so weight, not op count, is the budget, and one bit on li costs what four reg-reg opcodes cost. A weighs 16 as fifteen ops that are nearly all weight 1 (breadth); B weighs 16 as six ops, of which li at eight bits is 8 and addi at seven is 4 (depth). The block is 16 x 16 = 256, the same as the symmetric set it replaces.
• The asymmetry is only purchasable because the pair is ORDER-FREE in 87.1% of the corpus residue: rsd-alu-pair packs two independent results, so unless one reads the other’s destination the scheduler may emit either orientation and only one need be encodable. The list scheduler already tries both (its tier-1 and tier-2 partner picks). See results/corpus/RSD-RESIDUE.md for the measurement and for the weighted optimisation that chose these two sets.

  prologue-pair

  Function prologue: reserve the stack frame and save the return address.

Notes and observations (mostly AI)

• rs1b is a drawn 5-bit field: ANY register may be the one stored at the top of the new frame. ra is the overwhelmingly common case but not a constraint – a leaf function that keeps its fp saves s0 there instead, and rules.py accepts it.

  epilogue-pair

  Function epilogue: release the stack frame and return.

Notes and observations (mostly AI)

• The row draws only the target register: the rs2+rs1 columns carry the sp adjustment, so a jalr here has a ZERO offset by construction – there is no field for one – and rules.py rejects the nonzero-offset spelling.

  dual-setup-pair

  Two independent small moves or constants – argument marshalling.

Notes and observations (mostly AI)

• THE WIDE BAND IS ARGUMENT-DESTINED, measured (2026-08-05). With the width caps relaxed to ten bits, wide li destinations are argument registers 86-89% of the time on musl-gcc-rv32 + sqlite-rv64 (at 7 bits 404 arg vs 51 other, at 8 bits 938 vs 154) and 85%/65% on cpp-rv32 – the arg-call-pair effect, without the call. The band this replaces, 6 bits at any rd, is nearly vacant: keeping it alongside the 8-bit band (re-measured, full scheduler) buys +18 pairs over three corpora for a doubled block. Dropped.
• Swept with the real scheduler against the 6-bit-any-rd baseline (musl-gcc-rv32 / sqlite-rv64 / cpp-rv32, corpus TOTALS so displacement is netted): +169 / +429 / +216 pairs. Part of the gain is displacement – rsd-alu-pair gives back up to 110, li-branch-chain up to 50 – which the totals already count. Re-measured 2026-08-07 on the merged operand-position baseline (post jalr-split and pcrel reworks, which absorbed part of the original gain): +144 / +249 on musl-gcc-rv32 / sqlite-rv64. Still positive at no block cost.
• addi4spn deliberately does NOT get the split: its wide destinations are a coin flip on musl+sqlite (129 arg vs 135 other at 7 bits) and splitting it regressed musl-gcc while paying on cpp (+375/-71 relative) – a C++-marshalling bet, not a win. Its 6-bit band stays as it was.
• The a0-a7 restriction is enforced by scheduler/rules.py (_ARG_REGS, shared with arg-call-pair); the yaml states it as the 3-bit destination part of the split rows, which is how arg-call-pair states it too. ONE wide variant on purpose: an intermediate draft carried the split in BOTH slots so per-slot pricing would see one declared width, which bought nothing – either slot alone covers every pair, because the frame is order-free and the encoder places the wide operand. The asymmetric ops spelling (li_8s in A, bare li in B) prices each slot as it actually is; rules.py stays slot-agnostic, accepting the wide op in either stream position.
• A-SIDE, NOT B-SIDE, and the two are not interchangeable in shape even though they are in capture. The spare bits are in rs1: it is the destination port, rda is the only operand drawn there, and narrowing rda to a0-a7 frees two bits for imma without touching another column – which is arg-call-pair row 2 exactly. Slot B has nothing equivalent, since rd holds rdb alone and immb would have to straddle two columns. Each side also costs exactly one canonical-order inversion (A-side spells (wide li, mv) li-first; a B-side band would spell (addi4spn, wide li) spn-first), so that is not a discriminator.
• PRICED 13 BY THE MODEL, ~19 BY HAND, in the same 32-block. opcode_codepoints scores each op against the slot’s WIDEST row, so slot B’s split rows (7-bit field) hide addi4spn’s sixth bit there, which in the full-rd rows still rides an opcode repeat – the same widest-row coarseness arg-call-pair already lives with; it also cannot see that B’s li needs its full-rd narrow row beside the split rows. A band-by-band hand count (B li: rd5 narrow + rd3 seven-bit + one repeat for the eighth) is ~19. Both are inside the block; the gap is a known model artifact, not spare room to spend.

  load-call-chain

  Load a function pointer and call through it (virtual dispatch).

Notes and observations (mostly AI)

• rd: unused leaves the selecting sentinel to the enumerator, which allocates it from the reserved x0/x2 pool per (host, sentinel) – both patterns are reserved either way, so whichever has room carries this frame.
• The link register is NOT drawn – both templates share one row and are told apart by the op-select, which is why the budget is 4 for two loads rather than 2. rules.py reads the permitted set from the b op list above (each op’s encode.rd), so a register that is not spelled here cannot be paired by the scheduler either.

  arg-call-pair

  Set up an argument, then call through a hard-coded base register.

Notes and observations (mostly AI)

• Row 1 holds mv, which needs only rs1a and rda; row 2 holds the three ops that want a wide immediate and an ARGUMENT destination, splitting the rs1 column three-two so imma reaches seven bits; row 3 holds the stores, whose source register needs all five bits and whose stack offsets are small. The call displacement rides funct5+rd in every row – the S-type immediate positions.
• A 3-bit rda costs almost nothing here and buys two: li at rda3+imm5 catches 925 of the 933 that an unrestricted rda catches on cpp-rv32, because these are argument setups by construction. 3+7 beats 5+5 by 68% on cpp li and 18% on cpp addi4spn.
• Load and store offsets scale by the ACCESS width, as c.lwsp and c.sdsp do: spill slots are aligned to the access, so k*imm costs nothing and reaches four or eight times further.
• addi4spn scales by four, which is a real trade rather than a free one: 10.7% of cpp’s addi rd,sp are NOT 4-aligned, because C++ takes the address of byte- and short-sized stack temporaries, so scaling costs 13% of the cpp hits (6473 against 7456 for a raw 7-bit field) and buys 0..508 instead of 0..127. On rv64 the scaled form is the one the fit prefers outright.
• The rd column carries the displacement in every row, so this frame neither hosts nor is hosted.

  setup-jump-pair

  Set up an argument or return value, then transfer control.

Notes and observations (mostly AI)

• j covers jal x0; a jal with a real destination is a call and is excluded from every jump frame.
• Direct j (78-92% of this frame’s packets) takes rows 3-4: rs1b is dropped – a direct jump has no register operand – and immb takes funct5+rd, a 10-bit displacement in PACKET units at the branch-immediate positions every control frame shares. Packets are 4-byte aligned, so the low bit RVC must carry is dead and a displacement costs 0.54x its RVC bits. 10 bits covers 84.6% of direct j on sqlite and 97-98% on musl.
• rules.py cannot range-check the displacement: corpus jump operands are unresolved labels, so a pairwise rule has nothing to test. The scheduled count includes the over-range tail (~15% on sqlite). See results/corpus/README.md.
• On the direct-j rows a load has no offset field (offsets are zero in 98.2% of chained cases anyway) and li narrows to 5 bits.

  arith-jump-pair

  A last in-place computation, then a control transfer.

The results

Random test files, compiled with RVC and run through a scheduler to try to pick out viable instruction pairs gives these results:

corpus          insns   pairs  packet%  realRVC%   vsRVC  to parity
testcase0       21875    4185    80.9%     81.6%   99.1%      -167
godot           90171   15823    82.5%     76.3%  108.1%     +5545
cpp-rv32       418345   92667    77.8%     71.0%  109.7%    +28786
cpp-rv64       409200   87664    78.6%     71.2%  110.4%    +30274
musl-rv32      118990   27712    76.7%     74.9%  102.4%     +2159
musl-rv64      102010   22208    78.2%     72.7%  107.6%     +5608
sqlite-rv32    192688   45512    76.4%     72.1%  105.9%     +8258
sqlite-rv64    189602   42689    77.5%     72.1%  107.5%    +10266
---------------------------------------------------------------------
RV32 aggregate 751898  170076    77.4%     72.2%  107.2%    +39036
RV64 aggregate 790983  168384    78.7%     72.2%  109.1%    +51693
COMBINED      1542881  338460    78.1%     72.2%  108.1%    +90729

This is suboptimal because it’s not using a compiler which optimises for the instruction set I’ve created. It’s also suboptimal because I’m using code compiled for RVC, which has register pressure that does not apply here, and so it uses more instructions than strictly necessary (at least in Clang’s case – GCC finds excuses to use more instructions regardless). I have some other test cases but the tabulation got mucky, so let’s just run with the above for now.

Development process

I vibe-coded an instruction scheduler which scans a corpus of assembly and attempts to find and fuse pairable instructions according to rules describing what a legitimate instruction pair would look like; just to get a feel for what sorts of pairing rules I could introduce. It simply looks at register usage to determine when a result is no longer needed, and which instructions can move past which other instructions.

This seemed easier than writing my own compiler to optimise a made-up instruction set which I hadn’t designed yet, but it also has limitations. There’s no expectation for it to yield runnable code; merely to give a feel for how things would pack if the nits can be worked out.

Then I randomly threw rules at it to see what would stick.

And I pivoted to laying out the bit patterns by hand in order to prove that the budgets were being met.

Attempting to draw things around the standard RISC-V frames brought out the four-register-field pattern shown above, while sweeping up the remaining bits for an unregulated mix of frame selection and opcode selection.

Then, I did a bad thing: I ran optimisers against an irresponsibly small corpus to see what could be squeezed out.

Here’s the tooling, such as it is: CISC-V experiment (content-warning: unchecked AI output)

It’s no longer human-readable. Claude has taken things in its own direction. Much of what it does is flaky and unreliable, and most of the code is only there as a toolkit for “what if?” queries posed to the AI. I don’t really want to think about working with that code by hand.

But it’s sufficient to get a gist of whether the ideas make sense and how they map to real code.

Pairing rule selection

I drew inspiration from classic CISC operations, proposals for macro-op fusion, and things other architectures do. And just kind of threw them all in there and mused openly to Claude about how that looked to me and asked it for feedback.

Claude was not a reliable witness, and led me down many garden paths of faulty analyses and losses of comprehension. But it was an exploration I could pick up on a whim with my phone, so it won on convenience.

It feels like it’s come out with a lot of redundancies; though often the apparent redundancies are just redistributions of immediate sizes to suit different idioms.

Biclique optimisation

Some (many?) instructions pair naturally with only a limited set of other instructions. Attempting to pair a free choice of any operation with free choice of any other operation isn’t fruitful. By cutting the frames into different sections with different purposes (often emulating different CISC instructions) it becomes easy to minimise the combinations which are worth making space for. Possibly (TBD) at the cost of decode complexity.

Conversely, rules like rsd-alu-pair avoid relationships between slots and so encoding freedom of operation order wastes nearly one bit, and removing that freedom realises more opportunities for tuning.

All this optimisation risks over-fitting and adding complexity to the decoder, so it must be done thoughtfully (Narrator: it has not been done thoughtfully).

Immediate sizing

This is gnarly. You get 5 bits by default, aliasing with a register index. Five bits can’t fully specify a bit shift on a 64-bit target. Five bits is often not enough for a lot of things. And you have to decide whether it’s signed or not.

In a lot of cases the thing to do is sacrifice another register operand to get a 10-bit immediate. Implicit SP with a 10-bit offset means you can get to a lot of local variables.

Also, the value of the immediate in one slot will often be scaled by the instruction choice in the other slot (e.g., addi gets its immediate scaled by 4 if it’s paired with lw), and of course memory access also uses its own implicit scaling.

Otherwise, duplicate the opcode in the opcode list to extend the immediate range by one bit.

Trawling through code there are patterns of step changes in immediate requirements. The specific corpus is an obvious source of this effect, and some artefacts of the original immediate limits of the existing architecture, but other things appear to be a legitimate reflection of the way code tends to work. I just kind of guessed. Claude helped. It did lead to a lot of redundancy, but I didn’t have many better ideas, so immediate shaping became a big factor in the design choices.

Enumeration

For the sake of a quick POC I just enumerated all the frames according to their population counts rounded up to powers of two, and hoped I wouldn’t run out of space. There’s scope to do this more intelligently, signalling specific conditions relevant to the instruction decoder in specific bits of the enumeration, but I haven’t put the effort in at this stage.

Load/store pairings

I was initially very reluctant to merge load/store data operands into interdependent arrangements with arithmetic, because it leaves no space for scheduling around memory delays. Eventually I resigned myself to accepting it, though, because without that there’s going to be a lot less compression.

Also, it opened up opportunities to hint at things that could be left out of direct ALU paths. Things like indirect branching via memory; where branch prediction (when present) typically goes ahead with its decision without seeing the data, and the data is only there to cancel the prediction after the fact if it was inconsistent.

Chaining with a base-register operand was less painful. In particular filling the gap RISC-V leaves with rb+k*ri address generation which, it turns out, can be done via temporary register without needing to save the intermediate result.

Future work

decode complexity

A major problem right now is that the enumeration of frames and opcodes within frames doesn’t really attempt to match established conventions about how the decoder can resolve details quickly. It does (generally) put rs1 and rs2 for the first instruction in the same slots, so they can be prepared early, but there are other details one wants to know soonish which could be surfaced but have not been.

With a bit of massaging it appears to be possible to reduce the signature of each frame type down to a handful of bits in the opcode field, and squeeze a signature for the transform required to turn the slot-B parameters into a slot-A frame in another handful of bits. But I have not written (or vibed) such an allocator yet.

how to approach that

What we have right now is ten bits of “deal with it later”, and 20 bits corresponding to operand fields in fairly regular positions. 1024 codepoints, only about 3/4 populated after rounding each frame up to a power of two.

What I believe is needed is to collate every codepoint by its slot-A operand patterns (including immediate sizes and positions) and to pack these bits together as a convenient decoder index. I think Claude said this was doable in about three or four bits.

Then, without regard to those bits, we need to sort the codepoints by the slot B operands in the same way, and pack these together in the same way, but in some different bits, so that we can begin the re-format of slot B into a shape the normal instruction decoder can ingest. One would also want a clear signal for branches and jumps, for the instruction prefetch pipeline.

There’s no guarantee that will resolve into a sensible number of bits, but I asked Claude to try and it said it might get away with three more bits, but I haven’t verified.

And in the cases where a list of opcodes contains repetitions of an opcode to make up extra immediate bits, that enumeration should be swizzled to put the redundant opcode selector at bit 30 or 31 of the word, so immediate decode is relatively consistent. This seems like the least hard problem, but it should be done.

quality

Another problem is lack of thoughtful optimisation and, conversely, gross overfitting to my limited test corpus.

And, of course, the regularity needs to be improved. Balancing regularity and generality against compression. And then factoring the cost model of a realistic compiler in and then fitting more tightly to that, and then reasserting regularity and generality all over again. Around and around and around…

That said, this adventure promotes itself as being CISC-inspired, so being a random bucket of overlapping things that seemed like good ideas is pretty on-brand.

sundries

And a toolchain would be nice, too. And an implementation. And from those, feedback into what makes a better target, and back around the tuning loops again with that insight in mind.

AI disclosure statement

Yep.

It also, while introducing some of the complexity of CISC, leaves behind other CISC advantages like explicit macro-op encoding for often-fused operations in higher-performance machines. But by blithely throwing in CISC instructions to get code size down you give up the simplicity of implementation for compact designs.

So I’ve been tinkering to try to find a different compromise which allows both fast and compact implementations to do things in a way that suits their separate goals.

I had hoped that this post, when I got to it, would be where I published a more complete proof of concept over what I have discussed before, but things have not gone to plan and I’m rushing this out tonight.

On the plus side, at least I have the name, now: CISC-V

And as we all know, naming is half the battle.

Instruction-packet-based compression

While strict alignment could be imposed on an existing 16-bit instruction compression scheme, that gives up coding space to express things which are no longer legal. It makes more sense to use 32-bit packets (or, conceivably, 64-bit packets) which can, in turn, exploit the intrinsic pairing of two opcodes within a packet for other gains.

That’s the plan, here. One 32-bit opcode may occupy a whole packet, or two compact instructions can occupy the same space instead.

Since a lot of assembly refers to the same register repeatedly from one instruction to the next it also makes sense to exploit this redundancy within packets to regain some coding space. CISC typically exploits this by using the same register as destination and one of its sources, but we can take things further by sharing with an adjacent instruction.

The down side is that some instructions which should be compact will fail to be compact because they can’t be moved adjacent to something they can share the packet with.

Other constraints can be imposed on the packet, as well.

In particular, both instructions must execute (give or take exceptions). There’s no branching to just the second instruction in the packet (all branch offsets must be 32-bit aligned, so relative branches reach further). And any branch out of the packet is coded as the second instruction, so it can’t prevent the execution of the other instruction in the packet.

(There’s an alternative model, here, where the first instruction can be a forward branch to the next packet, rendering the second instruction in the packet conditional, and the implementation can decide how it’s going to handle that)

The architecture still has to allow for exception restarts at the second instruction, but it doesn’t have to encode relative branches, and use of such return addresses can be restricted to appropriate instructions and/or privilege levels. Or difficult restarts can just be emulated in software.

Decoding models

Baby steps

Rather than decoding four bytes starting at the 16-bit address and advancing either two or four bytes accordingly, we always examine a 32-bit packet and decode it in one of two different ways depending on whether our instruction pointer is at an odd or even 16-bit boundary.

Alternatively, upon entry to a 32-bit packet, we decode the first instruction and begin to execute it, and concurrently we shuffle the bits around to produce a 32-bit opcode to decode on the next cycle using the same instruction decoder (with a bit of extra logic so exception resume can ignore the first instruction when necessary).

This is the target of the “as-if model” for other approaches. Ambiguous cases, if they’re allowed (preferably not!), should be resolved in terms of what this model would do. Here we risk producing those gnarly situations that cause high-performance implementations to do pipeline flushes, so try very hard to avoid this.

Omnomnomnom!

If you have the sort of implementation which likes to pick up dozens of opcodes at once and throw them all down the pipeline in parallel to be sorted out later, then you probably don’t want to hear about decoding each 32-bit packet twice and producing up to twice as many instructions as packets, even if most of them are no-op placeholders for instructions which didn’t decode.

To avoid that headache I propose pushing it back to the µ-op fission stage, since that exists already and it’s already in the habit of splitting things up which are too complicated.

What could possibly go wrong? I don’t know, so I assume it’s fine.

As a secondary benefit, it creates opportunities to not break some instructions, and to treat some packets as pre-fused macro-ops.

Exceptions

A restartable exception may be triggered within an instruction pair, and the architecture has to allow for this.

My working assumption is that bit 1 in the program counter or return address signals that the first instruction is to be ignored (it has already executed and retired), but this will not be used in any normal operation outside of exceptions. No calls can set this bit, no returns outside of exceptions should accept it being set, and relative branches are in 32-bit increments.

Also, while instruction pairing may suggest the use of a direct data path from one instruction to the next within the packet, without the need to land the result in a register, this data still has to be exposed for save, restore, and inspection by an exception handler. So a temporary register must be available.

The experiment

I vibe-coded a tool to try to maximise pairs of instructions by reordering instructions in ways that were functionally equivalent (in particular, by noting when registers were dead) but which would open up pairing opportunities. Unfortunately Claude soon became mired in its own bad code, and I was spending more time asking it to clean up its messes than I was trying new experiments.

For sample data I used a generic kernel built for a basic RVA profile (or maybe RVM?), and I built Godot for RVA23, and ran stats on both of these, attempting to reorder instructions to bring pairs together, but not too intelligently.

This is operating a little blind, and overlooking how the compiler might arrange things differently if it knew the target instruction set, but it’s the limit of the effort I’m going to make. Instead, I spent most of my energy cursing at Claude.

The whole effort was kind of a bust, and I needed to spend more time than I had doing it all from scratch. I could, theoretically, vibe-code it from scratch asking for a much more restricted tool where I could do the hard parts myself, but I don’t have time for that.

What I did get, though, was a better feel for what pairing rules are actually useful if the compiler were to put things in an order that exploited them.

Pairing types

The rules I found which most often identify pairable instructions are:

• load/store at adjacent memory locations (Aarch64’s ldp and stp opcodes) (top by a large margin)
• pairs of independent mv or li instructions
• double-indirect memory accesses (load a pointer, then load/store whatever that pointer points to)
• pre/post increment memory operations
• pairs of independent arithmetic in two-operand form (rsd, rs2)
• compare-branch chains (branch depends on result of comparison)
• load-branch chains (load followed by conditional branch on loaded value; which is then discarded)
• arithmetic chains

Chain rules

Chains are where the second instruction depends on the first, and in the experiments that I did the result of the first must also be discarded after use by the second, so the intermediate value needn’t be exposed in an architectural register – except that it’s still needed for single-stepping implementations and exceptions. My solution, here, is to use x31 or x15 as the hard-coded temporary register, with a rule that the content of the register is undefined after the second instruction.

Some pre-increment rules could be chains, too. These are cases where a value is added to a register before using that register as the base of a memory operation, and the base register is discarded after use. Pre-increment achieves this but it overwrites the original base register with the modified address, which is not always the desired outcome (maybe 50:50, varying significantly by testcase).

So, instruction pairs like:

op0, rd0, ra0, rb0
op1, rd1, rd0, rb1

or

op0, rd1, ra0, rb0
op1, rd1, rd1, rb1

can be replaced with:

op0, x31, ra0, rb0
op1, rd1, x31, rb1

and then x31 is not coded at all, but rather deduce that from the pairing category.

This pattern has further sub-classes where the relationship between op0 and op1 is constrained to save coding space.

First, exclude the two-operand instructions (one-in-one-out), like li and mv because they don’t benefit.

If the second instruction is load/store, then the first is preparing its base address (pre-increment, no write-back), and shifts and bit manipulation aren’t likely to be any use, so make a category and exclude those possibilities. At the same time the load/store instruction encodes a data size and this can restrict possibilities for the other instruction; eg., by choosing the right X for shXadd so we need only one entry in the set for all the adds.

Some instructions might not themselves be common enough to make available in both slots in a generic chain, but when they’re used we can guess at what they’ll pair with and make a mini set for them. For example, slli is often followed by srli, srai, add, sub, or or.

I had hoped to prohibit load-use-discard altogether and to keep the emphasis on things that paired without huge unknowable delays between the two, but the reality is that it’s too common to ignore in a compression scheme.

So if the first instruction is a load it may go on to generic arithmetic (which usually has other pairing opportunities anyway), but a lot of cases involve conditional branches or second indirections, and these are very hard to ignore.

I’d be curious to see how load-branch-discard could play out if it’s signalled explicitly in the instruction stream. Could branch prediction handle it differently from the signals it gets from the ALU?

Similarly, could explicitly-coded double-indirection (load-load-discard) suggest data prediction optimisations where they’re not otherwise warranted?

two-operand arithmetic rules

The best-known code size optimisation is to encode three-operand instructions with two operands by re-using the first source as the destination register.

In theory this could be another mode for chain rules, where the first result is saved for later and also forwarded to the second instruction; but that doesn’t seem to come up that frequently in the general case (a notable exception is pre-increment addressing).

Really a pair of these just sweeps up a lot of arithmetic which doesn’t otherwise fit a chain rule. This is redundant with chain rules if two of these in a packet use the same destination register (reserve for future use?), and the chain version is slightly more flexible in that it starts with two read-only inputs rather than just one.

But these can also be used to fill the pairing space with compact non-arithmetic instructions, like updating the stack pointer before function return, or implementing pre-increment with writeback before a memory access.

It’s tempting to take aside some operations which are uninteresting when ra and rb are the same register, and to re-purpose those as unary operations like neg, not, and slli rd, 1, rd.

Another special case here would be addi sp, imm, where the immediate here has to be a multiple of 16, so it can reach further, which is not a case which applies to addi rd, sp, imm.

two-in-two-out rules

There’s a group of operations which are often paired implicitly in CISC architectures, like mul/mulh or div/rem, and it’s potentially beneficial to fuse these because most of the work overlaps.

Instructions like those take the same two inputs for two different operations which produce two different outputs.

Other obvious pairs would be min/max, add/sub, and/andn, but these are only meaningful for coding efficiency (if you want to keep the inputs unmodified).

For coding efficiency I also put mv/mv, li/li, and mv/li (li/mv is uninteresting) into this set, where each instruction simply takes one or other argument directly.

We can also put the load-pair and store-pair instructions in this category, with a small wrinkle that the second instruction does the same thing but takes the immediate with an extra offset (the data size of the memory operation).

The compressible instruction sets

I simply haven’t had enough time to decide what to put in my straw-man proposal, yet. And I’ve run out of time to work it out. I blame AI.

I’ve cobbled together enough fundamentals to make a Linux kernel smaller than its RVC build (if my vibe-coded analysis tool is to be trusted), but when I tried the same on a compiled Godot binary results were much, much poorer. I blame C++ for that.

Instruction encoding

I’ve avoided dealing with this. What I do instead is count up the number of bits I need to encode all the fields, and then count the number of combinations this creates and add these to the total, and try to keep that total less than 2^30.

Actually laying the bits out in an instruction packet doesn’t seem terribly interesting. I guess it’s nice to align the source and destination registers of the first instruction with those of the 32-bit instructions (in a compact implementation there’s another cycle to use to redistribute the bits for a second interpretation).

I was thinking a sphere, originally. And applying that subtraction recursively in all of the solid areas left by the previous removals. Why a sphere? Well, that’s the mathematical ideal. Unfortunately you can’t print a sphere without something inside to support the roof (and maybe floor) while it’s printing. Also, the continuous symmetry of a sphere doesn’t really mean much when it’s sliced into layers and has different strength characteristics in different directions.

So spheres are obviously not ideal at all. But lots of things won’t be ideal, here. Let’s start compromising!

First, the sphere’s internal support. Ideally this support structure would not be too rigid. This is because a rigid support undermines the even distribution of forces we’re trying to get from a sphere. I’m no civil engineer but I have played Bridge Builder Game, and I know that if you make one part too strong you can force other parts to fail because they then get all the stress.

Ignoring that problem, I tried to get OrcaSlicer to add whatever it thought appropriate to support the roof of a sphere. Because my sphere was a void inside of a cube it was technically an external support, and it gave me this tree-like thing made of rings, which added a lot to the print time.

I think the ideal support would have been Lightning but I didn’t see that as an option. I guess it would deface the print if it were used as an external support, but my “external” is actually internal to the model and I won’t be trying to remove it. Another caveat there is you probably wouldn’t want a deliberately flimsy printing support to break off and rattle around inside the model at some later point.

So I stopped messing about with that and made a different shape which loosely approximated a sphere but tapered to points at each end. The so-called “fusiform”. It looks to me like an onion:

I think the tapers should be better than 30° overhang, but OrcaSlicer disagreed and only stopped adding supports when I lowered the threshold to about 27°. I figured it was a rounding error and I just switched supports off and assume my effort was good enough.

This shape is at least circular in one axis, meaning that it should be resistant to buckling. It comes to a point at the top and bottom, but unlike a bridge those points are points on a 2D plane supported all around by thicker material, and hopefully that’s good enough. Plus I have a few millimetres clearance before hitting the outside wall, with infill to spread that load (don’t try that excuse when building a bridge!).

download STL

With OrcaSlicer’s default settings (15% crosshatch infill, and some walls and stuff) the cost of the onion’s walls inside of a 10cm cube approaches the cost of the infill it replaces. It’s less material but only about 10% less time.

In order to make myself look more successful I changed the infill configuration to use more expensive infill. Presumably stronger infill, and still relevant – maybe more relevant – when there’s a huge hole in the middle.

I also tried adding extra, smaller onions in the corners to eat up more volume, but it only made things worse – wall thickness remaining constant, wall area shrinking, but enclosed volume shrinking much faster. So nevermind that; but it did highlight that I should test a smaller cube, and I did that instead.

The big question, though, is is it as strong as or stronger than the homogenous infill?

Well, I don’t know! I don’t have a 3D printer, and I don’t have the means to test it scientifically, and there are a lot of different ways to define “stronger”. This is all abstract and theoretical.

The next step is to try to increase the volume of the void without deviating too much further from our spherical ideal.

Enter, The Sphube!

You might be more familiar with the squircle, and this is just a 3D extension on that idea. These squircles and hypersquircles have the benefit of being continuous curves, and so should be a bit more resistant to buckling than a flat-faced cube would be. That makes them a more viable monocoque.

What we’re looking at in the general form would be some kind of shrunken, rounded monocoque approximation of the real model – a rigid empty shell – and on top of that we build up using a practical in-fill pattern, and on top of that we build the desired outer shape of the model. This construction should work like a truss arch bridge, with the infill acting as truss, the monocoque providing the arch(es), and the external model being the road surface people drive across.

Consider how the cross-section looks something like a bridge (two bridges):

This is a really half-arsed bridge. The infill is just a regular pattern rather than triangles with carefully-chosen dimensions and placement. But it might be sufficient. Baby steps.

The down-side is that trusses add tensile stress (where steel excels, but 3D prints do not), which means that layer adhesion becomes a much more concerning factor. Maybe that’s why this isn’t a standard approach already.

But that’s really the big idea, here. Make all the walls into trusses with the underside of the truss being a strong monocoque which resists compression by being wholly convex.

Right now I don’t have the means to convert an arbitrary model to its eroded, curved form. I tried searching for model erosion tools and mostly just found ways to make things look weathered.

But I do at least know how to erode a square down to a squircle. That can be done with something like a smoothmax(), or a generalised mean of x and y coordinates. As in “we’re inside the squircle if smoothmax(abs(dx), abs(dy)) < r”.

If you imagine using max() in place of smoothmax() then that would give you a square boundary. And if you replaced max() with sqrt(dx^2 + dy^2) then a circle. smoothmax() and generalised mean can pick functions somewhere in between, with a parameter that allows them to express both.

After a bit of digging I found a simple way to get from those simple equations to an .STL file.

STL sphubes (lower-resolution STL sphubes)

But as we learned with the sphere, this isn’t going to work because of the roof problem, and my lack of access to an “external” lightning fill. Now it’s a bit worse because that roof is wider and flatter.

download STL anyway

So back to the compromises I must go…

Or I can just post this as-is and go tinker with sphubes generalised to other platonic solids for no clear reason at all:

Of course a much simpler solution is to just pick a bunch of reasonable colours and put them in a table (eg., 1 2 3). But doing things the hard way is more interesting. Also, a list which includes both black and white isn’t solving quite the right problem for this post…

Spoiler alert: this won’t (directly) attempt to address accessibility for colour-blind users.

I’ve written in the past about trying to draw diagrams and graphs on web pages. The essential point is that you can embed SVG with a transparent background but you must use currentColor as the pen colour when you do this, so that the image is drawn in the same colour as the text, rather than assuming that the background is always white so you need to draw black on top. If you use something like Dark Reader you’ll often see this go awry.

Alternatively you can force the background of the image to be a known colour, but then on a contrasting background that can still be hard to look at.

So I know how to draw lines with reasonable contrast from the background, without assuming that the background will be light or dark. The next problem is to add to that palette some extra colours which also contrast with the background but are visibly distinct from each other. Like three lines on a graph.

Single-parameter variation

A quick-and-dirty notion of “contrast” is having a different brightness. Having a different colour but the same brightness can be very hard to look at. So for starters, let’s look at just varying the colour while keeping brightness at a single value chosen to contrast with the text or the background.

$\frac{n}{\varphi} \mod 1$ has the property that every new $n$ falls inside one of the largest gaps, and inside the largest span of contiguous largest gaps (when there are many largest-equal gaps), etc., subdividing that gap/span by 1:φ, which is tolerably close to 1:2.

That is to say that each new value is as far as possible from as many previous values as possible without deciding in advance how many values you’ll need or changing step sizes at different stages in the sequence.

Anyway, let’s have a look. These colours step around the hue of the HSL space:

It’s interactive. You can resize the box to change the way rows line up, so you can put different colours next to each other for comparison.

And if you do that you’ll see a problem. It seems to visit relatively few colours before coming back around to use something very similar to a colour that’s already been used. So things get indistinct much sooner than one might hope.

Fun fact: When taking steps of 1/φ mod 1 those “kind of similar” colours occur at distances which are Fibonacci numbers. Resize the box to have a Fibonacci number of columns and you’ll see stripes.

HSL is tied to the numerical coding of colour in RGB. It’s made out of up and down ramps of R and G and B without regard to how they’re perceived. OKLCh, on the other hand, is tied more closely to human perception. Maybe that’ll help:

This has the unfortunate effect (normally a feature) of flattening the lightness of each colour, so none of the colours are distinguished by the perceptual lightness variations which would sneak through HSL. Maybe the hues are more evenly spread, but I can’t see it.

On the positive side, the contrast with the numbers written on the boxes is more even. That’s important.

Another problem with OKLCh is that it’s so easy to stumble out of gamut (the range of colours which the display can represent) and this brings gamut mapping into play. The way to do that is not well defined right now and it may never be defined in a way that’s useful for these purposes. It’s not always obvious how and when the test swatches I’m using here will be clipped to fit the display capabilities, so it’s hard to be confident that everybody sees the same thing.

That’s a problem with human perception anyway, but this makes it so much worse.

But let’s persevere with it a while longer…

Multi-parameter variation

Changing just the one parameter doesn’t seem to get us a lot of distinct choices. The next thing we can change without interfering with our fixed brightness constraint is saturation, or C for “chromatic intensity” in OKLCh. Alternatively, C represents the distance which the a (green-red) and b (blue-yellow) values are from 0,0 in OKLab, so we could vary a and b instead of C and h.

So how do you get the properties of $\frac{n}{\varphi} \mod 1$ in two dimensions? It turns out a (the?) generalisation takes us to the plastic ratio (ρ=1.3247), next. In short, multiply $n$ by (1/ρ, 1/ρ²), or (0.7548776662, 0.5698402910) mod

1. This maximises the minimum distance between any two points in two dimensions.

Here’s how that looks in OKLab:

This gives uniform coverage of a square in the chroma plane, so it has pointy corners where the saturation reaches further out than it can near the edges. It’s probably going out of gamut and being clipped in unpredictable ways.

In another problem space we could use rejection sampling to avoid those ugly corners, but then we can’t define a colour as a simple function of $n$. Instead, a technique to map two uniform random values (a square) to a uniform distribution over a disc is to take one value as the radius and the other as an angle around that circle. Squaring the value used as radius compensates for the over-concentration of points around the centre (proof left as an exercise for Google search).

Does this retain the mathematical rigour of low-discrepancy sequences? No. Not at all. But it’s the best I have right now.

And here’s what that gives us for OKLCh:

Something really unfortunate about the plastic ratio shows up, here. It’s too close to 4/3. This has the consequence that one parameter appears nearly periodic mod 4, with a very slow precession. For example, in the polar test case, we start at 0 so the first radius is zero (grey), and every fourth colour after that is very close to grey as well, and it takes a long time to climb out of that hole.

By switching the axes around then the problem will manifest in the hue instead:

For completeness, let’s also try OKLCh but with fixed C and varying the lightness instead.

Or swapping the axes:

Varying all three parameters

Next step is to make adjustments to all three parameters; but only modest adjustments so that all results still have strong contrast with the background colour.

I don’t know of a name for what comes after Golden and Plastic, but its value is g=1.22074408460575947536, and the reciprocals of the powers are (0.8191725134, 0.6710436067, 0.5497004779).

The lightness figure needs compression to ensure things don’t wander too far and start failing to meet the original contrast limitation.

But I preferred the result with the terms in a different order:

I wasn’t sure about the appropriateness of compressing an axis of an LDS the way I was doing it, so I tried using a smaller modulo instead:

but this version becomes distinctly worse at intervals of 22. Which is respectable, but it’s not as good as the previous version.

Those are all OKLab, so they have pointy saturation corners – though I did reduce the range a little to compensate. Let’s try another OKLCh:

And back to HSL:

And HSL with the axes rearranged:

So many choices… also, you can add some arbitrary starting value to pick a handful of colours you like the look of, and the subsequent colours will only come up in extreme cases.

Putting it into context

Given some function or other to turn an index into a colour, that colour still has to make sense for the way it’s being used. Coloured lines want contrast with the background while being distinguishable from each other, but if you fill in a box you probably want that fill to have contrast with any text that goes inside, so it should be close to the background colour.

In my totally unscientific tinkering I’ve found that low-saturation light colours (pastels) work well for lines on dark backgrounds and for fill colours behind dark text, and that high-saturation dark colours (“deep” colours) work well for lines on light backgrounds and fill colours behind light text.

Also, fills turn out to be easier to distinguish from each other than lines, so lines might need their saturation amplified a bit to compensate. Maybe. I don’t want to go that deep right now.

All that said; one should have other means to distinguish things because not everybody sees colour the same way.

Code plz!

In CSS you can deduce a contrasting background colour with something like: HSL(from currentColor 0, 0, clamp(0, l * -100 + 50, 1)) This negates the luminance and amplifies 100-fold so as to hit the limits imposed by clamp() right away. Resulting in either black or white being chosen.

One can also deduce that a low saturation might be desired when currentColor has a low lightness value, and high saturation is desired when currentColor has a high lightness value.

It’s easier to do this in two steps, first making a “mask” colour, and then using that mask as the basis for palette colours:

* {
  --stroke-mask: oklab(from currentColor
      clamp(.40, l *  100 - 50, .9)
      clamp(.15, l * -100 + 50, .3)
      clamp(.15, l * -100 + 50, .3));
  --fill-mask: oklab(from currentColor
      clamp(.40, l * -100 + 50, .9)
      clamp(.15, l *  100 - 50, .3)
      clamp(.15, l *  100 - 50, .3))

  --colour-stroke: oklab(from var(--stroke-mask)
    calc(calc(mod(.6710436067 * var(--n), 1) - l) * .25 + l)
    calc(calc(mod(.5497004779 * var(--n), 1) - 0.5) * a)
    calc(calc(mod(.8191725134 * var(--n), 1) - 0.5) * b));
  --colour-fill: oklab(from var(--fill-mask)
    calc(calc(mod(.6710436067 * var(--n), 1) - l) * .25 + l)
    calc(calc(mod(.5497004779 * var(--n), 1) - 0.5) * a)
    calc(calc(mod(.8191725134 * var(--n), 1) - 0.5) * b));
}

Where --n is an integer colour index. Just set --n to different numbers for each group of objects which should have the same colour, and use var(--colour-stroke) and/or var(--colour-fill) as appropriate within that.

TODO: here’s where I’d demonstrate boxes and lines in different colours, and on different backgrounds, but I don’t really have time right now.

I figured the thing to do would be to enumerate the cards randomly and then radix-sort them into place. This seemed like a comparatively (comparatively) easy mechanism to build. As a side effect, enumerating and reordering means that you could also add a camera and then identify and sort the cards by their actual value. It’s also much easier to verify that sorting has been done correctly than it is to verify that shuffling has been done correctly.

In fact, the user could choose whether to sort or to shuffle simply by placing the cards face-up or face-down. Or if it’s a real mess then the deck can be separated into face-up and face-down stacks in one pass.

Equivalence of shuffling, sorting, and riffling

What’s a riffle?

A riffle can be modelled as dividing the cards into two stacks and randomly picking either the left or right stack to deliver the next card to the result, over and over until there are no more cards. Each choice is based on probabilities proportional to the number of cards in each stack, and this model implies the dealer tries to mix the two stacks evenly rather than letting one side expire early and then simply dropping the rest of the cards from the other stack on top.

Unfortunately if you have too much precision then the outcome is that you interleave the cards in a regular left-right-left-right pattern, which is completely predictable. Some people can do this deliberately!

If it is ideally unpredictable then you need to do at least six of these to get a fair shuffle in a deck of 52 cards. Probably more, but certainly not less.

What’s a radix sort?

Radix sorting is a multi-pass binning operation, where the cards are sent to one of n (n will be two in this build) different bins depending on whether they should be at the front or the back of the sorted list. Doing this in multiple stages means making the decision based on different conditions on each pass. You might separate even and odd cards, then place one pile on the other for the next round, then low and high numbered cards mod-4, then mod-8, etc., with the final pass separating the red and black cards.

Technically separating the cards into two bins is the opposite of riffling; but the overall effect in either case is a permutation which can be identified by the binary decisions made along the way.

To use a sorting machine as a shuffler you can randomly assign unique numbers to each card, and then sort the cards by their associated numbers.

What you should not do is to take a sorting algorithm and then make random decisions at each comparison. That rarely works. Radix sorting might perform comparatively well in this arrangement, but it’s still wrong. In fact it’s radix sort’s good (but not perfect) performance that makes riffle shuffling converge on a strong shuffle after only one or two extra rounds beyond the theoretical minimum.

How are they similar?

If every card remembers whether it came from the left pile or the right pile, for every riffle step in a shuffle, then it would come out with six or seven boolean values, which you can combine as bits into a number, which represents its index in the shuffled pile. In essence the process gives each card a random 6-bit number and then sorts them by those numbers.

A radix sort replays that same string of decisions but in reverse order. Reading those same index numbers from the other end.

But look out. Just assigning numbers this way allows the possibility that two cards could have the same number, and then their final order won’t be changed from their initial order. More riffles add more bits to the numbers, decreasing the chances of two numbers having the same number and being “stuck together” for the whole shuffle, but it’s a coarse approximation of picking predictably unique numbers.

An ideal shuffle chooses unique indices for each card, and then sorts by that value. Moreover; an ideal shuffle chooses one of the 52! possible permutations and then puts the cards in that order, and that order can be described by numbering the cards according to where they land. A pair of cards could still come out in the same order as they went in, but only with a suitably low probability.

That’s a thing we can do trivially in a microcontroller, but not-at-all-trivially in a Victorian-era mechanical contraption.

How to build a thing for that?

To build a radix-sorting machine I need to be able to take cards one at a time from the source deck and to deliver them to one of two (or n) other bins according to logic of some sort, and once all the cards are redistributed, to combine those two piles and bring them back to the starting point for the next round.

Binning

Starting with the easiest bit; capturing the cards in multiple bins and bringing them back together into a single pile for the next round.

For this I decided on a vertical column with three shelves. The source pile at the top, and two output piles below that. A shuttle (also acting as the bottom shelf) can then lift the cards to the top, but as it lifts the cards, the shelves above have to get out of the way while depositing their cards on top of those already on the shuttle.

To achieve this, I made the shelves a pair of forks, on diagonal sliders. Upward pressure from below would push the forks backwards out of the way, while the wall they retreated into would keep the cards lined up with the shuttle as it rose. When the shuttle passed the forks they would drop back into place behind it.

Then the shuttle needs to deposit the cards on the top shelf and go back to the bottom. To achieve this it’s made of overlapping wings which lift up and slip between the forks on the way back down, leaving the cards on top of those forks.

And that actually worked! Hurrah!

Here I would offer a picture, but the kids stripped my build for parts and now we have a Lego Porsche 911 instead of a card shuffler. So I’m going to offer a quick and dirty 3D mockup instead:

Dealing

Next we have to deal the cards one at a time from the top pile, and decide where they should be delivered. Dealing cards with Lego is a problem that seems really hard. How do I ensure only one card is drawn at a time? How does a printer do that?

I ran out of time for the project before I could build any prototype, but I had thoughts and I hope to revisit the problem imminently.

My thinking, such as it is, involves a roller (motorised Lego wheel) on top of the deck pushes at least the top card out, while a brush sits beneath where the top card protrudes and tries to sweep back any other cards which got dragged along with the top card. Not sure if it’s necessary, but I feel like I at least have a plan if it turns out it is necessary.

Once the top card is protruding far enough that I think the brush has isolated it, slightly faster rollers can pick it up and get it moving on its way.

This mechanism has to have a bit of vertical freedom so that it can adapt to the shrinking pile, obviously, and I guess the smart thing would be to sense when the pile is empty (ie., when there’s no card supporting the roller, and it falls beyond a threshold). It also has to get out of the way when the shuttle is trying to refill the pile. I figure that the refill action should lift both mechanisms together, and then replace both mechanisms together.

I intend to use the same motor to drive the rollers and also to raise and lower the shuttle and rollers. Why? Because I only bought two motors and two motor controllers. This means turning the motor in one direction will lift things up and disengage the rollers, and then turning that motor in the other direction will lower everything and at the point it’s seated further motion on the motor toggles over to driving the rollers.

Slightly fiddly, but probably easier overall than adding more motors.

TODO: draw a diagram

Routing

Every card drawn has to be directed to one of the two bins, and so some kind of switch is in order. I figure that’s basically just a slide which can be raised or lowered to point at the appropriate bin. The main complication comes from wanting to make sure that timing errors don’t cause a card to get jammed in a destructive way, so there has to be clearance for the card to find a safe escape path if things move at the wrong time, and it has to jump over this gap in normal operation.

Also, I need a sensor to regulate the timing of the switching. One which will tell me when the next card is passing by. Or, in the fancy version a sensor to read the face value of the cards, and also that the next card is passing by.

There’s no Lego sensor for the second version, so I’m sticking with the first (though I do have a thing in a box somewhere…?).

TODO: more diagrams?

Actuation

controller

For the actual control logic I went with a micro:bit, because it’s cheap and because my employer gave me one to celebrate an anniversary. Also my boss gave me another one because he thought he’d never have time to use his.

Moreover, at the time I felt that the EV3 brick was unreasonably expensive and I wanted to do my part in making that cheaper so that Lego education kits could be stretched a bit further. But that whole thing is for another blog post.

Here’s all the bits I needed on some breadboard:

Parts: edge connector, driver, connector.

Since then Lego has changed its connector standard (again). I have the older motors right now, but I think I should re-do the build for the modern connectors at some point. Maybe Lego will stop changing the connector standard now?

motors

Lego Mindstorms “servo” motors are a combination of 9V DC motor and quadrature encoder. That and a PWM output from the controller are enough for a PID control loop to manage speed and position, but it won’t know its absolute position at boot.

One solution to this is to have a bump switch to confirm the zero position at start-up. Alternatively, Lego has a clutch gear and at boot time you can just over-extend the position and let that slip to reset the zero position. This introduces the risk of drift and may require periodic re-homing, but (depending on levers and stuff) it may also lessen the damage if a card gets jammed in the wrong place.

I have to say, playing with a PID loop on a Lego motor is fun and everybody should try it at least once. It’s interesting to feel how the poll rate and parameters affect the feel of the motor as it resists you pushing on it. It can feel disconcertingly solid in contrast with the elastic feeling of a motor without control – depending on parameters.

logic

With all the machinery in place I have to actually write some code. Well, I wrote some code early on. Starting with a driver for the quadrature decoder which is provided by the nRF51822 on the micro:bit, and the PID controller… but none of that means much without a machine to attach it to. Which I don’t have. I just have a racing car, a bunch of rubber-band launchers, and some stuff the dog’s been chewing on.

But what I would do is:

With the cards set on the top shelf, turn the first motor forwards continuously, feeding cards one at a time towards the ramp. In the first pass it doesn’t matter where the ramp points, because we’re just counting the cards (or checking the current face value order if we’re fancy). Keep rolling until a sensor tells us we’re out of cards.

Here we stop and do some thinking to decide what order we want to put the cards into. If we saw n cards we enumerate them in random order from 1..n, and that’s going to be our target order. Knowing how many cards we have we also know we’ll have to do ceil(log2(n)) passes.

Next reverse the motor, which stops the rollers and lifts the shuttle and rollers. Keep doing that until [TBD], then turn the motor forwards again to begin lowering everything. At this point rollers are still disengaged and the cards are on the shuttle which is above the top shelf.

On the way down the shuttle deposits the cards on the top shelf and passes between the forks. Once the shuttle hits the bottom, the [TBD] mechanism disengages from the shuttle and begins turning the rollers again. As each card passes by, move the ramp up or down to direct the card appropriately for its planned position in the final sort.

This is just an LSD radix sort. Odd numbered cards go up, even numbered cards go down, or whatever. Keep going until we run out of cards. Make sure the count is consistent with last time, or we’ve done a whoopsie.

Shuttle up, shuttle down. Repeat. This time the shuttle position is determined by the next bit in the cards’ indices.

Over and over until we’ve done enough passes to fully shuffle the cards. All done. Yay!

Now I just have to rebuild what I used to have, build and test the bits I didn’t already have, write the code, ???, and profit!

One day. When I’m retired, or whatever.

Here’s how LED strips are typically wired:

The vertical stack of LEDs is distributed along the strip somewhat, which is why you’re restricted to cutting the strip at regular intervals of every three or six LEDs.

Let’s simplify that by treating the LED circuits as lamps:

You can hover over a lamp to see where the current flows. The further you go from the power supply the greater the cumulative resistance of the power rails.

The expedient but costly solution is to reinforce the power rails in the strip by soldering some heavy hookup wire onto the strip at some of the cut points where you don’t actually cut it (once every metre should be plenty; more frequently would be unnecessarily tedious).

But if you happen to be running the strip in a loop, such that the ends end up somewhat close to each other, or if you’re willing to run one length of hookup wire alongside the strip, then there’s a simpler fix for that difference in brightness.

Connect one side of the power supply to the near end of the strip, and connect the other side of the power supply to the far end of the strip. Be careful to still connect minus to minus and plus to plus in the usual way, though. Like so:

This way the length of the circuit through each LED is (approximately) the same, and so the resistance is the same and they all come out the same brightness all the way along the strip.

You’ll see this in some prefabricated lighting strings which are not designed to be cut. They’ll have a third wire which is not be connected directly to the LEDs, but at the end it’ll be connected to one of the other wires, and that will complete the circuit from the far end back to the power supply to balance things out. If you cut those then they won’t work anymore, because you would need to reconnect two of the wires at the cut point.

It doesn’t matter if the power supply hookup lines are different lengths. Having the total length be unnecessarily long will be less energy efficient, but they affect all the LEDs equally regardless of whether or not both sides are the same length.

It might be tempting to link both ends of the strip together in tee intersections with the power supply. That should work, and you’ll get more light out of the system overall, but you may still see a bit of dimming in the middle of the loop.

int x;

Hello x.

Now suppose you decide that under some circumstances x should have a particular value.

if (some_circumstances) x = particular_value;

And later on x’s good buddy y wants to have its own value based on x’s value.

int y = f(x);

Hey y, how’s it going? What’s that? You say you don’t feel so good?

Oh dear. It looks like somebody’s coming down with a touch of the Undefined Behaviour. Perhaps some_circumstances wasn’t the only case we should have addressed, here.

Conventional wisdom says you should avoid this situation by always initialising your variables when you define them. Ideally you do this by declaring them only when you know what they should be. But sometimes you have only partial information when you want to put a value in there, and so in the alternate case you can only make something up:

int x = 0;
if (some_circumstances) x = particular_value;
int y = f(x);

But what if your intention was not to set y to f(0)? What if the real bug was in failing to consider another case and come up with a suitable result in that case as well? What if x was actually a uid_t? Should a uid be initialised to zero as a “safe default” in the case of logic bugs?

Well, you could initialise x with a value so absurd that the mistake was bound to be highly visible in some way or other. Good choices are signalling NaNs, nullptr, etc., or something you’ll catch in an assert() eventually (if you remember, and if you have the test coverage). That’s problematic if your type can only represent legal and appropriate values (very often the case for DSP work).

You could use a bigger type as a temporary, or use std::optional<> which includes an explicit flag saying whether or not the variable has been initialised. But these require that extra checks be manually implemented before the variable is used. Otherwise they’ll likely produce silent failures of their own. And checks might not be put in all the necessary places, because they’re a manual effort.

The thing is, though, leaving the variable uninitialised is setting it to an illegal value which the compiler will try to prove cannot escape:

int x;  // will definitely get overwritten
if (some_circumstances) x = particular_value;
if (some_other_circumstances) x = different_value;
if (unusual_circumstances) x = spooky_value;
int y = f(x);

Ideally, if (some_circumstances || some_other_circumstances || unusual_circumstances) isn’t provably true then the compiler will gripe about this and you’ll have to revisit the code and make it right. This is most valuable if the code was clean before you made changes and afterwards this warning suddenly turns up.

Sadly, Clang and GCC really only care if they’re going to produce an undefined value, and with optimisations enabled most of these cases are obviated by replacing predicates with constants. That might cover security vulnerabilities but it’s no help with logic bugs. To get the job done properly you need to run Clang with --analyze, or use your own favourite static analyser.

Clearly the compiler’s still not going to get all of them, and the static analyser might miss something too, so being the diligent you that you are you’ll hopefully catch the remaining cases when you run your unit tests with -fsanitize=memory.

But if you do initialise the variable before you know what should be in that variable, then those checks will never work. Consequently you can introduce bugs which cause the initialiser you chose (before you knew what the value should be) to become the final value, and neither the compiler nor the sanitiser will be able to tell you that you’ve done so. You’d have been better off knowing you just broke something, but instead you’ll just get that “safe” value you initialised with.

Modern tooling has made an uninitialised variable the implicit signalling illegal state. But it’s also long-established bad style, so people have put time and effort into hiding bugs which would have been surfaced by the tools had they not tried to improve their code.

It’s unfortunate that there’s no consistent way to explicitly declare a variable as having an illegal state which should raise an error if it’s used. All we have is well-known ad-hoc solutions like nullptr, NAN, std::numeric_limits<T>::signaling_NaN, maybe T::end(), etc..

I would prefer explicit syntax for “I don’t know yet” initialisers which still allow the tools to do their job but can drop in default fill values when the tools reach their limits. Like C++26’s erroneous behaviour, but made explicit so as to stave off those generic “uninitialised variable” warnings. Perhaps name it undecided<T>{} or uncommitted<T>{} or provisional<T>{}, with an optional value argument if you don’t want to leave that choice to the implementation, reflecting that the developer hasn’t chosen a value and any attempt to read it before it changes would be a mistake, but without implying that it could be uninitialised.

int x = uncommitted<int>{};
if (some_circumstances) x = particular_value;
if (some_other_circumstances) x = different_value;
if (unusual_circumstances) x = spooky_value;
int y = f(x);  // invoke C++26 erroneous behaviour as needed

Ideally the compiler or static analyser would pick up any oversights in that logic. If not, -fsanitize=memory might pick it up provided you have a test case that covers it. If not, then a default value is inserted as chosen by uncommitted<int>{}, or the value you specify if you choose to do so (even though you’ve clearly never tested it). One might expect uncommitted<float>{} to choose a signalling NaN and any pointer type to choose nullptr.

C++26 might achieve that if you leave the variable uninitialised at definition, but that just looks like a mistake, and it’s a landmine if you don’t have your compiler configured appropriately.

Additionally, if you could be explicit, you can be more explicit about other things, like:

int f(Result& result, int arg) {
    result = uncommitted<Result>{};
    // ...
    result = work_in_progress;
    // ...
    if (accident_happened) {
        result = uncommitted<Result>{};
        return -1;
    }
    // ...
    return 0;
}

And let the tools ensure that result is left untouched when it’s in an undefined state.

Rationale

RISCV sees implementations ranging from lightweight scalar to wide OOE superscalar, each needing to take very different approaches to how the instruction stream is ingested.

Things like the large number of instruction entrypoints with unaligned 32-bit opcodes are problematic for out-of-order machines; while the low-end processors still want to minimise code size and icache burden.

I’ve previously mused over the idea of aligned 32-bit packets of 16-bit instructions with extra constraints to try to make it easy to ingest the packet as a single opcode, and then to split it into micro-ops later in the pipeline, where everything else gets split into micro-ops already.

And at the same time I observed that overlapping rd and rs1 operands is not the only way to overload the bits in an opcode.

So without any real insight into the technicalities of how those things would work out in practice, I set about making my own little straw-man.

I’ve taken inspiration from other proposals, and tried to make such extensions available as pairs of more pedestrian opcodes within the same 32-bit packet. So what might look like a CISC instruction can be dressed up as two compressed RISC instructions instead; even if one were to implement it as a single fused instruction.

Design objectives

• Support only 32-bit opcode packets, but squeezing pairs of instructions into those packets for compression.
• Ensure that every such packet can be interpreted in two passes as two independent instructions, each conforming to the standard RISCV ISA model (2-in-1-out, etc.).
• Restrict branching to only the final operation of a packet.
• Try to exploit the frequent sharing of common registers in adjacent instructions to aid compression.
• Capture some proposed instruction extensions which could be implemented as macro-op fusion instructions and formalise them as pairs within one 32-bit packet.
• Use no more than 1/4 (30 bits) of the opcode space.
• Make code smaller.

References

Qualcomm Znew/Zics:

• https://lists.riscv.org/g/tech-profiles/attachment/332/0/code_size_extension_rvi_20231006.pdf

Macro-op fusion stuff:

• https://arxiv.org/pdf/1607.02318
• https://en.wikichip.org/wiki/macro-operation_fusion#Proposed_fusion_operations

RISCV reference card:

• http://riscvbook.com/greencard-20181213.pdf (warning: non-SSL link)
• https://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/RISCVGreenCardv8-20151013.pdf

A provisional attempt

With no statistical model of instruction-pair frequency, I just guessed at what might work and came up with the following.

For expediency I’ve only counted the number of instructions in each class and laid them out sequentially. It would be folly to try to arrange the specific bit patterns for efficient decoding before the supported instruction set is decided.

       0x0+0x10000000: 14: arith4  rsd,rsd,rs_imm          14: arith4  rsd,rsd,rs_imm          (28 bits)  660 hits
0x10000000+0x10000000: 14: arith4  t6,rs1,rs_imm           14: arith4  rd,t6,rs_imm            (28 bits)  0 hits
0x20000000  +0x800000: 14: arith5i rsd,rsd,imm5             9: arith5i rsd,rsd,{imm}           (23 bits)  79 hits
0x20800000  +0x800000: 14: arith5r rsd,rsd,rs2              9: arith5r rsd,rsd,{rs2}           (23 bits)  1 hits
0x21000000  +0x800000: 14: arith5i rsd,rsd,imm5             9: arith5r rsd,rsd,{rd}            (23 bits)  27 hits
0x21800000  +0x800000: 14: arith5r rsd,rsd,rs2              9: arith5r rsd,rsd,{rd}            (23 bits)  8 hits
0x22000000 +0x2000000: 14: arith4  rsd,rsd,rs_imm          11: beqz    {rd},imm11              (25 bits)  23 hits
0x24000000 +0x2000000: 14: arith4  rsd,rsd,rs_imm          11: bnez    {rd},imm11              (25 bits)  32 hits
0x26000000 +0x1000000: 13: cmpi    t6,rs1,imm5             11: beqz    t6,imm11                (24 bits)  0 hits
0x27000000 +0x1000000: 13: cmpi    t6,rs1,imm5             11: bnez    t6,imm11                (24 bits)  0 hits
0x28000000 +0x2000000: 14: arith4  rsd,rsd,rs_imm          11: j       imm11                   (25 bits)  76 hits
0x2a000000 +0x2000000: 14: arith4  rsd,rsd,rs_imm          11: jal     ra,imm11                (25 bits)  92 hits
0x2c000000  +0x100000: 15: arith5  rsd,rsd,rs_imm           5: jr      rs2                     (20 bits)  16 hits
0x2c100000  +0x100000: 15: arith5  rsd,rsd,rs_imm           5: jalr    ra,rs2                  (20 bits)  7 hits
0x2c200000  +0x200000: 21: --reserved--                    (21 bits)  0 hits
0x2c400000  +0xc00000: 19: pair.a  rd,rs1,rs2               5: {opcode:pair} rd,{rs1},{rs2}    (24 bits)  0 hits
0x2d000000 +0x1000000: 24: ldst    rd,imm10(rs1)            0: {opcode} {rd:next},{imm:next}({rs1})  (24 bits)  341 hits
0x2e000000 +0x8000000: 13: arith3  rsd,rsd,rs_imm          14: ldst    rd,0(rs1)               (27 bits)  364 hits
0x36000000 +0x8000000: 14: ldst    rd,0(rs1)               13: arith3  rsd,rsd,rs_imm          (27 bits)  635 hits
total size: 0x3e000000,  bits: 30
saved=2361, total=10258

Or here’s another verison:

       0x0+0x10000000: 14: arith4  rsd,rsd,rs_imm          14: arith4  rsd,rsd,rs_imm          (28 bits)  658 hits
0x10000000+0x10000000: 14: arith4  t6,rs1,rs_imm           14: arith4  rd,t6,rs_imm            (28 bits)  0 hits
0x20000000  +0x800000: 14: arith5i rsd,rsd,imm5             9: arith5i rsd,rsd,{imm}           (23 bits)  78 hits
0x20800000  +0x800000: 14: arith5r rsd,rsd,rs2              9: arith5r rsd,rsd,{rs2}           (23 bits)  1 hits
0x21000000  +0x800000: 14: arith5i rsd,rsd,imm5             9: arith5r rsd,rsd,{rd}            (23 bits)  27 hits
0x21800000  +0x800000: 14: arith5r rsd,rsd,rs2              9: arith5r rsd,rsd,{rd}            (23 bits)  8 hits
0x22000000 +0x2000000: 14: arith4  rsd,rsd,rs_imm          11: beqz    {rd},imm11              (25 bits)  23 hits
0x24000000 +0x2000000: 14: arith4  rsd,rsd,rs_imm          11: bnez    {rd},imm11              (25 bits)  32 hits
0x26000000 +0x1000000: 13: cmpi    t6,rs1,imm5             11: beqz    t6,imm11                (24 bits)  0 hits
0x27000000 +0x1000000: 13: cmpi    t6,rs1,imm5             11: bnez    t6,imm11                (24 bits)  0 hits
0x28000000 +0x2000000: 14: arith4  rsd,rsd,rs_imm          11: j       imm11                   (25 bits)  79 hits
0x2a000000 +0x2000000: 14: arith4  rsd,rsd,rs_imm          11: jal     ra,imm11                (25 bits)  92 hits
0x2c000000  +0x100000: 15: arith5  rsd,rsd,rs_imm           5: jr      rs2                     (20 bits)  18 hits
0x2c100000  +0x100000: 15: arith5  rsd,rsd,rs_imm           5: jalr    ra,rs2                  (20 bits)  7 hits
0x2c200000  +0x800000: 15: arith5  rsd,rsd,rs_imm           8: sw      {rd},imm8(sp)           (23 bits)  1 hits
0x2ca00000  +0x800000: 15: arith5  rsd,rsd,rs_imm           8: sd      {rd},imm8(sp)           (23 bits)  0 hits
0x2d200000  +0x800000: 13: lw      rd,imm8(sp)             10: arith5  {rd},{rd},rs_imm        (23 bits)  1 hits
0x2da00000  +0x800000: 13: ld      rd,imm8(sp)             10: arith5  {rd},{rd},rs_imm        (23 bits)  1 hits
0x2e200000  +0x200000: 21: --reserved--                    (21 bits)  0 hits
0x2e400000  +0xc00000: 19: pair.a  rd,rs1,rs2               5: {opcode:pair} rd,{rs1},{rs2}    (24 bits)  0 hits
0x2f000000 +0x1000000: 19: ldst    rd,imm5(rs1)             5: {opcode} rd,{imm:next}({rs1})   (24 bits)  402 hits
0x30000000 +0x8000000: 13: arith3  rsd,rsd,rs_imm          14: ldst    rd,0(rs1)               (27 bits)  372 hits
0x38000000 +0x8000000: 14: ldst    rd,0(rs1)               13: arith3  rsd,rsd,rs_imm          (27 bits)  620 hits
total size: 0x40000000,  bits: 30
saved=2420, total=10258

Other opcodes like breakpoint can be overloaded in the rd=0 space. Or fall back to 32-bit encoding.

The mem,mem operations essentially mimic the load/store pair instructions proposed by Qualcomm, but lacking pre/post-increment because that would break the 2-in-1-out contract in a two-round implementation. These share the base register and immediate offset arguments, and the destination register is a consecutive pair.

The arithmetic,mem and mem,arithmetic pairs provide the pre/post-increment operations proposed by Qualcomm, but are then generalised to offer other arithmetic operations as well. There are details to work out, here, regarding how the implicit shift produced by a load operation should interact with various types of arithmetic.

The mem,arithmetic pairs should probably be defined to prohibit use of the load result in the second operation, even though this is probably a very reasonable thing to expect to do in general.

And the cmp,b pairs produce the beqi and bnqi Qualcomm proposal.

The notes about hits and saved (you need to scroll right) are how many times that pair was used by a simplistic regex (currently only considering adjacent pairs) on a trivial benchmark which I ran through qemu. In the case of duplication the first viable row takes the credit.

About 2400 intructions out of 10000 instructions were squeezed into the preceeding instruction. The original RVC compression used about 5500 16-bit opcodes, so to compare like-for-like that means I used 4800 “16-bit opcodes”.

I don’t think that’s too bad considering that no tuning has been done either in my opcode selection or in the compiler to put things in a viable order. And I’ve put a lot of space into things the compiler obviously wouldn’t generate without modification.

Big caveat regarding the quality of my regular expressions, though.

load/store ops

| RV32  | RV64  | RV128 |
|-------|-------|-------|
| `lb`  | `lb`  | `lb`  |
| `lh`  | `lh`  | `lh`  |
| `lw`  | `lw`  | `lw`  |
|  --   | `ld`  | `ld`  |
|  --   |  --   | `lq`  |
| `sb`  | `sb`  | `sb`  |
| `sh`  | `sh`  | `sh`  |
| `sw`  | `sw`  | `sw`  |
|  --   | `sd`  | `sd`  |
|  --   |  --   | `sq`  |
| `lbu` | `lbu` | `lbu` |
| `lhu` | `lhu` | `lhu` |
| `flw` | `lwu` | `lwu` |
|  --   | `fld` | `fld` |
| `fsw` |  --   |  --   |
|  --   | `fsd` | `fsd` |

The x/y options differ between RV32, RV64, and RV128; if the unsigned version would be identical to the signed version because that is the native word size, then this instruction is repurposed as a native-sized floating-point load or store instead (resulting in RV128 having no floating-point load or store – oh well).

arithmetic ops

| 3 bits, 50% immediates|
|-----------------------|
| `addi`     # imm+0    |
| `addi`     # imm+32   |
| `addi`     # imm-64   |
| `addi`     # imm-32   |
| `add`                 |
| `sub`                 |
| `and`                 |
| `or`                  |

|4 bits, 50% immediates |
|-----------------------|
| `addi`     # imm+0    |
| `addi`     # imm-32   |
| `addiw`    # imm+0    |
| `addiw`    # imm-32   |
| `addi4spn` # imm+0    |
| `addi4spn` # imm+32   |
| `andi`     # imm+0    |
| `andi`     # imm-32   |
| `add`                 |
| `addw`                |
| `sub`                 |
| `subw`                |
| `and`                 |
| `bic`                 |
| `or`                  |
| `xor`                 |

|5 bits, 50% immediates |
|-----------------------|
| `addi`     # imm+0    |
| `addi`     # imm-32   |
| `addiw`    # imm+0    |
| `addiw`    # imm-32   |
| `andi`     # imm+0    |
| `andi`     # imm-32   |
| `addi4spn` # imm+0    |
| `addi4spn` # imm+32   |
| `slli`     # imm+0    |
| `slli`     # imm+32   |
| `srli`     # imm+0    |
| `srli`     # imm+32   |
| `srai`     # imm+0    |
| `srai`     # imm+32   |
| `rsbi`     # imm+0    |
| `rsbi`     # imm+32   |
| `add`                 |
| `addw`                |
| `sub`                 |
| `subw`                |
| `and`                 |
| `bic`                 |
| `or`                  |
| `xor`                 |
| `mul`                 |
| `mulh`                |
| `div`                 |
| `rem`                 |
| `sll`                 |
| `srl`                 |
| `sra`                 |

For the addi*4spn instruction, the rsd field is used simply as rd and sp is used as the new rs1. Also the immediate is multiplied by four. I suppose this should be an unsigned immediate because that’s where all the useful data is. A couple of other operations need unsigned immediates, too.

Where the second operation borrows its rs2_imm argument from the first operation it doesn’t have free choice between a register or immediate value. Consequently one bit of the encoding is redundant. I’ll fix that later. In fact, while sharing the immediate between two insturctions makes sense (eg., shl/shr patterns), it’s less clear that the extra bit of free choice for immediate serves any purpose. But it’s harder to recycle that bit.

|cmp (3 bits, all immediates)|
|----------------------------|
| `slti`     # imm+0         |
| `slti`     # imm-32        |
| `sltiu`    # imm+0         |
| `sltiu`    # imm+32        |
| `seqi`     # imm+0         |
| `seqi`     # imm-32        |
| `bittesti` # imm+0         |
| `bittesti` # imm+32        |

I don’t think bittest is a thing in any RISCV extension? But I’m throwing it in here because it fills a niche. The immediate operand is the bit index to test and to branch on.

Some instructions I just made up to fill in gaps while I didn’t want to think about it.

| pairs (4 bits, no immediates) |
| `add`     | `sltu`    |
| `sub`     | `add`     |
| `min`     | `max`     |
| `minu`    | `maxu`    |
| `and`     | `bic`     |
| `mulhsu`  | `mul`     |
| `mulh`    | `mul`     |
| `mulhu`   | `mul`     |
| `div`     | `rem`     |
| `divu`    | `remu`    |
| `???`     | `???`     |
| `???`     | `???`     |

The use of an add,sltu pair forms and add-with-carry, but is problematic in its definition. It breaks the pattern of sharing both source registers, needing the result of the previous add instead, unless the sltu part is instead redefined to be a different operation which simply computes the carry from the inputs.

TODO: Extracting carry like this raises questions on whether overflow is also warranted, and also if there should be branching versions of the same ops for efficiently handling small arithmetic with low-overhead escapes to longer arithmetic as needed (signed and/or unsigned, like as needed in in python and JavaScript).

Caveats

• Arithmetic paired with ldst are affected by the ld/st width (yikes?), which means that if you overwrite the load with a breakpoint you still need to be able to encode the effect on the adjacent op.
• Also, I didn’t think too hard about statistical merits of any of these choices. I took some guidance from the existing compressed instruction extension to keep it in roughly the right place, but my changes may add their own implications.
• There might be much too much overlap between the different register sharing modes for arithmeric. This needs to be looked at still.

Variations

• For mem,mem the immediate could be smaller and the pair of destination registers could be arbitrary, consistent with the arithmetic instructions which share both source registers.
• op.full rd,rs,rs ; =~op.full =rd,=rd,rs is also 25 bits and could probably be more use in that it doesn’t corrupt the original sources. just have to pick a sensible ~op.full.
• As well as the usual overloading of Rd=x0, it might make sense, for example, if Rsd=t6 then to read that as sp and write t6 in the first opcode, and then read Rsd in the second operation as t6 and write Rsd as the register actually specified. Or something like that.
• I notice there’s this RV32E profile, which discards the top 16 registers from the register file. This might be a reasonable compromise to repurpose a couple of bits, and presumably it’s easier to get the compiler to generate test code for it.

Questions

• I didn’t do anything about an optimisation using the same rd for both instructions (implicit discard of the first result after it’s used by the second). Why is that?
• When an arithmetic instruction has an implicit shift provided by being paired with a load or store (which has a data size), when should it apply? Should it affect only immediates? (I say no!) Should it affect only add and sub operations? Should it affect only operations whose destination register is the same as the base register in the memory operation?
• What are the alignment constraints of these mem,mem ops? I don’t know!
• Did I choose the right basic arithmetic instructions?

Observations

Reserving a portion of the coding space for compressed instructions it’s different from Thumb. One doesn’t have to squeeze everything in. If something is difficult it can be ignored and left to the 32-bit encoding, leaving coding space to allow anything else to capture more cases.

On the other hand it’s tempting to hang on to some of the CISC-like tuples on the basis that they are strong candidates for fusion, and sometimes that is a squeeze. It’s bad form to pre-suppose the implementation in the ISA, but it’s still tempting to make such an optimisation available.

Next steps

I really need more data about why each instruction fails to fall into a pair. Is it because I chose the wrong shortlist of opcodes, or because the operand constraints don’t fit, or because the immediate is too big? A lot of this hangs on choices the compiler made, which in turn reflect the instruction set it was aiming for, but I don’t think I’m capable of iterating over the compiler’s notion of available instructions, so I’ll just use proxy configurations instead.

As a general guide I plan to use:

qemu-riscv64-static -d nochain,in_asm,execxx ./benchmark

(or something like that) to collect translation blocks of instructions and count the number of times each block is executed. These blocks, compiled in different ways, can be used for a casual measure of the compression ratio, but it would rely on some re-ordering of instructions and a contract in the compiler to not use the t6 register because I borrowed it for some operation pairs with throwaway results.

What would be better is to see how different arrangements fare in an actual compiler trying to optimise for them, but I don’t know if that’s a realistic thing to experiment with.

In the simplest possible terms this compression works by maintaining a dictionary of pre-cooked strings, appending those to the output stream, and noting when they’ve already been emitted recently (a simple index to last use with bounds check) and emitting a backreference code instead of the full string in those cases.

Non-pre-cooked strings are not supported efficiently. It’s an encoder restricted to very specific applications. Probably.

The bit-packing overhead is obviated by contriving Huffman codes which always fall on byte boundaries. This is impossible for a generic octet stream in the Delete format, but is achievable for UTF-8 text.

The hard part turned out to be the checksum calculation. When I thought of the idea I assumed (hoped) it would be an Adler32 checksum where it is easy to reason about appending precomputed checksums to the running checksum. It turned out gzip uses CRC32, and gzip is the preferred format over zlib in web browsers. So I had to figure out how to append CRC checksums as efficiently as possible.

It turns out you can precompute the string checksum and store the string length as a multiplier to be applied to the running checksum via clmul and folding that with a 64-bit crc32 operation.

Arm has CPU instructions for both of these operations, but x86 only has the former (its CRC instruction uses the wrong polynomial), which means using clmul to calculate the crc as well. Typically this is optimised for SIMD use, but a scalar operation is all that’s needed here. I suspect the extra work to batch it into SIMD chunks would be worse than the savings.

TODO: a bunch of extra exposition

Here’s the code: defl-8bit.

possible improvements

• Write a preprocessor to break input text into strings at the most appropriate boundaries, adding flexibility in random string generation.
• Implement the higher-level backref operator so multiple backreferences can be consolidated and their checksums can be computed as the difference between start and end of previous copy.
• Make larger backrefs using the conventional rolling hash thing, but on the precomputed string fragments rather than every byte.
• Or, remember previous backref distance and merge them when possible.
• Clean up the code.
• Figure out a proper generic interface with virtual methods in places that make sense and don’t have scary performance implications.
• Add a practical fallback implementation for CRC for webasm compatibility (all that work for nothing!).
• Does the Adler-32 implementation even work?
• Tweak the clmul crc for performance.
• Tweak everything else for performance.
• Clean up this post.

Anybody except for ChatGPT, it turns out.

The rules I gave were simple enough:

• A word ending with a vowel represents a dot.
• A word ending with a consonant represents a dash.
• A word ending with a y represents the gap between letters.
• Express a message in morse code, using the above substitutions of words for symbols.
• The words should be chosen to form coherent sentences.

That seemed to leave plenty of freedom for choosing words.

It turns out schemes like these are called acrostics or telestichs (the latter in my case). The extra layer of using morse code and groups of letters helps to make it less obvious than traditional acrostics, but it takes several words to make a letter of the hidden message.

I thought an LLM should be able to churn out a coherent paragraph under those constraints, and I’m sure that it could if it could remember what it was supposed to do, but I had some difficulties.

For the secret message example, ChatGPT gave me:

Alone Henry left a trail then slept quietly, and followed slowly too.

I don’t know what that means or why it wrote it, but it decodes as:

. -.--- -- .

Which comes back out as E�ME. That’s not quite right.

Let’s try fixing it by hand:

Alone, Henry left the tree. Then sleepily he sat. Slowly following on my horse. What could he say? The adverbs are too many to try.

. -..- .- -- .--. .-.. . 

There. Fixed. But that wasn’t as much fun as I thought it would be. The adverbs are indeed too many. While there are plenty of words ending in y to choose from, it gets hard to think of things that aren’t adverbs or adjectives. And that need comes up too frequently.

Obviously having only words ending in one letter to choose from for that marker is too restrictive, and y is an especially distracting choice. Some markers could simply be dropped because there are a lot of cases where it’s not ambiguous, but unambiguous cases are at the end of infrequent letters, where it’s frustrating already.

I won’t try to fix this because it’s not my priority. All I wanted was something with the simplicity of a children’s game. Unfortunately I feel like it’s a bit too tedious for many kids to encode their own messages. At least without the support of an editor or thesaurus to offer up practical synonyms.

Or, of course, one could just make an LLM do it, as was the original plan. I’m sure it should have no trouble if it can be put in a suitable wrapper to keep it on track. But I’m too lazy, which is why I went to ChatGPT in the first place.

But there are many related schemes would could be devised, and I think technology is in a place, right now, where it should be trivial to automate. I just can’t be bothered doing that.

Update: I got Claude to do me a demo implementation.