nx_zstd_huf_gate.nx
buildroot/runtime/nx_zstd_huf_gate.nx
about
nx_zstd_huf_gate.nx -- proves the zstd Huffman decode table.
T2 pins the EXACT table layout for a known weight set, index by index.
Weights {2,1,4,3,1} at tableLog 4 must tile 16 entries as:
0..7 symbol 2, 1 bit (weight 4, the shortest code, LOWEST indices)
8..11 symbol 3, 2 bits
12..13 symbol 0, 3 bits
14 symbol 1, 4 bits
15 symbol 4, 4 bits
Laying ranks out in SYMBOL order instead of DESCENDING WEIGHT produces a
table that decodes self-consistently and disagrees with every other zstd
implementation -- a file only this decoder can read. Asserting the indices
directly is the only way to catch that.
T3 requires the slots to TILE EXACTLY. A weight set that sums to 15 of 16
leaves an entry no symbol ever claims, and a peek landing there would decode
as symbol 0 forever. The build refuses rather than leaving the hole.
T5 decodes a hand-assembled backward stream. Bits were placed so the reader
emits 0 | 10 | 110 | 1111, which must come out as symbols 2, 3, 0, 4 --
four codes of four different lengths, so a decoder that consumes tableLog
bits per symbol instead of the code's true length fails on the second one.
license_tier: ORIGINAL
dependencies 3 imports · 0 importers
imports: nx_syscalls.nxnx_zstd_bits.nxnx_zstd_huf.nx
imported by: nobody (leaf or entry point)
call flow from main pre-order; caps 40 nodes / depth 6 declared; ↻ = already shown
structs
| none |
consts
| none |
functions
| 29 | func g_puts(s: *u8) -> i64 |
| 36 | func g_putn(v: i64) -> i64 |
| 50 | func main() -> i64 |