Why 9-Bit Bytes Could Have Changed Everything: A Rant on Missed Opportunities in Computing
Hello everyone. Today, let’s take a trip down the byte lane and talk about something that sounds like a fever dream from a computer science conference in the 1970s: 9-bit bytes. Yes, you heard me right. Not 8, not 16, but 9. And before you roll your eyes and reach for your anti-nostalgia medication, let me assure you—this isn’t just a thought experiment for the sake of it. There’s a real argument here that we’d all be better off if the world had standardized on 9-bit bytes instead of the now-ubiquitous 8.
The 8-Bit Tyranny: How We Got Here
Let’s start with a little history lesson, because every good diagnosis needs a patient history. Back in the 1970s, some systems—most notably the PDP-10—used 9-bit bytes. But then along came IBM’s System/360, which, like a stubborn old doctor refusing to update his stethoscope, set the standard at 8 bits. And because IBM was the big dog, everyone else fell in line. Now, 8 bits seems natural, almost like it’s encoded in our DNA. But is it really the best we could have done?
The Missed Opportunities: What 9 Bits Could Have Fixed
- IPv4 Address Space: Everyone knows the story: IPv4 has 32-bit addresses, giving us about 4 billion possible addresses. That sounded like a lot in the 1980s, but now it’s about as roomy as a hospital waiting room during flu season. If we’d had 9-bit bytes, IPv4 would have had 36-bit addresses—64 billion in total. That would still be enough today, and we’d probably have another decade before we hit the wall. No NATs, no convoluted workarounds, and maybe, just maybe, a smoother transition to IPv6 (if we ever needed it at all).
- UNIX Time: In our timeline, 32-bit UNIX timestamps run out in 2038, which means every piece of software has to painfully transition to 64-bit structures. With 36-bit timestamps, we’d be good until the year 3058. That’s right, your great-great-great-grandchildren could still be running legacy code without worrying about the clock running out. Negative timestamps would even cover events as far back as the collapse of the Classic Maya. Talk about long-term planning!
- Unicode: Unicode started with 65,000 16-bit characters, which seemed like enough for all the world’s languages—if you were really stingy with Chinese characters. With 9-bit bytes, we’d have 262,000 18-bit characters. That’s more than enough for every language, emoji, and cat smiley you can dream of. UTF-9 would be more of a compression format, and we wouldn’t have to deal with the mess of CJK unification.
- Pointers and Memory: 32-bit operating systems cap processes at 2 GB, which is pretty restrictive. 36-bit systems would allow up to 32 GB per process. Even today, that’s a big machine. Memory usage would be lower thanks to smaller pointers, though strings would be bigger. Overall, it might be a wash, but at least we wouldn’t be hitting arbitrary limits all the time.
The Lesser-Known Benefits: More Than Just Numbers
- AS Numbers: 16-bit Autonomous System numbers ran out years ago. 18-bit numbers would still be enough.
- Ports, Process IDs, User IDs: 18-bit versions would be roomier and less prone to exhaustion.
- Instruction Encodings: x86 and ARM64 instruction encodings would be a bit saner. Maybe even Thumb would work better.
- Half-Precision Floats: 18-bit floats might have become prominent earlier, making today’s manic 4- and 5-bit floats seem less necessary.
- Extended ASCII: With room for Greek, it could have become a kind of NATO code page, and UTF-9 would privilege most of Western Europe, not just the US.
- Unix Permissions: One byte, so no sticky bits. Octal, not hex, would be standard. (Blame the PDP-10!)
The Potential Pitfalls: Would 9 Bits Have Broken Anything?
Now, before you accuse me of being a 9-bit evangelist with a prescription pad full of rose-colored glasses, let’s talk about the potential downsides. No system has bit addressing, so a non-power-of-two byte size doesn’t actually matter. Page sizes and block sizes probably wouldn’t change. The kernel wouldn’t be doing anything different. Would something else exhaust in ugly ways? Maybe, but nothing as catastrophic as what we’ve already dealt with.
The scariest scenario is TCP sequence numbers. 18-bit sequence numbers might look appealing but would cause real problems for high-bandwidth connections. You’d need window scaling by the early ’90s and a bump to 36-bit sequence numbers by the mid-’90s, culminating in a TCPv2 effort. But even that’s not as bad as IPv6: ISPs would need to support TCPv2 to offer higher speeds, which was the main way ISPs competed. They’d make the investment. And since it all happens in the mid-’90s, HTTP might end up requiring TCPv2. We wouldn’t dual-stack.
The Alternate History: A World of Fewer Annoying Limits
So, what would this alternate world look like? Fewer annoying limits, fewer lame protocol extensions, less US-specificity, and so on. So much of the early computing era was shaped by numerological limits. With 9-bit bytes, we’d have sidestepped a lot of those issues. Sure, there might be some new problems, but nothing we couldn’t handle with a little bit of medical-grade ingenuity.
Conclusion: The 9-Bit Prescription
In conclusion, the world of 8-bit bytes is like a patient who’s been living with a chronic condition for so long that they’ve forgotten what it’s like to feel healthy. 9-bit bytes could have been the cure we never got. Fewer limits, smoother transitions, and a more inclusive computing environment. But alas, we’re stuck with 8 bits, and all we can do now is dream of what might have been.
And that, ladies and gentlemen, is entirely my opinion.
