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.
willis936 · 33m ago
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.
gxs · 17m ago
Or 60 minutes in an hour
1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, and 60
AnotherGoodName · 1h ago
Factorio logic applies as always - powers of 2 for trains belts etc. makes evenly splitting resources trivial.
phkahler · 1h ago
Good points! I was going to say I think 12 bits would have been a nice choice, but yeah optimizing for circuits is kind of important.
ForOldHack · 13m ago
Brillant, that 36 bits would be three bytes.
"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.
Taniwha · 1h ago
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
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.
percentcer · 1h ago
on, off, and the other thing
tyingq · 1h ago
hi-z is one choice. Though I don't know how well that does past a certain speed.
duskwuff · 33m ago
It works poorly at any speed. Hi-Z is an undriven signal, not a specific level, so voltage-driven logic like (C)MOS can't distinguish it from an input that's whatever that signal happens to be floating at. In current-driven logic like TTL or ECL, it's completely equivalent to a lack of current.
ForOldHack · 4m ago
Using 8 way quadrature and high-z, you have 16 values packed into 1 quasi-hexalogic gate. May your hydration prove fruitful.
mzajc · 53m ago
null :)
mouse_ · 24m ago
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.
zamadatix · 3h ago
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.
oasisbob · 50m ago
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.
marcosdumay · 1h ago
Well, there should be half as many cases of multiples-of-9-bits ran out than for multiples-of-8-bits.
I don't think this is enough of a reason, though.
foxglacier · 30m ago
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.
PaulHoule · 1h ago
I thought the PDP 10 had 6-bit bytes, or at least 6-bit characters
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.
jacquesm · 19m ago
You are correct. The Sperry-Univac 1100 series though did have 36 bit words and 9 bit bytes.
xdennis · 1h ago
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.
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.
vincent-manis · 9m ago
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.
adrianmonk · 25m ago
> 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.
elcritch · 18m ago
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.
bawolff · 2h ago
> But in a world with 9-bit bytes IPv4 would have had 36-bit addresses, about 64 billion total.
Or we would have had 27 bit addresses and ran into problems sooner.
bigstrat2003 · 2h ago
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.
dmitrygr · 2h ago
> simply don't because they are lazy and IPv4 works for them
Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.
zamadatix · 2h ago
Most of the "unwanted" things in IPv6 aren't actually required by IPv6. Temporary addresses, most of the feature complexity in NDP, SLAAC, link-local addresses for anything but the underlying stuff that happens automatically, "no NAT, you must use PD", probably more I'm forgetting. Another large portion is things related to trying to be dual stack like concurrent resolutions/requests, various forms of tunneling, NAT64, and others.
They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.
yjftsjthsd-h · 1h ago
I'm not convinced that's true in practice. I would like to have an IPv6 network that I can connect Android devices to and on which I can connect to the devices by their host name. Android refuses to support DHCPv6, telling the local DNS server about SLAAC addresses involves awful and unreliable hacks, mDNS requires extra daemons and resolver configuration. I looked at just copying my v4 stack to v6; it doesn't appear possible.
zamadatix · 2m ago
Android was nearly my real life example of "IPv6 doesn't mandate anything be different, some guy at Android just likes doing things that way more". I.e. the problem is there is some dude (I forget his name) over on the Android side who has a hard on against supporting DHCPv6 because he likes what forcing SLAAC implies on carriers, not that IPv6 said it had to be so.
JoshTriplett · 1h ago
> They're almost always deployed though because people end up liking the ideas.
Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.
Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
zamadatix · 5m ago
> For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.
On IPv4 I assume you're doing something which boils down to:
ip addr add 192.168.1.100/24 dev eth0
ip route add default via 192.168.1.1 dev eth0
So what's the different with:
ip -6 addr add 2001:db8:abcd:0012::1/64 dev eth0
ip -6 route add default via 2001:db8:abcd:0012::1 dev eth0
Is different? If you're also doing a static ARP to be "fully" static then you've probably also got an additional config which boils down to something akin to:
ip neigh add 192.168.1.50 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent
Which maps to:
ip -6 neigh add 2001:db8:abcd:0012::2 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent
In both cases you either need to locally respond to ARP/ND still or also statically configure the rest of the devices in the subnet, but it should be identical outside the address size.
> Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
I have a strong aversion to AWS, but if there is anything more difficult about this than it takes to do for IPv4 it's exactly what I meant about IPv6 not requiring any of this, rather the implementers (usually carriers or providers) really wanting to enforce some of these other dynamic things as part of rolling it out (because it's easier on them to use the whizz-bang options, not because IPv6 dictated it).
hinkley · 4m ago
If it had been more urgent to move off of IPv4 a lot of those riders would have either been eliminated or not thought of yet. We’d be looking at 54 bit addressing and planning IPv7 to have 108.
codebje · 33m ago
If you "simply" added more bits to IPv4, you'd have a transition every bit (ahaha, ahem, sorry) as complex as the transition to IPv6 anyway, because IPv4+ would be a new protocol in exactly the same way as IPv6. A new DNS response record. Updates to routing protocols. New hardware. New software.
And no interoperability between the two without stateful network address translation.
bigstrat2003 · 1h ago
I've run IPv6 on both corporate and home networks. Whether or not the additions were merited, they are not a formidable challenge for any reasonably-skilled admin. So no, I don't think that the reason you gave suffices as an excuse for why so many still refuse to deploy IPv6.
ay · 1h ago
The first transition was to IPv4, and it was reportedly (I wasn’t in the workforce yet :-) relatively easy…
If we had 9-bit bytes and 36-bit words, then for the same hardware budget, we'd have 12.5% fewer bytes/words of memory. It seems likely that despite the examples in the article, in most cases we'd very likely not make use of the extra range as 8/32 is enough for most common cases. And so in all those cases where 8/32 is enough, the tradeoff isn't actually an advantage but instead is a disadvantage - 9/36 gives less addressable memory, with the upper bits generally unused.
smallstepforman · 2h ago
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.
pratyahava · 2h ago
This must be the real reason of using 8-bit. But then why did they make 9-bit machine instead of 16-bit?
AlotOfReading · 1h ago
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.
Not a very good argument. Yes, more bytes in situations where we’ve been constrained would have relieved the constraint… but it would eventually come. Even IP addresses… we don’t need an IP per person… IPv6 will be IPs for every device… multiple even… including an interplanetary network.
layer8 · 9m ago
It would also make Base64 a bit simpler (pun intended), at the cost of a little more overhead (50% instead of 33%).
hinkley · 3m ago
We likely wouldn’t use base64 at all in that case, but Base256. But also more of Europe would have fit in ASCII and Unicode would be a few years behind.
NelsonMinar · 2h ago
This is ignoring the natural fact that we have 8 bit bytes because programmers have 8 fingers.
classichasclass · 1h ago
No, we still have 10. Real programmers think in octal. ;)
ISO reserves programmers thumbs to LGTM on pull requests
Keyframe · 3h ago
Yeah, but hear me out - 10-bit bytes!
pdpi · 2h ago
One of the nice features of 8 bit bytes is being able to break them into two hex nibbles. 9 bits breaks that, though you could do three octal digits instead I suppose.
10 bit bytes would give us 5-bit nibbles. That would be 0-9a-v digits, which seems a bit extreme.
tzs · 28m ago
10-bit has sort of been used. The General Instrument CP1600 family of microprocessors used 16-bit words but all of the instruction opcodes only used 10 bits, with the remaining 6 bits reserved for future use.
GI made 10-bit ROMs so that you wouldn't waste 37.5% of your ROM space storing those 6 reserved bits for every opcode. Storing your instructions in 10-bit ROM instead of 16-bit ROM meant that if you needed to store 16-bit data in your ROM you would have to store it in two parts. They had a special instruction that would handle that.
The Mattel Intellivision used a CP1610 and used the 10-bit ROM.
The term Intellivision programmers used for a 10-bit quantity was "decle". Half a decle was a "nickel".
jacquesm · 17m ago
That's a very interesting bit of lore, I knew those were peculiar CPUs but I never know about these details, thank you!
int_19h · 2h ago
Clearly it should be 12 bits, that way you could use either 3 hex digits or 4 octal ones. ~
monocasa · 2h ago
Alternate world where the pdp-8 evolved into our modern processors.
pratyahava · 2h ago
Crockford base32 would be great. it is 0–9, A–Z minus I, L, O, U.
pdpi · 2h ago
The moment you feel the need to skip letters due to propensity for errors should also be the moment you realise you're doing something wrong, though. It's kind of fine if you want a case insensitive encoding scheme, but it's kind of nasty for human-first purposes (e.g. in source code).
titzer · 2h ago
10 bit bytes would be awesome! Think of 20 bit microcontrollers and 40 bit workstations. 40 bits makes 5 byte words, that'd be rad. Also, CPUs could support "legacy" 32 bit integers and use a full 8 bits for tags, which are useful for implementing dynamic languages.
phpnode · 29m ago
why stop there? 16-bit bytes would be so much cleaner
iosjunkie · 2h ago
No! No, no, not 10! He said 9. Nobody's comin' up with 10. Who processing with 10 bits? What’s the extra bit for? You’re just wastin’ electrons.
Waterluvian · 2h ago
Uh oh. Looks like humanity has been bitten by the bit byte bug.
pratyahava · 2h ago
deleted
relevant_stats · 1h ago
I really don't get why some people like to pollute conversations with LLMs answers. Particularly when they are as dumb as your example.
What's the point?
svachalek · 1h ago
Same, we all have access to the LLM too, but I go to forums for human thoughts.
pratyahava · 1h ago
ok, agree with your point, i should have got the numbers from chatgpt and just put them in the comment with my words, i was just lazy to calculate how much profit we would have with 10-bit bytes.
pratyahava · 1h ago
umm, i guess most of the article is made by llm, so i did not see it as a sin, but for other cases i agree, copy-pasting from llm is crap
CyberDildonics · 57s ago
On hacker news the comments need to be substance written by a person, but the articles can be one word title clickbait written by LLMs.
monocasa · 3h ago
Ohh, and then we could write the digits in octal.
Interestingly, the N64 internally had 9 bit bytes, just accesses from the CPU ignored one of the bits. This wasn't a parity bit, but instead a true extra data bit that was used by the GPU.
ethan_smith · 2h ago
The N64's Reality Display Processor actually used that 9th bit as a coverage mask for antialiasing, allowing per-pixel alpha blending without additional memory lookups.
monocasa · 2h ago
As well as extra bits in the Z buffer to give it a 15.3 fixed point format.
crazygringo · 1h ago
It's an interesting observation that 2^16 = 65K is a number that isn't quite big enough for things it's mostly big enough for, like characters.
And that 2^32 = 4B is similarly awkwardly not quite big enough for global things related to numbers of people, or for second-based timestamps.
But a 9th bit isn't going to solve those things either. The real problem is that powers-of-two-of-powers-of-two, where we jump from 256 to 65K to 4B to 18QN (quintillion), are just not fine-grained enough for efficient usage of space.
It might be nice if we could also have 2^12=4K, 2^24=16M, and 2^48=281T as more supported integer bit lengths used for storage both in memory and on disk. But, is it really worth the effort? Maybe in databases? Obviously 16M colors has a long history, but that's another example where color banding in gradients makes it clear where that hasn't been quite enough either.
kyralis · 1h ago
"We've guessed wrong historically on data sizes, and if we had 9 bit bytes those guesses (if otherwise unchanged) would have been less wrong, so 9 bit bytes would be better!" is an extremely tenuous argument. Different decisions would have been made.
We need to be better at estimating require sizes, not trying to trick ourselves into accomplishing that by slipping in an extra bit to our bytes.
folsom · 3h ago
I don't know what if we ended up with a 27 bit address space?
As far as ISPs competing on speeds in the mid 90s, for some reason it feels like historical retrospectives are always about ten years off.
brudgers · 1h ago
I'm writing this on a four-year-old Macbook Pro and it only has 16 GB of RAM. Server-class machines would still need to address more memory than that, but they're usually running specialized software or virtualizing; databases and hypervisors are already tricky code and segmentation wouldn't be the end of the world.
Because, I have a ten year old Dell laptop with 40GB of RAM, 16GB seems like an arbitrary limitation, an engineering compromise, or something like that.
I don’t see how it is a result of 8 bit bytes because 64bits has a lot of address space.
And because my laptop is running Windows 10 currently and ram Ubuntu before that, ordinary operating systems are sufficient.
—-
Also ECC RAM is 9 bits per byte.
LarMachinarum · 1h ago
while none of the arguments of the article came even close to being convincing or to balancing out the disadvantages of a non-power-of-two orientation, there actually is one totally different argument/domain where the 9 bit per byte thing would hold true, that is: ECC bits in consumer devices (as opposed to just on servers):
The fact that Intel managed to push their shitty market segmentation strategy of only even supporting ECC RAM on servers has rather nefarious and long-lasting consequences.
alphazard · 2h ago
When you stop to think about it, it really doesn't make sense to have memory addresses map to 8-bit values, instead of bits directly. Storage, memory, and CPUs all deal with larger blocks of bits, which have names like "pages" and "sectors" and "words" depending on the context.
If accessing a bit is really accessing a larger block and throwing away most of it in every case, then the additional byte grouping isn't really helping much.
SpaceNoodled · 2h ago
It makes sense for the address to map to a value the same width as the data bus.
A one-bit wide bus ... er, wire, now, I guess ... Could work just fine, but now we are extremely limited with the number of operations achievable, as well as the amount of addressable data: an eight-bit address can now only reference a maximum of 32 bytes of data, which is so small as to be effectively useless.
alphazard · 1h ago
If each memory address mapped to a CPU word sized value, that would make sense, and that is closer to the reality of instructions reading a word of memory at a time. Instead of using the CPU word size as the smallest addressable value, or the smallest possible value (a bit) as the smallest addressable value, we use a byte.
It's an arbitrary grouping, and worse, it's rarely useful to think in terms of it. If you are optimizing access patterns, then you are thinking in terms of CPU words, cache line sizes, memory pages, and disk sectors. None of those are bytes.
wmf · 1h ago
Byte addressing is really useful for string handling.
nayuki · 1h ago
Today, we all agree that "byte" means 8 bits. But half a century ago, this was not so clear and the different hardware manufacturers were battling it out with different sized bytes.
A reminder of that past history is that in Internet standards documents, the word "octet" is used to unambiguously refer to an 8-bit byte. Also, "octet" is the French word for byte, so a "gigaoctet (Go)" is a gigabyte (GB) in English.
(Now, if only we could pin down the sizes of C/C++'s char/short/int/long/long-long integer types...)
gnabgib · 13m ago
An octet is unambiguously Latin for 8 of something; instruments, players, people, bytes, spider's legs, octopus' arms, molecules (see: octane).
Octad/octade was unambiguously about 8 bit bytes, but fell out of popular usage.
Nevermark · 1h ago
1 extra (literally) odd bit would require a lot of changes...
What if instead of using single bytes, we used "doublebytes"?
8-bit software continues to work, while new 16-bit "doublebyte" software gets 256x the value capacity, instead of a meager 2x.
Nobody will ever need more byte space than that!
Without requiring any changes to CPU/GPU, RAM, SSD, Ethernet, WiFi ...
Magic. :)
Retr0id · 2h ago
Aside from memory limits, one of the problems with 32-bit pointers is that ASLR is weakened as a security mitigation - there's simply fewer bits left to randomise. A 36-bit address space doesn't improve on this much.
64-bit pointers are pretty spacious and have "spare" bits for metadata (e.g. PAC, NaN-boxing). 72-bit pointers are even better I suppose, but their adoption would've come later.
AlotOfReading · 58m ago
ASLR has downsides as well. The address sanitizers have a shadow memory overhead that depends on the entropy in the pointer. If you have too much entropy, it becomes impossible for the runtime linker to map things correctly. Generally they'll just disable ASLR when they start, but it's one of the problems you'd have to solve to use them in production like ubsan even though that'd be extremely useful.
montag · 51m ago
Nah…We would have attempted to squeeze even bigger things into 18- and 36-bit address spaces that would have been equally short-sighted. But this is a tragedy of successes :)
SlowTao · 2h ago
Can you imagine the argument for 8bit bytes if we still lived in the original 6bit world of the 1950s?
A big part of the move to 8bit systems was that it allowed expanded text systems with letter casing, punctuation and various ASCII stuff.
We could move to the world of Fortran 36bit if really needed and solve all these problems while introducing a problem called Fortran.
LegionMammal978 · 2h ago
There was already more than enough space for characters with 12-bit systems like the PDP-8. If anything, the convergence on 8-bit words just made it more efficient to use 7-bit codepages like ASCII.
consp · 2h ago
As the UTF encodings have shown you can put any encoding in any bitform if need be.
zokier · 2h ago
Another interesting thought experiment would what if we went down to 6 bit bytes instead? Then the common values probably would be 24 and especially 48 bits (4 and 8 bytes), but 36 bit values might have appeared also in some places. In many ways 6 bit bytes would have had similar effect than 9 bit bytes; 18 and 36 bits would have been 3 and 6 bytes instead of 2 and 4 bytes. Notably with 6 bit bytes text encoding would have needed to be multibyte from the get-go, which might have been significant benefit (12 bit ASCII?)
wmf · 1h ago
Some early mainframes used 6-bit characters which is why they didn't have lowercase.
sedatk · 1h ago
Our capability to mispredict wouldn't have been different. We would have still picked the wrong size, and got stuck with scaling problems.
nottorp · 2h ago
Of course, if that happens we'll get an article demanding 10-bit bytes.
Got to stop somewhere.
jayd16 · 3h ago
I guess nibbles would be 3 bits and you'd 3 per byte?
TruffleLabs · 2h ago
PDP-8 has a 12-bit word size
js8 · 2h ago
I have thought for fun about a little RISC microcomputer with 6-bit bytes, and 4-byte words (12 MiB of addressable RAM). I think 6-bit bytes would have been great at a point in history, and in something crazy fun like Minecraft. (It's actually interesting question, if we were to design early microprocessors with today's knowledge of HW methods, things like RISC, caches or pipelining, what would we do differently?)
FrankWilhoit · 4h ago
That's what the PDP-10 community was saying decades ago.
Dwedit · 1h ago
Many old 8-bit processors was basically 9-bit processors once you considered the carry flag.
kazinator · 2h ago
36 bit addresses would be better than 32, but I like being able to store a 64 bit double or pointer or integer in a word using NaN tagging (subject to the limitation that only 48 bits of the pointer are significant).
consp · 2h ago
Funny thing is we sort-of got 36bit addressing mainstream with PAE in the 32bit x86 age.
kazinator · 1h ago
We sort of got 16 + 4 = 20 bit addressing in the 16 bit x86 age too.
labrador · 1h ago
At the end: "Thank you to GPT 4o and o4 for discussions, research, and drafting."
At first I thought that was a nice way to handle credit, but on further thought I wonder if this is necessary because the base line assumption is that everyone is using LLMs to help them write.
xandrius · 1h ago
Yeah, I don't remember ever thanking the spellchecker anything in the past. Maybe we are kinder to technology nowadays that we even credit it?
Thank you to Android for mobile Internet connectivity, browsing, and typing.
labrador · 1h ago
A counter point is that googling "thank you linux" turns up a lot of hits. "thank you linux for opening my eyes to a bigger world" is a typical comment.
svachalek · 1h ago
As soon as that's my baseline assumption, I think I'm done with the internet. I can get LLM slop on my own.
labrador · 1h ago
I thought the article was well written. I'm assuming the author did most of the writing because it didn't sound like AI slop. I also assume he meant he uses AI to assist, not as the main driver.
jacquesm · 15m ago
It really wasn't well written. I contains factual errors that stand out like lighthouses showing the author had an idea about an article but doesn't actually know the material.
apt-apt-apt-apt · 1h ago
We may have been stuck with slower, more expensive machines for 40+ years while computers that couldn't fully use the higher limits wasted time and energy.
cwmoore · 9m ago
“It goes up to 1011!”
kazinator · 2h ago
Problem is, not only did we have decades of C code that unnecessarily assumed 8/16/32, this all-the-world-is-a-VAX view is now baked into newer languages.
C is good for portability to this kind of machine. You can have a 36 bit int (for instance), CHAR_BIT is defined as 9 and so on.
With a little bit of extra reasoning, you can make the code fit different machines sizes so that you use all the available bits.
was that assumption in C code really unnecessary? i suppose it made many things much easier.
kazinator · 1h ago
In my experience, highly portable C is cleaner and easier to understand and maintain than C which riddles abstract logic with dependencies on the specific parameters of the abstract machine.
Sometimes the latter is a win, but not if that is your default modus operandi.
Another issue is that machine-specific code that assumes compiler and machine characteristics often has outright undefined behavior, not making distinctions between "this type is guaranteed to be 32 bits" and "this type is guaranteed to wrap around to a negative value" or "if we shift this value 32 bits or more, we get zero so we are okay" and such.
There are programmers who are not stupid like this, but those are the ones who will tend to reach for portable coding.
pratyahava · 1h ago
yep, i remember when i tried coding for some atmega, i was wondering "how big are int and uint?" and wanted the types names to always include the size like uint8. but also there is char type, which should become char8 which looks even more crazy.
protocolture · 30m ago
Yeah uh, moving ISP's from IPv4 to IPv6 has been a headache, moving backwards to IPv4-9BIT would fuck things even harder.
MangoToupe · 3h ago
Maybe if we worked with 7-bit bytes folks would be more grateful.
shmerl · 1h ago
> It's 2025 and Github—Github!—doesn't support IPv6
Yeah, I wonder why. It's not IPv6's problem though, it's definitely Github's.
Anyway, it's not a good example, since IPv6 is vastly wider than 9-bit variant of IPv4 would have been.
m463 · 2h ago
We have already solved this problem many times.
In clothing stores, numerical clothes sizes have steadily grown a little larger.
The same make and model car/suv/pickup have steadily grown larger in stance.
I think what is needed is to silently add 9-bit bytes, but don't tell anyone.
1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, and 60
"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
Then they decided to abandon their indigenous technology in favour of copying Western designs
If you don't believe me, just ask Paula Bean.
https://scontent-lax3-2.xx.fbcdn.net/v/t39.30808-6/476277134...
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.
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.
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.
I don't think this is enough of a reason, though.
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.
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.
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.
Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.
They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.
Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.
Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
On IPv4 I assume you're doing something which boils down to:
So what's the different with: Is different? If you're also doing a static ARP to be "fully" static then you've probably also got an additional config which boils down to something akin to: Which maps to: In both cases you either need to locally respond to ARP/ND still or also statically configure the rest of the devices in the subnet, but it should be identical outside the address size.> Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
I have a strong aversion to AWS, but if there is anything more difficult about this than it takes to do for IPv4 it's exactly what I meant about IPv6 not requiring any of this, rather the implementers (usually carriers or providers) really wanting to enforce some of these other dynamic things as part of rolling it out (because it's easier on them to use the whizz-bang options, not because IPv6 dictated it).
And no interoperability between the two without stateful network address translation.
https://www.internetsociety.org/blog/2016/09/final-report-on...
Some more interesting history reading here:
https://datatracker.ietf.org/doc/html/rfc33
[1] https://web.archive.org/web/20170404160423/http://archive.co...
[2] https://web.archive.org/web/20170404161611/http://archive.co...
10 bit bytes would give us 5-bit nibbles. That would be 0-9a-v digits, which seems a bit extreme.
GI made 10-bit ROMs so that you wouldn't waste 37.5% of your ROM space storing those 6 reserved bits for every opcode. Storing your instructions in 10-bit ROM instead of 16-bit ROM meant that if you needed to store 16-bit data in your ROM you would have to store it in two parts. They had a special instruction that would handle that.
The Mattel Intellivision used a CP1610 and used the 10-bit ROM.
The term Intellivision programmers used for a 10-bit quantity was "decle". Half a decle was a "nickel".
What's the point?
Interestingly, the N64 internally had 9 bit bytes, just accesses from the CPU ignored one of the bits. This wasn't a parity bit, but instead a true extra data bit that was used by the GPU.
And that 2^32 = 4B is similarly awkwardly not quite big enough for global things related to numbers of people, or for second-based timestamps.
But a 9th bit isn't going to solve those things either. The real problem is that powers-of-two-of-powers-of-two, where we jump from 256 to 65K to 4B to 18QN (quintillion), are just not fine-grained enough for efficient usage of space.
It might be nice if we could also have 2^12=4K, 2^24=16M, and 2^48=281T as more supported integer bit lengths used for storage both in memory and on disk. But, is it really worth the effort? Maybe in databases? Obviously 16M colors has a long history, but that's another example where color banding in gradients makes it clear where that hasn't been quite enough either.
We need to be better at estimating require sizes, not trying to trick ourselves into accomplishing that by slipping in an extra bit to our bytes.
As far as ISPs competing on speeds in the mid 90s, for some reason it feels like historical retrospectives are always about ten years off.
Because, I have a ten year old Dell laptop with 40GB of RAM, 16GB seems like an arbitrary limitation, an engineering compromise, or something like that.
I don’t see how it is a result of 8 bit bytes because 64bits has a lot of address space.
And because my laptop is running Windows 10 currently and ram Ubuntu before that, ordinary operating systems are sufficient.
—-
Also ECC RAM is 9 bits per byte.
The fact that Intel managed to push their shitty market segmentation strategy of only even supporting ECC RAM on servers has rather nefarious and long-lasting consequences.
If accessing a bit is really accessing a larger block and throwing away most of it in every case, then the additional byte grouping isn't really helping much.
A one-bit wide bus ... er, wire, now, I guess ... Could work just fine, but now we are extremely limited with the number of operations achievable, as well as the amount of addressable data: an eight-bit address can now only reference a maximum of 32 bytes of data, which is so small as to be effectively useless.
It's an arbitrary grouping, and worse, it's rarely useful to think in terms of it. If you are optimizing access patterns, then you are thinking in terms of CPU words, cache line sizes, memory pages, and disk sectors. None of those are bytes.
A reminder of that past history is that in Internet standards documents, the word "octet" is used to unambiguously refer to an 8-bit byte. Also, "octet" is the French word for byte, so a "gigaoctet (Go)" is a gigabyte (GB) in English.
(Now, if only we could pin down the sizes of C/C++'s char/short/int/long/long-long integer types...)
Octad/octade was unambiguously about 8 bit bytes, but fell out of popular usage.
What if instead of using single bytes, we used "doublebytes"?
8-bit software continues to work, while new 16-bit "doublebyte" software gets 256x the value capacity, instead of a meager 2x.
Nobody will ever need more byte space than that!
Without requiring any changes to CPU/GPU, RAM, SSD, Ethernet, WiFi ...
Magic. :)
64-bit pointers are pretty spacious and have "spare" bits for metadata (e.g. PAC, NaN-boxing). 72-bit pointers are even better I suppose, but their adoption would've come later.
A big part of the move to 8bit systems was that it allowed expanded text systems with letter casing, punctuation and various ASCII stuff.
We could move to the world of Fortran 36bit if really needed and solve all these problems while introducing a problem called Fortran.
Got to stop somewhere.
At first I thought that was a nice way to handle credit, but on further thought I wonder if this is necessary because the base line assumption is that everyone is using LLMs to help them write.
Thank you to Android for mobile Internet connectivity, browsing, and typing.
C is good for portability to this kind of machine. You can have a 36 bit int (for instance), CHAR_BIT is defined as 9 and so on.
With a little bit of extra reasoning, you can make the code fit different machines sizes so that you use all the available bits.
https://isocpp.org/files/papers/P3477R1.html
Sometimes the latter is a win, but not if that is your default modus operandi.
Another issue is that machine-specific code that assumes compiler and machine characteristics often has outright undefined behavior, not making distinctions between "this type is guaranteed to be 32 bits" and "this type is guaranteed to wrap around to a negative value" or "if we shift this value 32 bits or more, we get zero so we are okay" and such.
There are programmers who are not stupid like this, but those are the ones who will tend to reach for portable coding.
Yeah, I wonder why. It's not IPv6's problem though, it's definitely Github's.
Anyway, it's not a good example, since IPv6 is vastly wider than 9-bit variant of IPv4 would have been.
In clothing stores, numerical clothes sizes have steadily grown a little larger.
The same make and model car/suv/pickup have steadily grown larger in stance.
I think what is needed is to silently add 9-bit bytes, but don't tell anyone.
also: https://imgs.xkcd.com/comics/standards_2x.png
Note to the author, put this up front, so I know that you did the bare minimum and I can safely ignore this article for the slop it is.