Non-power-of-2 sizes are awkward from a hardware perspective. A lot of designs for e.g. optimized multipliers depend on the operands being divisible into halves; that doesn't work with units of 9 bits. It's also nice to be able to describe a bit position using a fixed number of bits (e.g. 0-7 in 3 bits, 0-31 in 5 bits, 0-63 in 6 bits), e.g. to represent a number of bitwise shift operations, or to select a bit from a byte; this also falls apart with 9, where you'd have to use four bits and have a bunch of invalid values.
To summarize the relevant part of the video. The RDP wants to store pixel color in 18 bits 5 bits red 5 bits blue 5 bits green 3 bits triangle coverage it then uses this coverage information to calculate a primitive but fast antialiasing. so SGI went with two 9-bit bytes for each pixel and magic in the RDP(remember it's also the memory controller) so the cpu sees the 8-bit bytes it expects.
Memory on N64 is very weird it is basicly the same idea as PCIE but for the main memory. PCI big fat bus that is hard to speed up. PCIE small narrow super fast bus. So the cpu was clocked at 93 MHz but the memory was a 9-bit bus clocked at 250 MHz. They were hoping this super fast narrow memory would be enough for everyone but having the graphics card also be the memory controller proved to make the graphics very sensitive to memory load. to the point that the main thing that helps a n64 game get higher frame rate is to have the cpu do as few memory lookups as possible. which in practical terms means having it idle as much as possible. This has a strange side effect that while a common optimizing operation for most architectures is to trade calculation for memory(unroll loops, lookup tables...) on the N64 it can be the opposite. If you can make your code do more calculation with less memory you can utilize the cpu better because it is mostly sitting idle to give the RDP most of the memory bandwidth.
> a common optimizing operation for most architectures is to trade calculation for memory(unroll loops, lookup tables...)
That really depends. A cache miss adds eons of latency thus is far worse than doing a few extra cycles of work but depending on the workload the reorder buffer might manage to negate the negative impact entirely. Memory bandwidth as a whole is also incredibly scarce relative to CPU clock cycles.
The only time it's a sure win is if you trade instruction count for data in registers or L1 cache hits but those are themselves very scarce resources.
Yeah but if the CPU can't use it then it's kinda like saying your computer has 1,000 cores, except they're in the GPU and can't run general-purpose branchy code
In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers. It doesn't address more than 4 GB of anything ever
Plato argued that 7! was the ideal number of citizens in a city because it was a highly factorable number. Being able to cut numbers up is an time-tested favorite. That's why there are 360 degrees.
360 degrees in a circle predates Plato by quite a lot (2000 years I think!). It comes from the Summarians more than 4000 years ago. They used a method of counting on fingers that goes up to 12 on one hand and 60 using both hands, so their numbering system was based on 60. 360 is 6 * 60 and also roughly how many days in a year.
Later societies inherited that from them along with 60 minutes in and hour.
Not that these are exclusive, but I thought it's a rounding of 365.25 days a year stemming from Egypt. 360 is a pretty useful number of degrees for a starry sky that changes ince a night.
I've always held opinion that ideal base for our day life computation is 12. It's close enough to 10, so most things would work just as well (like you just need to remember 2 more digits), but it's actually divisible by 3, 4, 6 which is a lot more useful than 5, compared to 10-base.
And many of the conversions between metric and imperial align with the Fibonacci sequence on any order of magnitude. 130km/h is roughly 80mph simply because the fibo sequence has 8 and 13.
Obviously not an emergent property but shows how these things were designed.
Author here. It's true that you'd need one more bit to represent a bit position in a word, like for shifts, but we're already vastly over-provisioned; even in 64-bit registers we're only using six of eight bits. (Plus, in a lot of places we'd have that extra bit around!)
Some hardware circuits are a bit nicer with power-of-two sizes but I don't think it's a huge difference, and hardware has to include weird stuff like 24-bit and 53-bit multipliers for floating-point anyway (which in this alternate world would be probably 28-bit and 60-bit?). Not sure a few extra gates would be a dealbreaker.
"DEC's 36-bit computers were primarily the PDP-6 and PDP-10 families, including the DECSYSTEM-10 and DECSYSTEM-20. These machines were known for their use in university settings and for pioneering work in time-sharing operating systems. The PDP-10, in particular, was a popular choice for research and development, especially in the field of artificial intelligence. "
"Computers with 36-bit words included the MIT Lincoln Laboratory TX-2, the IBM 701/704/709/7090/7094, the UNIVAC 1103/1103A/1105 and 1100/2200 series, the General Electric GE-600/Honeywell 6000, the Digital Equipment Corporation PDP-6/PDP-10 (as used in the DECsystem-10/DECSYSTEM-20), and the Symbolics 3600 series.
Smaller machines like the PDP-1/PDP-9/PDP-15 used 18-bit words, so a double word was 36 bits.
Not really - I worked on a DSP with 9-bit bytes in the 90's (largely because it was focused on MPEG decode for DVDs, new at the time) largely because memory was still very expensive and MPEG2 needed 9-bit frame difference calculations (most people do this as 16-bits these days but back then as I said memory was expensive and you could buy 9-bit parity RAM chips)
It had 512 72-bit registers and was very SIMD/VLIW, was probably the only machine ever with 81-bit instructions
The bit shifts were my first idea too where this would break down; but actually, 1-8 bit shifts would be just fine, and they can be encoded in 3 bits. 0 and 9 are special cases anyway (nop and full nonyte/nyte) for the programmer/compiler to become a tiny bit more clever; or use the shift-by-register instruction instead. T
This is not the case for 18 or 36 bits; I would imagine an architecture like this wouldn’t have a swap/swapb but a shuffle type instructions to specify where each nyte is expected to end up, encoded in 4x2 bit in the most generic case.
With this, I think I can get behind the 9-bit archs with the niceties described in the post..
reminds me of GA144 forthchips where it is effectively 20-bit architecture (vs 32-bit architecture). The instructions are 5-bit, and so 4 instructions can fit in 20-bits.
But with 5 valued electronics, Up, down, left, right and charm...
You could have the equivalent of 45-bit numbers ( 44 + parity ).
And you could have the operands of two 15 bit numbers and their result encoded in 9 quint-bits or quits. Go pro or go home.
Times have changed. Gnome people will yell at you for mentioning things as innocuous as pixel measurements. You'd probably be crucified for suggesting there's a hardware-correct way of handling address space.
Don't those issues only apply to odd number of bits, rather than non-power-of-2? For example, 12 isn't a power of 2 but doesn't suffer from any of those things you mentioned.
Because we have 8 bit bytes we are familiar with the famous or obvious cases multiples-of-8-bits ran out, and those cases sound a lot better with 12.5% extra bits. What's harder to see in this kind of thought experiment is what the famously obvious cases multiples-of-9-bits ran out would have been. The article starts to think about some of these towards the end, but it's hard as it's not immediately obvious how many others there might be (or, alternatively, why it'd be significantly different total number of issues than 8 bit bytes had). ChatGPT particularly isn't going to have a ton of training data about the problems with 9 bit multiples running out to hand feed you.
It also works in the reverse direction too. E.g. knowing networking headers don't even care about byte alignment for sub fields (e.g. a VID is 10 bits because it's packed with a few other fields in 2 bytes) I wouldn't be surprised if IPv4 would have ended up being 3 byte addresses = 27 bits, instead of 4*9=36, since they were more worried with small packet overheads than matching specific word sizes in certain CPUs.
Author here. Actually I doubt we'd have picked 27-bit addresses. That's about 134M addresses; that's less than the US population (it's about the number of households today?) and Europe was also relevant when IPv4 was being designed.
In any case, if we had chosen 27-bit addresses, we'd have hit exhaustion just a bit before the big telecom boom that built out most of the internet infrastructure that holds back transition today. Transitioning from 27-bit to I don't know 45-bit or 99-bit or whatever we'd choose next wouldn't be as hard as the IPv6 transition today.
When 32 bits were chosen it was because it was deemed a temporary thing for an experimental protocol, so there was no need to invest into proposed 128bit addressing by IIRC Vint Cerf (or 160 bit addresses of ITU/ISO protocols).
After all, we were supposed to switch off IPv4 in 1990...
Might have ended up with 27-bit. If you do not really expect personal computer usage and just want to essentially make some proof of concept of interoperability which you will later upgrade or replace.
Maybe there would have been push to change at some point as there would have been real limits in place.
>we'd have hit exhaustion just a bit before the big telecom boom that built out most of the internet infrastructure that holds back transition today
I think this does go both ways. It's hard to care about 3058, but it's nice that we started trying to solve y2k and 2038 while they were still merely painful. Wouldn't want a loop leading to a divide-by-zero in my warp drive.
The IPv4 networking case is especially weird to think about because the early internet didn't use classless-addressing before CIDR.
Thinking about the number of bits in the address is only one of the design parameters. The partitioning between network masks and host space is another design decision. The decision to reserve class D and class E space yet another. More room for hosts is good. More networks in the routing table is not.
Okay, so if v4 addresses were composed of four 9-bit bytes instead of four 8-bit octets, how would the early classful networks shaken out? It doesn't do a lot of good if a class C network is still defined by the last byte.
LLM dren also isn't going to provide anything on how wildly different the home computer revolution would have been with twice as big character ROMs; the personal computer revolution would have been with twice as big code pages 437, 850, and 1252 and an extra CGA attribute bit; the BBS era would have been with 9N1 telecommunications; ECMA-48 and ECMA-35 would have been with space for the C1 control characters with no need for alternative forms; ASCII and EBCDIC would have been without need for the national variants and room for some accented characters; and even how different the 6502 instruction set would have been.
With so many huge changes like those the alternate history by today would be far diverged from this universe.
The knock-on effect of EBCDIC having room for accented characters would have been the U.S.A. not changing a lot of placenames when the federal government made the GNIS in the 1970s and 1980s, for example. MS-DOS might have ended up with a 255-character command-tail limit, meaning that possibly some historically important people would never have been motivated to learn the response file form of the Microsoft LINK command. People would not have hit a 256-character limit on path lengths on DOS+Windows.
Teletext would never have needed national variants, would have had different graphics, would have needed a higher bitrate, might have lasted longer, and people in the U.K. would have possibly never seen that dog on 4-Tel. Octal would have been more convenient than hexadecimal, and a lot of hexadecimal programming puns would never have been made. C-style programming languages might have had more punctuation to use for operators.
Ð or Ç could have been MS-DOS drive letters. Microsoft could have spelled its name with other characters, and we could all be today reminiscing about µs-dos. The ZX Spectrum could have been more like the Oric. The FAT12 filesystem format would never have happened. dBase 2 files would have had bigger fields. People could have put more things on their PATHs in DOS, and some historically important person would perhaps have never needed to learn how to write .BAT files and gone on to a career in computing.
The Domain Name System would have had a significantly different history, with longer label limits, more characters, and possibly case sensitivity if non-English letters with quirky capitalization rules had been common in SBCS in 1981. EDNS0 might never have happened or been wildly different. RGB 5-6-5 encoding would never have happened; and "true colour" might have ended up as a 12-12-12 format with nothing to spare for an alpha channel. 81-bit or 72-bit IEEE 754 floating point might have happened.
"Multimedia" and "Internet" keyboards would not have bumped up against a limit of 127 key scancodes, and there are a couple of luminaries known for explaining the gynmastics of PS/2 scancodes who would have not had to devote so much of their time to that, and possibly might not have ended up as luminaries at all. Bugs in several famous pieces of software that occurred after 49.7 days would have either occurred much sooner or much later.
Actual intelligence is needed for this sort of science fiction alternative history construction.
Guess we should count our blessings that 7-bit bytes didn't become the de facto standard. Given that 7 bits is sufficient for ASCII and BCD, and the popularity of the IBM 1401 in the 1960's, that's not at all implausible. The alternate history might have had only 2^28 (268,435,456) unique IP4s. The cynic in me wants you to be sure to include the inevitable "We'd be better of with 10-bit bytes" headline in the 9-bit alternate history.
I've always taken it as a given that we ended up with 8-bits bytes because its the smallest power-of-two number of bits that accommodates ASCII and packed BCD. Back in the day, BCD mattered rather a lot. x86 has legacy BCD instructions, for example.
Author here. Really great comment; I've linked it from the OP. (Could do without the insults!) Most of the changes you point out sound... good? Maybe having fewer arbitrary limits would have sapped a few historically significant coders of their rage against the machine, but maybe it would have pulled in a few more people by being less annoying in general. On colors, I did mention that in the post but losing an alpha channel would be painful.
> The knock-on effect of EBCDIC having room for accented characters would have been the U.S.A. not changing a lot of placenames when the federal government made the GNIS in the 1970s and 1980s, for example.
I don't know about that, it had room for lots of accented characters with code pages. If that went unused, it probably would have also gone unused in the 9 bit version.
> Actual intelligence is needed for this sort of science fiction alternative history construction.
Why? We're basically making a trivia quiz, that benefits memorization far more than intelligence. And you actively don't want to get into the weeds of chaos-theory consequences or you forget the article you're writing.
That's an interesting argument about convenience discouraging interaction with the system. If everything just works, there's no need to tinker. If you stop tinkering, the world might miss out on some real magic.
If you're deciding between using 8 bits or 16 bits, you might pick 16 because 8 is too small. But making the same decision between 9 and 18 bits could lead to picking 9 because it's good enough at the time. So no I don't think there would be half as many cases. They'd be different cases.
That might've been better, actually. The author makes the mistake of "more time would've made this better", but we've had plenty of time to transition to IPv6. People simply don't because they are lazy and IPv4 works for them. More time wouldn't help that, any more than a procrastinating student benefits when the deadline for a paper gets extended.
But on the other hand, if we had run out sooner, perhaps IPv4 wouldn't be as entrenched and people would've been more willing to switch. Maybe not, of course, but it's at least a possibility.
The internet also fundamentally changed in the middle of the rollout. End user devices stopped being directly accessible because this was a security issue, they stopped being always online because they mostly run on battery now, and IP addresses costing money became a kind of barrier to spam and abuse.
Even if we could directly address every device on the internet, you'd still mostly want to run through a middle server anyway so you can send files and messages while the receiver device is sleeping, or to sync between multiple devices.
Pretty much the only loss was people self hosting servers, but as long as you aren't behind CGNAT you can just set up DDNS and be fine. Every ISP I've been with lets you opt out of CGNAT as well as pay for a static IP.
Author here. I kind of doubt it. Copied from a comment earlier:
I doubt we'd have picked 27-bit addresses. That's about 134M addresses; that's less than the US population (it's about the number of households today?) and Europe was also relevant when IPv4 was being designed.
In any case, if we had chosen 27-bit addresses, we'd have hit exhaustion just a bit before the big telecom boom that built out most of the internet infrastructure that holds back transition today. Transitioning from 27-bit to I don't know 45-bit or 99-bit or whatever we'd choose next wouldn't be as hard as the IPv6 transition today.
IPv4 was designed in 1981. The idea of every household in america having a computer in 1981 probably would have sounded insane. According to google there was only 213 hosts on the internet in 1981.
Notably the PDP 8 had 12 bit words (2x6) and the PDP 10 had 36 bit words (6x6)
Notably the PDP 10 had addressing modes where it could address a run of bits inside a word so it was adaptable to working with data from other systems. I've got some notes on a fantasy computer that has 48-bit words (fit inside a Javascript double!) and a mechanism like the PDP 10 where you can write "deep pointers" that have a bit offset and length that can even hang into the next word, with the length set to zero bits this could address UTF-8 character sequences. Think of a world where something like the PDP 10 inspired microcomputers, was used by people who used CJK characters and has a video system that would make the NeoGeo blush. Crazy I know.
This is what happens when you write articles with AI (the article specifically mentions ChatGPT).
The article says:
> A number of 70s computing systems had nine-bit bytes, most prominently the PDP-10
This is false. If you ask ChatGPT "Was the PDP-10 a 9 bit computer?" it says "Yes, the PDP-10 used a 36-bit word size, and it treated characters as 9-bit bytes."
But if you ask any other LLM or look it up on Wikipedia, you see that:
> Some aspects of the instruction set are unusual, most notably the byte instructions, which operate on bit fields of any size from 1 to 36 bits inclusive, according to the general definition of a byte as a contiguous sequence of a fixed number of bits.
Actually, the PDP-10 didn't have any byte size at all, it was a word-addressed machine. (An early attempt to implement C on this machine came a cropper because of this.) It did have a Load Byte and a Store Byte instruction, which allowed you to select the byte size. Common formats were Sixbit (self-explanatory), ASCII (5 7-bit bytes and an unused bit), and (more rarely, I think), 9-bit bytes.
My first machines were the IBM 7044 (36-bit word) and the PDP-8 (12-bit word), and I must admit to a certain nostalgia for that style of machine (as well as the fact that a 36-bit word gives you some extra floating-point precision), but as others have pointed out, there are good reasons for power-of-2 byte and word sizes.
Multics ran on Honeywell 6180 and DPS8/M machines. They had 36 bit words like the PDP-10. They also had instructions that would operate o in 6 or 9 bit characters in the word
What exactly is the argument here? Bigger numbers are bigger? But then we could also argue that by that logic, octets are better than 9-bit bytes because you need more bytes sooner and that gives you seven more bits over the additional one in 9-bit.
> Thank you to GPT 4o and o4 for discussions, research, and drafting.
This is just an argument for longer roads and can kicking. He thanks ChatGPT for "discussions, research, and drafting". A real friend would have talked him out of posting this.
The elephant in the room nobody talks about is silicon cost (wires, gates, multiplexirs, AND and OR gates etc). With a 4th lane, you may as well go straight to 16 bits to a byte.
Would you lay out your logic (pun intended) a bit more? In what cases does doing from 8-bit bytes to 9-bit bytes result in something like a 2X penalty?
One possibility would be bit-indexed addressing. For the 9-bit case, yes, such an index would need 4 bits. If one wanted to keep nice instruction set encoding nice and clean, that would result in an underutilized 4th bit. Coming up with a more complex encoding would cost silicon.
The original meaning of byte was a variable number of bits to represent a character, joined into a larger word that reflected the machine's internal structure. The IBM STRETCH machines could change how many bits per character. This was originally only 1-6 bits [1] because they didn't see much need for 8 bit characters and it would have forced them to choose 64 bit words, when 60 bit words was faster and cheaper. A few months later they had a change of heart after considering how addressing interacted with memory paging [2] and added support for 8 bit bytes for futureproofing and 64 bit words, which became dominant with the 360.
> IPv4 would have had 36-bit addresses, about 64 billion total. That would still be enough right now, and even with continuing growth in India and Africa it would probably be enough for about a decade more. [ ... ] When exhaustion does set in, it would plausibly at a time where there's not a lot of growth left in penetration, population, or devices, and mild market mechanisms instead of NATs would be the solution.
I think it's actually better to run out of IPv4 addresses before the world is covered!
The later-adopting countries that can't get IPv4 addresses will just start with IPv6 from the beginning. This gives IPv6 more momentum. In big, expensive transitions, momentum is incredibly helpful because it eliminates that "is this transition even really happening?" collective self-doubt feeling. Individual members of the herd feel like the herd as a whole is moving, so they ought to move too.
It also means that funds available for initial deployment get spent on IPv6 infrastructure, not IPv4. If you try to transition after deployment, you've got a system that mostly works already and you need to cough up more money to change it. That's a hard sell in a lot of cases.
Author here. My argument in the OP was that we maybe would never need to transition. With 36-bit addresses we'd probably get all the people and devices to fit. While there would still be early misallocation (hell, Ford and Mercedes still hold /8s) that could probably be corrected by buying/selling addresses without having to go to NATs and related. An even bigger address space might be required in some kind of buzzword bingo AI IoT VR world but 36 bits would be about enough even with the whole world online.
And nothing like FOMO of developing markets not being able to access a product to drive VPs and CEOs to care about ensuring IPv6 support works with their products.
Readit News
This was done for graphics reasons, native antialiasing if I understand it. The cpu can't use it. it still only sees 8-bit bytes.
https://www.youtube.com/watch?v=DotEVFFv-tk (Kaze Emanuar - The Nintendo 64 has more RAM than you think)
To summarize the relevant part of the video. The RDP wants to store pixel color in 18 bits 5 bits red 5 bits blue 5 bits green 3 bits triangle coverage it then uses this coverage information to calculate a primitive but fast antialiasing. so SGI went with two 9-bit bytes for each pixel and magic in the RDP(remember it's also the memory controller) so the cpu sees the 8-bit bytes it expects.
Memory on N64 is very weird it is basicly the same idea as PCIE but for the main memory. PCI big fat bus that is hard to speed up. PCIE small narrow super fast bus. So the cpu was clocked at 93 MHz but the memory was a 9-bit bus clocked at 250 MHz. They were hoping this super fast narrow memory would be enough for everyone but having the graphics card also be the memory controller proved to make the graphics very sensitive to memory load. to the point that the main thing that helps a n64 game get higher frame rate is to have the cpu do as few memory lookups as possible. which in practical terms means having it idle as much as possible. This has a strange side effect that while a common optimizing operation for most architectures is to trade calculation for memory(unroll loops, lookup tables...) on the N64 it can be the opposite. If you can make your code do more calculation with less memory you can utilize the cpu better because it is mostly sitting idle to give the RDP most of the memory bandwidth.
That really depends. A cache miss adds eons of latency thus is far worse than doing a few extra cycles of work but depending on the workload the reorder buffer might manage to negate the negative impact entirely. Memory bandwidth as a whole is also incredibly scarce relative to CPU clock cycles.
The only time it's a sure win is if you trade instruction count for data in registers or L1 cache hits but those are themselves very scarce resources.
In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers. It doesn't address more than 4 GB of anything ever
Later societies inherited that from them along with 60 minutes in and hour.
Not that these are exclusive, but I thought it's a rounding of 365.25 days a year stemming from Egypt. 360 is a pretty useful number of degrees for a starry sky that changes ince a night.
1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, and 60
Obviously not an emergent property but shows how these things were designed.
Some hardware circuits are a bit nicer with power-of-two sizes but I don't think it's a huge difference, and hardware has to include weird stuff like 24-bit and 53-bit multipliers for floating-point anyway (which in this alternate world would be probably 28-bit and 60-bit?). Not sure a few extra gates would be a dealbreaker.
Basically all FIFOs or addressable memory works far nicer with power-of-two sizes.
Deleted Comment
"DEC's 36-bit computers were primarily the PDP-6 and PDP-10 families, including the DECSYSTEM-10 and DECSYSTEM-20. These machines were known for their use in university settings and for pioneering work in time-sharing operating systems. The PDP-10, in particular, was a popular choice for research and development, especially in the field of artificial intelligence. "
"Computers with 36-bit words included the MIT Lincoln Laboratory TX-2, the IBM 701/704/709/7090/7094, the UNIVAC 1103/1103A/1105 and 1100/2200 series, the General Electric GE-600/Honeywell 6000, the Digital Equipment Corporation PDP-6/PDP-10 (as used in the DECsystem-10/DECSYSTEM-20), and the Symbolics 3600 series.
Smaller machines like the PDP-1/PDP-9/PDP-15 used 18-bit words, so a double word was 36 bits.
Oh wait. Its already been done.
It had 512 72-bit registers and was very SIMD/VLIW, was probably the only machine ever with 81-bit instructions
If memory serves, I had a Creative Labs DXR2 that I almost immediately regretted.
PDP-10 could do 9-bit (or 7, or 6) bytes into 36-bit words. It seems like something that would be fun for 1-2 days.
This is not the case for 18 or 36 bits; I would imagine an architecture like this wouldn’t have a swap/swapb but a shuffle type instructions to specify where each nyte is expected to end up, encoded in 4x2 bit in the most generic case.
With this, I think I can get behind the 9-bit archs with the niceties described in the post..
Then they decided to abandon their indigenous technology in favour of copying Western designs
If you don't believe me, just ask Paula Bean.
You could have the equivalent of 45-bit numbers ( 44 + parity ). And you could have the operands of two 15 bit numbers and their result encoded in 9 quint-bits or quits. Go pro or go home.
Deleted Comment
It also works in the reverse direction too. E.g. knowing networking headers don't even care about byte alignment for sub fields (e.g. a VID is 10 bits because it's packed with a few other fields in 2 bytes) I wouldn't be surprised if IPv4 would have ended up being 3 byte addresses = 27 bits, instead of 4*9=36, since they were more worried with small packet overheads than matching specific word sizes in certain CPUs.
In any case, if we had chosen 27-bit addresses, we'd have hit exhaustion just a bit before the big telecom boom that built out most of the internet infrastructure that holds back transition today. Transitioning from 27-bit to I don't know 45-bit or 99-bit or whatever we'd choose next wouldn't be as hard as the IPv6 transition today.
After all, we were supposed to switch off IPv4 in 1990...
Maybe there would have been push to change at some point as there would have been real limits in place.
I think this does go both ways. It's hard to care about 3058, but it's nice that we started trying to solve y2k and 2038 while they were still merely painful. Wouldn't want a loop leading to a divide-by-zero in my warp drive.
Thinking about the number of bits in the address is only one of the design parameters. The partitioning between network masks and host space is another design decision. The decision to reserve class D and class E space yet another. More room for hosts is good. More networks in the routing table is not.
Okay, so if v4 addresses were composed of four 9-bit bytes instead of four 8-bit octets, how would the early classful networks shaken out? It doesn't do a lot of good if a class C network is still defined by the last byte.
With so many huge changes like those the alternate history by today would be far diverged from this universe.
The knock-on effect of EBCDIC having room for accented characters would have been the U.S.A. not changing a lot of placenames when the federal government made the GNIS in the 1970s and 1980s, for example. MS-DOS might have ended up with a 255-character command-tail limit, meaning that possibly some historically important people would never have been motivated to learn the response file form of the Microsoft LINK command. People would not have hit a 256-character limit on path lengths on DOS+Windows.
Teletext would never have needed national variants, would have had different graphics, would have needed a higher bitrate, might have lasted longer, and people in the U.K. would have possibly never seen that dog on 4-Tel. Octal would have been more convenient than hexadecimal, and a lot of hexadecimal programming puns would never have been made. C-style programming languages might have had more punctuation to use for operators.
Ð or Ç could have been MS-DOS drive letters. Microsoft could have spelled its name with other characters, and we could all be today reminiscing about µs-dos. The ZX Spectrum could have been more like the Oric. The FAT12 filesystem format would never have happened. dBase 2 files would have had bigger fields. People could have put more things on their PATHs in DOS, and some historically important person would perhaps have never needed to learn how to write .BAT files and gone on to a career in computing.
The Domain Name System would have had a significantly different history, with longer label limits, more characters, and possibly case sensitivity if non-English letters with quirky capitalization rules had been common in SBCS in 1981. EDNS0 might never have happened or been wildly different. RGB 5-6-5 encoding would never have happened; and "true colour" might have ended up as a 12-12-12 format with nothing to spare for an alpha channel. 81-bit or 72-bit IEEE 754 floating point might have happened.
"Multimedia" and "Internet" keyboards would not have bumped up against a limit of 127 key scancodes, and there are a couple of luminaries known for explaining the gynmastics of PS/2 scancodes who would have not had to devote so much of their time to that, and possibly might not have ended up as luminaries at all. Bugs in several famous pieces of software that occurred after 49.7 days would have either occurred much sooner or much later.
Actual intelligence is needed for this sort of science fiction alternative history construction.
I've always taken it as a given that we ended up with 8-bits bytes because its the smallest power-of-two number of bits that accommodates ASCII and packed BCD. Back in the day, BCD mattered rather a lot. x86 has legacy BCD instructions, for example.
I don't know about that, it had room for lots of accented characters with code pages. If that went unused, it probably would have also gone unused in the 9 bit version.
> Actual intelligence is needed for this sort of science fiction alternative history construction.
Why? We're basically making a trivia quiz, that benefits memorization far more than intelligence. And you actively don't want to get into the weeds of chaos-theory consequences or you forget the article you're writing.
I don't think this is enough of a reason, though.
Or we would have had 27 bit addresses and ran into problems sooner.
But on the other hand, if we had run out sooner, perhaps IPv4 wouldn't be as entrenched and people would've been more willing to switch. Maybe not, of course, but it's at least a possibility.
Even if we could directly address every device on the internet, you'd still mostly want to run through a middle server anyway so you can send files and messages while the receiver device is sleeping, or to sync between multiple devices.
Pretty much the only loss was people self hosting servers, but as long as you aren't behind CGNAT you can just set up DDNS and be fine. Every ISP I've been with lets you opt out of CGNAT as well as pay for a static IP.
Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.
https://www.internetsociety.org/blog/2016/09/final-report-on...
Some more interesting history reading here:
https://datatracker.ietf.org/doc/html/rfc33
I doubt we'd have picked 27-bit addresses. That's about 134M addresses; that's less than the US population (it's about the number of households today?) and Europe was also relevant when IPv4 was being designed. In any case, if we had chosen 27-bit addresses, we'd have hit exhaustion just a bit before the big telecom boom that built out most of the internet infrastructure that holds back transition today. Transitioning from 27-bit to I don't know 45-bit or 99-bit or whatever we'd choose next wouldn't be as hard as the IPv6 transition today.
https://en.wikipedia.org/wiki/Six-bit_character_code#DEC_SIX...
Notably the PDP 8 had 12 bit words (2x6) and the PDP 10 had 36 bit words (6x6)
Notably the PDP 10 had addressing modes where it could address a run of bits inside a word so it was adaptable to working with data from other systems. I've got some notes on a fantasy computer that has 48-bit words (fit inside a Javascript double!) and a mechanism like the PDP 10 where you can write "deep pointers" that have a bit offset and length that can even hang into the next word, with the length set to zero bits this could address UTF-8 character sequences. Think of a world where something like the PDP 10 inspired microcomputers, was used by people who used CJK characters and has a video system that would make the NeoGeo blush. Crazy I know.
The article says:
> A number of 70s computing systems had nine-bit bytes, most prominently the PDP-10
This is false. If you ask ChatGPT "Was the PDP-10 a 9 bit computer?" it says "Yes, the PDP-10 used a 36-bit word size, and it treated characters as 9-bit bytes."
But if you ask any other LLM or look it up on Wikipedia, you see that:
> Some aspects of the instruction set are unusual, most notably the byte instructions, which operate on bit fields of any size from 1 to 36 bits inclusive, according to the general definition of a byte as a contiguous sequence of a fixed number of bits.
-- https://en.wikipedia.org/wiki/PDP-10
So PDP-10 didn't have 9-bit bytes, but could support them. Characters were typically 6 bytes, but 7-bit and 9-bit characters were also sometimes used.
My first machines were the IBM 7044 (36-bit word) and the PDP-8 (12-bit word), and I must admit to a certain nostalgia for that style of machine (as well as the fact that a 36-bit word gives you some extra floating-point precision), but as others have pointed out, there are good reasons for power-of-2 byte and word sizes.
AFAIK only Multics used 4 9-byte characters on the PDP-10s; I believe 5 7-bit ASCII characters fairly common later on in the PDP7/10 lifetime.
For characters, 6 bits also was used at times, for example in its disk format. There, a severely limited character set wasn’t problematic.
> Thank you to GPT 4o and o4 for discussions, research, and drafting.
That explains a lot.
Dead Comment
One possibility would be bit-indexed addressing. For the 9-bit case, yes, such an index would need 4 bits. If one wanted to keep nice instruction set encoding nice and clean, that would result in an underutilized 4th bit. Coming up with a more complex encoding would cost silicon.
What other cases are you thinking of?
Self-correction: In what cases does going from 8-bit bytes to 9-bit bytes result in a penalty, and how much is it?
[1] https://web.archive.org/web/20170404160423/http://archive.co...
[2] https://web.archive.org/web/20170404161611/http://archive.co...
I think it's actually better to run out of IPv4 addresses before the world is covered!
The later-adopting countries that can't get IPv4 addresses will just start with IPv6 from the beginning. This gives IPv6 more momentum. In big, expensive transitions, momentum is incredibly helpful because it eliminates that "is this transition even really happening?" collective self-doubt feeling. Individual members of the herd feel like the herd as a whole is moving, so they ought to move too.
It also means that funds available for initial deployment get spent on IPv6 infrastructure, not IPv4. If you try to transition after deployment, you've got a system that mostly works already and you need to cough up more money to change it. That's a hard sell in a lot of cases.