We'd be better off with 9-bit bytes

Original Article ↗ Hacker News Discussion ↗

Alternative byte sizes & human ergonomics

  • Many replies immediately generalize the 9‑bit idea to 10, 12, or even 16‑bit “bytes,” often tongue‑in‑cheek, showing that “one more bit” arguments don’t converge.
  • Several people prefer 12‑bit bytes (3 hex or 4 octal digits) as nicer for representation than 9 or 10.
  • 9 bits breaks the clean 8‑bit → 2 hex nibbles mapping; some suggest going “all in” on octal instead.
  • 10‑bit proposals focus on: 0–1023 mapping neatly to “metric-like” units, 40‑bit addresses (1 TB with 4‑byte pointers), and 5‑bit nibbles that could encode case‑insensitive alphabets, but others argue 5‑bit nibbles are ergonomically awful for humans.

Historical machines & encodings

  • Commenters recall 36‑bit and 12‑bit architectures, PDP‑family machines, 6‑bit character sets, and various word sizes; non‑8‑bit worlds are not hypothetical.
  • PDP‑10 and similar systems had word‑addressed memory with flexible “byte” sizes; the claim that PDP‑10 “had 9‑bit bytes” is flagged as misleading.
  • Some describe 10‑bit ROM/“decle” lore and N64 graphics hardware using 9th bits internally for antialiasing and coverage.
  • Discussion of ASCII, EBCDIC, code pages, and CJK unification: several argue 8‑bit bytes were deliberately chosen around ASCII/BCD needs and were “good enough” at the time.

IPv4/IPv6 and address-space what‑ifs

  • The article’s claim that 36‑bit IPv4 (≈64B addresses) would have avoided much pain is heavily debated.
  • Critics note current device counts (tens of billions) would still push 36 bits to saturation; NAT and a new protocol would likely appear anyway.
  • Some argue earlier exhaustion (e.g., 27‑bit addresses) might have helped IPv6‑like deployment by making transition urgent before IPv4 became entrenched.
  • Others emphasize that IPv6 complexity and ecosystem decisions (e.g., Android’s SLAAC‑only stance, router UX, Linux stack quirks) are bigger blockers than address length alone.

Hardware and architecture concerns

  • Multiple comments stress that non‑power‑of‑two byte sizes complicate hardware: shift counts, bit indexing, FIFOs, RAM layouts, and bus widths.
  • Extra bits also cost silicon and can reduce effective addressable memory for a fixed die budget; many 8‑bit values wouldn’t actually use a 9th bit.
  • Some note hardware already uses “odd” internal widths (e.g., 24/53‑bit FP mantissas), so a 9‑bit byte is not impossible, just less clean.

Programming languages, ABIs, and portability

  • C is cited as capable of non‑8‑bit bytes (CHAR_BIT≠8), but huge amounts of code and newer languages assume 8/16/32/64.
  • Discussion of pointer size blow‑ups from 32→64 bits: memory overhead is large, but mitigations exist (arena allocators, x32‑style ABIs, tagged pointers).
  • Some argue highly portable C (not assuming specific widths) is actually cleaner; others prefer fixed‑width typedefs.

ECC, parity, and “ninth bit”

  • Historically, many 9‑bit schemes were envisioned as 8 data + 1 parity/control bit, not 9 data bits; people compare this to modern SECDED ECC (~20% overhead).
  • Several see consumer‑grade ECC (often “9 bits per byte” on the DIMM) as the only really compelling 9‑bit story.

LLMs and article reception

  • The explicit credit to GPT‑4 for “research and drafting” triggers skepticism; some dismiss the piece as “LLM slop,” others find it readable but fact‑wobbly.
  • There’s broader unease with LLM‑generated content and with people pasting LLM answers into discussions without added human substance.