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
> In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers.
Usually the size of general purpose registers is what defines the bitness of a CPU, not anything else (how much memory it can address, data bus width, etc).
For instance, the 80386SX was considered a 32-bit CPU because its primary register set is 32-bit, despite the fact it had a 24-bit external address bus and a 16-bit external data bus (32-bit requests are split into two 16-bit requests, this was done to allow the chip to be used on cheaper motherboards such as those initially designed with the 80286 in mind).
Note that this is for general purpose registers only: a chip may have 80-bit floating point registers in its FPU parts (supporting floating point with a 64-bit mantissa) but that doesn't make it an 80-bit chip. That was a bit more obvious when FPUs where external add-ons like the 8087 (the co-pro for the 16-bit 8086 family back in the day, which like current FPUs read & wrote IEEE754 standard 32- & 64- bit format floats and computed/held intermediate results in an extended 80-bit format).
>Usually the size of general purpose registers is what defines the bitness of a CPU
The Motorola 68000 has 32-bit registers but it's usually considered a 16-bit CPU because it has 16-bit ALU and 16-bit data bus (both internal and external).
Motorola 68k is a curious case because it originally was supposed to be a 16bit cpu, not 32bit, and the 24bit addressing that ignored upper 8 bits didn't help the perception.
Ultimately, 68k being "16bit" is a marketing thing from home computers that upgraded from 8bit 6502 and the like to m68k but didn't use it fully.
I'd still call it a 32-bit CPU as it had 32-bit registers and instructions (and not just a few special case 32-bit instructions IIRC). Like the 386SX it had a 16-bit external data bus, but some of its internal data routes were 16-bit also (where the 386SX had the full 32-bit core of a 386, later renamed 386DX, with the changes needed to change the external data bus) as were some of its ALUs hence the confusion abaout its bit-ness.
In a way, the fact that you have home computer market calling it 16bit, while at the same time you have workstation systems that plainly talk about 32bit ISA, shows how much of marketing issue it is :)
I'm not aware of that one off the top of my head. If it naturally operated over 16-bit values internally (i.e. it had 16-bit registers and a primarily 16-bit¹ instruction set), at least as fast as it could work with smaller units, then probably yes.
----
[1] So not a mostly 8-bit architecture with 16-bit add-ons. The 8086 had a few instructions that could touch 32 bits, multiply being able to give a 32-bit output from two 16-bit inputs for instance (though the output was always to a particular pair of its registers), but a few special cases like that doesn't count so it is definitely 16-bit.
Well, the 6809 was basically the same in these respects.
Internal registers are 16 bit, with the accumulator (A) being provisioned as two 8 bit registers (A, B) as needed. Index X, Y, Stack, User Stack, PC, are all 16 bit registers.
The Hitachi 6309, adds to that with up to 32 bit register sizes in specific cases.
In any case, the ALU and data transfers are 8 bits and I am not sure I ever saw the 6809 referenced as a 16 bit device.
I'd say that it's a somewhat extended 8bit device because it's still 8bit focused architecture (6800) with extensions towards better handling of 16bit values and certain common parts involved including the zero/direct page are also effectively an increase in flexibility for 8bit code not so much move to 16bit.
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 just can't resist, pointing out that a "minute" is what you get when you split up an hour into 60 minute (i.e. the word pronounced my-newt) pieces, and a "second" is what you get if you break a minute into 60 pieces (i.e. you've performed the division a "second" time).
By this logic, 0.016 (recurring) seconds should be a called a "third".
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.
> "(like you just need to remember 2 more digits)"
"The standard among mathematicians for writing larger bases is to extend the Arabic numerals using the Latin alphabet, so ten is written with the letter A and eleven is written with the letter B. But actually doing it that way makes ten and eleven look like they're too separate from the rest of the digits so you can use an inverted two for ten and an inverted three for eleven. But those don't display in most fonts so you can approximate them with the letters T and E which also happen to be the first letters of the English words ten and eleven. But actually as long as we're okay for using the Latin alphabet characters for these digits then we might as well use X for ten like in Roman numerals. But actually now we're back to having them look too different from the other ten digits so how about instead we use the Greek letters Chi and Epsilon but actually if we're using Greek letters then there's no association between the X looking letter and the number ten, so maybe you can write ten with the Greek letter delta instead.
And all you really need to learn is those 'two new digits' and you're ready to use dozenal."
- Jan Misali in his comedy video on why base 6 is a better way to count than base 12 or base 10 https://www.youtube.com/watch?v=qID2B4MK7Y0 (which is a pisstake and ends up making the point that Base 10 isn't so bad).
("in dozenal, a seventh is written as 0.186X35 recurring because it's equal to one gross eight dozen ten great gross ten gross three dozen five eleven gross eleven dozen eleven great gross eleven dozen eleventh's").
Ideally you learn with what you are both with. It’s easy to have base 10 as you have ten fingers. If we only had 8 fingers we could have ended up with octal
Yeah, metric is cool and all, you can divide by ten and multiply by ten. But even better would be a hexadecimal system so that you could halve, third and quarter it. Plus it's n^2 so it's a perfect square \s
7! 5040 has the less than useful property of being quite large for interacting with human scales.
5! 120 however lacks fine precision required at human scale. Haven't done the math but it's probably something like using 3.1 as the analog of Pi.
360 seems like it might have been chosen based on a mix of precision and practicality. Many small prime factors ( 2 2 2 3 3 5 ). Also an extra prior prime factor for every added prime. 75600 too big, and 12 what analog clock faces use as their primary number.
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.
I don’t think any common conversions fall near there other than miles->km. It’s certainly not the case that the systems were designed to have the golden ratio as conversions between the two.
1 mile = 1,000 [double] paces of 0.8m each = 1,600m
1m = 1e-10 times half-meridian from the North Pole to the equator, via Paris for a croissant, apparently.
So kind of a coincindence... But a very neat one. Meanwhile, ratio of adjacent Fibonacci numbers converves to some expression involving sqrt(5) which is approx 1.6
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.
Weird bytelengths were very much the norm in early computing but noone (seemingly) ever mass-produced a 10 bit computer[1].
In the first 3⁄4 of the 20th century, n is often 12, 18, 24, 30, 36, 48 or 60. In the last 1⁄3 of the 20th century, n is often 8, 16, or 32, and in the 21st century, n is often 16, 32 or 64, but other sizes have been used (including 6, 39, 128).
"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.
Personally I think 12/48/96 would be more practical than the current 8/32/64. 32 bits is almost trivially easy to overflow whereas 48 bits is almost always enough when working with integers. And 64 bits is often insufficient or at least uncomfortably tight when packing bits together. Whereas by the time you've blown past 96 you should really just bust out the arrays and eat any overhead. Similarly I feel that 24 bits is also likely to be more practical than 16 bits in most cases.
12 bit color would have been great. In the old days 4 bits for each of RGB, or even packing 2 pixels per byte. Today 12 bit per channel would be awesome, although high end cameras seem to be at 14 (which doesn't fit bytes well either).
Instruction sets - 12 bits for small chips and 24 for large ones. RISC-V instructions encode better in 24bits if you use immediate data after the opcode instead of inside it.
Physical memory is topping out near 40bits of address space and some virtual address implementations don't even use 64 bits on modern systems.
Floating point is kinda iffy. 36 bits with more than 24bit mantissa would be good. not sure what would replace doubles.
Yeah it would be much more practical for color. 12 bit rgb4, 24 bit rgb8 or rgba6, and 48 bit rgb16 or rgba12 would all have proper alignment. The obvious rgb12 would obviate the need for the unholy mess of asymmetric 32 bit packed rgb formats we "enjoy" today.
Physical memory - Intel added support for 57 bits (up from 48 bits) in 2019, and AMD in 2022. 48 bit pointers obviously address the vast majority of needs. 96 bit pointers would make the developers of GC'd languages and VMs very happy (lots of tag bits).
For floats presumably you'd match the native sizes to maintain alignment. An f48 with a 10 bit exponent and an f96 with a 15 or 17 bit exponent. I doubt the former has any downsides relative to an f32 and the latter we've already had the equivalent of since forever in the form of 80 bit extended precision floats with a 16 bit exponent.
Amusingly I'm just now realizing that the Intel 80 bit representation has a wider exponent than IEEE binary128.
I guess high end hardware that supports f128 would either be f144 or f192. The latter maintains alignment so presumably that would win out. Anyway pretty much no one supports f128 in hardware to begin with.
The fixed point TI dsp chips always had a long int that was 48. Intel had 84 bit floating point registers before simd registers took over. And the pdp-11...
Powers of two aren't as ubiquitous as it seems. If anything, the hardware uses whatever sizes it wants and that gets abstracted from the rest of the world by compilers and libraries.
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.
There was a very good reasons for it, indigenous designs were obsolete by the time they left the drawing boards and countless design bureaus cost stupid amounts of money while producing dozens of incompatible computers. By the time they decided to adopt ES EVM they lagged by some 5 years and continued to lag further behind.
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.
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.
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.
If something is painful you aren't doing it often enough, right? So my (completely uninformed) idea would be 27 bit addresses that are only routable on the local LAN and then a second optional 27 bit address to route between LANs on the WAN. The effective 54 bit address space would have been more than large enough, and if you support modularly extending addresses like that then there's no reason not to keep going beyond the initial 2 by eating into the payload.
Being completely uninformed I have no idea how severe the negative consequences of this scheme would be for the efficiency of routing hardware but I assume it would probably be catastrophic for some reason or another.
That's very loosely how IPv6 works. Your ISP will typically assign your router a prefix and will route any address starting with that 56 or 64 bit prefix to you. Then devices on your network pick the remaining bits and they get their full address.
Well IPv4 also used to work that way back before address exhaustion. What I'm describing isn't an arbitrary allocation of a subset of a single fixed bit width address but rather two (or more) entirely disjoint address spaces.
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.
Your first paragraph implies 8-bit bytes are a coincidence, which is not true. It was a design decision.
A byte in computer is the smallest addressable memory location and this location at that time contained a character. The way characters are encoded is called code. Early computers used 5-bits, which was not enough for alphabetics and numerals, 6 bits was not enough to encode numbers and lower and upper case characters, which eventually lead to ASCII.
ASCII was also designed(!) to make some operations simple, eg. turning text to upper or lower case only meant setting or clearing one bit if the code point was in a given range. This made some text operations much simpler and more performant, that is why pretty much everybody adopted ASCII.
Doing 7-bit ASCII operations with a 6-bit bytes is almost impossible and doing them with 18-bit words is wasteful.
When IBM was deciding on byte size a number of other options were considered, but the most advantageous was the 8-bit byte. Note that already with 8-bit bytes, this was over-provisioning space for character code, as ASCII was 7-bit. The extra bit offered quite some space for extra characters, which gave rise to character encodings. This isn't something I would expect a person living in the USA to know about, but users of other languages used upper 128 bytes for local and language specific characters.
When going with 8-bit byte, they also made the bytes individually addressable, making 32-bit integers actually 4 8-bit bytes. 8-bit byte also allowed to pack two BCD in one byte and you were able to get them out with a relatively simple operation.
Even though 8-bits was more than needed, they were deemed cost effective and "reasonably economical of storage space". And being a power of two allowed addressing a bit in a cost effective way, if a programmer needed to do so.
I think your post discounts and underestimates the amount of performance gain and cost optimisations 8-bit byte gave us at the time it mattered most, at the time computing power was low, and the fact that 8-bit bytes were just "good enough" and we didn't get anything usable from 9, 10, 12, 14 or 16 bit bytes.
On the other hand you overestimate the gains with imaginary problems, such as IPv4, which didn't even exist in 1960s (yes, we ran out of public space quite some time ago, no, not really a problem, even on pure IPv6 one has 6to4 NAT), or negative unix time - how on Earth did you get the idea that someone would use negative unix time stamps to represent historic datings, when most of the time we can't even be sure what year it was?
I think the most scary thing is having and odd-bit bytes; there would be a lot more people raging against the machine, if byte was 9 bits.
Given how many early computers had 18-bit or 36-bit words, the possibility of 9-bit bytes doesn’t seem as unrealistic as you suggest. I don’t see 8-bit bytes as being so inevitable.
> 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.
You don't want to switch code pages while processing the data unless you add extra fields to indicate code page, ISO 2022 style (or in fact old baudot shifts style)
If you were saying they lost accents outside the main 50 or whatever, I'd understand why 8 bits were a problem. But you're saying they lost accents as a general rule, right? Why did they lose accents that were right there on the US code pages? Why would that reason not extend to a 9 bit semi-universal EBCDIC?
I read the original mention as trying to claim that it could have been solved by allowance for multiple codepages.
But for processing data in one common database, especially back then, you wanted to keep to single variation - main reason for using a different codepage if you didn't work in language other than english was to use APL (later, special variant of US codepage was added to support writing C, which for hysterical raisins wasn't exactly nice to work with in US default EBCDIC codepage).
So there would not be an allowance for multiple codepages if only because codepage identifier could cut into 72 characters left on punched card after including sort numbers
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.
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.
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.
Android was nearly my real life example a la "IPv6 doesn't mandate anything be different, some guy at Android just likes doing things that way more". I.e. nothing needs to be changed in the IPv6 standard, there's just some guy on the Android team who really likes SLAAC and thinks DHCPv6 is an abomination.
Okay, but that's not useful. In practice in the real world you cannot run a v6 network the way you would a v4 network even if you want to. That you theoretically could go implement changes to bring them into line doesn't really affect that.
I think we're saying the same thing except I'm splitting the blame from IPv6 (which was very much about adding more bits) and placing it on the unrelated hobby horses people like whats-his-name on Android ride in on. Intentionally not supporting DHCP in the new protocol had nothing to do with the design of IPv6, it's just something they prefer.
To put it from another perspective: If the situation was reversed would you be blaming IPv4 and saying IPv4 should have been designed differently or would you just be asking why this guy from Android doesn't want to add DHCPv4 when DHCPv6 is supported? In both situations it's not IPv4/IPv6 to blame for the inconvenience, it's the guy taking advantage of the transition between protocols to do something stupid at the same time. No amount of changing the definition of IP is going to make them like DHCP, they'll always push some SLAAC-like address assignment onto users. The only reason they didn't for IPv4 was they came in after it was already the way instead of before networks were deployed and they could force it.
It's often very difficult to use IPv6 in practice, but not because IPv6 made it that way.
> 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.
Side note: I'm not sure why folks downvoted you. Even if they disagree it seems like an honest question.
> 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 (from whatever network configuration tool you use):
ip addr add 192.168.1.100/24 dev eth0
ip route add default via 192.168.1.1 dev eth0
Which maps directly to:
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
If you're also doing a static ARP to be "fully" static then you'll also have 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 this config to statically set the MAC instead of using ND:
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 still locally respond to dynamic ARP/ND request or also statically configure the rest of the devices in the subnet (including the router) in a similar fashion, but there's not really much difference beyond the extra bits in the address.
> 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 for IPv6 than IPv4 then that's entirely on what AWS likes to do rather than what IPv6 requires. E.g. if they only give you a dynamic link local gateway it's because they just don't want you to use a public address as the static gateway, not because IPv6 said it had to be so by not supporting unicast gateways or something.
There's also nothing about IPv6 ND that would make it take longer to discover the gateway from a statically configured unicast address than IPv4 ARP would take, but AWS may be doing a lot of optional stuff beyond just being a dumb gateway in their IPv6 implementation - again, not because IPv6 itself said it should be so but because they want to do whatever they are doing.
That's really helpful, thank you; I'll give that a try the next time I'm attempting to make this work.
(I'm doing this using direct netlink calls from my init; this is all about booting as fast as possible. The IPv6 address information is coming from instance metadata.)
I'd figured that specific detail out already, though it was hard-won knowledge. But there's a lot more where that came from before getting to the point of bringing up IPv6 and sending packets without dealing with slow RA and various other slow processes of waiting for data from the network, for instance.
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.
Author here. The point is that with 9-bit bytes we'd have designed IPv4 to have 36-bit addresses from the beginning. There wouldn't have been a transition.
The post I replied to was speculating on IPv4's life being extended by "simply making the numbers bigger" rather than having more bits per byte, but nevertheless... there still would've been a transition, delayed by at most a few years.
Exhaustion was raised for 32-bit IPv4 in the very early 90s, when we had a few million active Internet users. Allocations were very sparsely used and growth in Internet usage was exponential. It didn't take much of an imagination to foresee a problem.
A 36-bit Internet would be little better. By the middle of the 90s we had ~45 million active Internet users, ending our 16x space advantage, even assuming we didn't just squander that with 8x as wasteful Class A allocations and bigger spaces reserved for uses that will never arise.
Today, we have ~70 billion connected devices: 5-6 billion home subscribers each with multiple devices in the home, 7.5 billion smartphones, 20 billion IoT devices, and all growing rapidly.
We'd need NAT. But NAT was a response to exhaustion concerns, as a stop-gap measure to provide time to design and transition to a proper solution. If we didn't have exhaustion concerns, there'd be no NAT. If we did have exhaustion concerns, brought on perhaps by the lack of NAT, we'd still have invented IPv6, because we'd still have been able to forecast that the Internet would rapidly outgrow 36 bits of address space.
edit: disclaimer, I work in this space, but my comments reflect my own opinion and are not necessarily those of my employer.
Great reply, much appreciated. I searched a bit for a number like ~70B and didn't find one. Perhaps 36 bits wouldn't have actually worked. I do think we'd have wasted more Class As, but that's where the "minor market mechanisms" would have happened—most of the class As did get sold and would in this universe too. Again, if total internet-connected devices is now 70B that wouldn't help, you'd still need NATs.
It's extremely hard to get an accurate count of connected devices, so we're all just estimating. There's lots of sources giving rough values for things like smartphones or IoT devices, there's a reasonably common estimate of 5.6 billion connected Internet users, but it's largely guesswork for connected devices per user.
It's improbable that I'm off by an order of magnitude: 7 billion is far too low (we have 7.5 billion smartphones in the world!) and 700 billion is far too high; how low an estimate could we make without being unreasonably optimistic? 40b seems quite low to me - 7.5b smartphones, 5.6b connected users, 20b IoT devices, and commercial use of IPs - but if we took that value we'd be sitting at saturation for 36 bits of address space (60% utilisation is pretty darn good!) and the next decade would kind of suck.
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.
It's definitely more of an education issue. I still run into "IT" people that instinctively disable IPv6 no matter what. How do we fix this? The sad thing is IPv6 is actually easier in many respects: subnetting is simpler, no NAT hackery, SLAAC...
> I still run into "IT" people that instinctively disable IPv6 no matter what. How do we fix this?
- force ISPs to follow RIPE guidance on addressing (static prefix, at least /56 for every site, DHCPv6-PD)
- force the manufacturers of low-end routers (e.g. provided by ISPs) to have good IPv6 support (good firewalling, DHCPv6-PD, mDNS, PCP/UPNP, advertise static ULA prefix to have working local network even if internet connection is cut)
- force Android team to support DHCPv6
- force browsers to support full IPv6 addresses in URLs / URIs (link local addresses, scope id)
- force avahi / mDNS to support IPv6 scope id
- make operating system manufacturers to have a better unified socket API which can resolve any type of address (IPv4, IPv6, DNS, mDNS, etc. maybe even URLs directly) and deprecate all other API
- make software developers to use this new API and don't try to parse IP addresses or URLs themselves
- have a good solution for multi-homing / WAN failover (without BGP and PI address space)
- have a good solution for mobile / roaming devices (phones, notebooks)
and maybe we could make IPv6 stable and universally working
(Waste a /40 for every company, get low on available prefixes and start over designing IPv8 to have 256 bit addresses with 184 bit host part...)
I'll assume you are speaking in good faith, so i'll reply so as well:
I do not want to be a "reasonably-skilled admin". Not my job nor desire. I want DHCP to work and NAT to exist which acts as a de-facto firewall and hides my internal network config from the outside world. All with zero or fewer clicks in my home router's config. With IPv4 this works. With IPv6 it does not. Simple choice for me then: find the IPv6 checkbox and turn it off, as usual.
As a consumer, I don’t care if it’s Santa Claus’s fault. IPv4: works, IPv6: doesn’t. I don’t even need to know what IPv6 means. I just need to know: Turn it off to make things work.
As a technologist, growing up involves learning not to blame the consumer. They are not holding it wrong, you just designed it in a dumb way.
If you want to come into a topic and say the problem is that IPv6 did too much, you can't fall back on "it doesn't matter who's at fault". Yes it does matter, that's what this thread is about, that and looking at how technological changes would have affected deployment.
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.
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.
In early 00s my university in Poland had all computers at the campus connected to the internet with public IPs :) Thousands of computers - every lab, every room at dormitories and some for public use standing at the corridors at campus, all with unique public IPs cause they had so many :)
I think they had 19 bits of IP addresses available or sth crazy like that :) They were one of the institutions introducing internet in Poland back in 90s, so they had a huge portion of the addresses assigned and kept them.
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.
> It did have a Load Byte and a Store Byte instruction, which allowed you to select the byte size.
Were these instructions atomic regarding interrupts? If not, then these look like shorthands for masking/shifting bit-fields out of words, leaving the word as the smallest atomically addressable unit.
They are atomic, indeed. The underlying implementation might have used masking and shifting, especially in bit-slice implementations like KS-10, but as far as operation of the computer was concerned they were atomic.
It becomes problematic for multiprocessor systems but you could probably build a communications fabric and memory model that works.
My fantasy CPU lets you write to the (say) 15 bits starting at the 43rd but of a 48 bit word which a real CPU would have to do a lot of work to implement but with the right kind of cache it is probably not so bad, it also has an instruction to read a UTF-8 character at a deep pointer and increment the pointer which a real system could satisfy out of the cache except when it can’t.
For PDP-10, because it operated only on word values, you can easily assume that every bus and memory operation passes a full 36 bit word every time.
In fact, recent-ish x86 CPUs have similar instructions, and as of Zen4 they are fast not just on Intel but also on AMD (previously they were microcoded as a bunch of shifts AFAIK with pretty lousy latency)
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.
It's not an argument for longer roads or can kicking? The thesis is stated at the top: with 9 bit bytes we'd avoid a couple of bad numerological coincidence (like that the number of Chinese characters is vague but plausibly around 50k, or the population of the earth is small integer billions). By avoiding the coincidences we'd avoid certain problems entirely. Unicode is growing but we're not discovering another Chinese! Not will world population ever hit 130B, at least as it looks now.
If you think there's some equally bad coincidence go ahead and tell me but no one has yet. I think I do a good job of that in the post. (Also it's amazing you and maybe everyone else assume I know nothing except what ChatGPT told me? There are no ads on the website, it's got my name face and job on it, etc. I stand by what I wrote.)
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.
"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.
Author here. The argument was that by numerological coincidence, a couple of very important numbers (world population, written characters, seconds in an epoch, and plausible process memory usage) just happen to lie right near 2^16 / 2^32. I couldn't think of equally important numbers (for a computer) near ~260k or ~64B. We just got unlucky with the choice of 8-bit bytes.
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.
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".
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).
> 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.
When you think end-to-end for a whole system and do a cost-benefit analysis and find that skipping some letters helps, why wouldn't you do it?
But I'm guessing you have thought of this? Are you making a different argument? Does it survive contact with system-level thinking under a utilitarian calculus?
Designing good codes for people isn't just about reducing transcription errors in the abstract. It can have real-world impacts to businesses and lives.
Safety engineering is often considered boring until it is your tax money on the line or it hits close to home (e.g. the best friend of your sibling dies in a transportation-related accident.) For example, pointing and calling [1] is a simple habit that increases safety with only a small (even insignificant) time loss.
I started off by saying that 0-9a-v digits was "a bit extreme", which was a pretty blatant euphemism — I think that's a terrible idea.
Visually ambiguous symbols are a well-known problem, and choosing your alphabet carefully to avoid ambiguity is a tried and true way to make that sort of thing less terrible. My point was, rather, that the moment you suggest changing the alphabet you're using to avoid ambiguity should also be the moment you wonder whether using such a large number base is a good idea to begin with.
In the context of the original discussion around using larger bytes, the fact that we're even having a discussion about skipping ambiguous symbols is an argument against using 10-bit bytes. The ergonomics or actually writing the damned things is just plain poor. Forget skipping o, O, l and I, 5 bit nibbles are just a bad idea no matter what symbols you use, and this is a good enough reason to prefer either 9-bit bytes (three octal digits) or 12-bit bytes (four octal or three hex digits).
Having 0-1000 fit inside a byte would be great. 1 byte for tonnes, 1 for kg, 1 for g, 1 for mg. Same with meters, liters, etc. Would work great with metric.
Or addressing 1 TB of memory with 4 bytes, and each byte is the next unit: 1st byte is GB, 2nd byte is MB, 3rd byte is KB, 4th byte is just bytes.
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.
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.
This article reminds me a lot of a conversation with an expert DBA recently. We were talking about performance improvements and he said that upgrading hardware is almost negligible. Upgrading from HDD to SSD gives you 10x boost. SSD to nvme maybe 4x. But optimizing queries and fixing indexes can give you 100x or 1000x improvements.
Of course, every little bit counts, so we still did upgrade the hardware, but (at least in our area), almost all speed improvements came from code optimization.
This article is talking about kicking the ipv4 can down down the road only 10 years and increasing process memory from 2G to 32G. Seems like such small fries when we could just double it and move on. If you brought the 2038 problem to Unix devs, I'm sure they would have said "thanks! We'll start with 64-bit" instead of "yes... Let's use an unaligned 36 bits so the problem is hidden slightly longer".
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.
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.
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.
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.
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.
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.
There was a time, however, where CPUs operated almost exclusively on on 8bit bytes (and had 8bit data buses). Everything else is merely the consequence of that.
Quick note that this isn't true. 8-bit CPUs are newer than 36-bit CPUs, and 8-bit bytes were established long before 8-bit CPUs came on the scene. Prior to the mid-70s most machines were word-addressed. The adoption of byte addressing (the subject of the grandparent) gained traction after C and similar languages became popular. C was developed on the pdp-11 which supported byte addressing and it provided a compatible memory model: any pointer value could be de-referenced to a byte. The VAX followed, also with byte addressing and by 1980 you couldn't sell a CPU that didn't support byte addressing (because C wouldn't work with it). 8-bit CPUs had nothing to do with any of this.
What you say is correct except for the very last part which is inaccurate. C works with word-addressed CPUs (I can see one from here, and it has a C compiler. And was, incidentally, sold into the early nineties). What C needs is a way to work with 8-bit characters, that's all (and even that isn't 100% true, just widely expected). So what a C compiler needs on, say, a 16-bit addressable computer, is a way to access a char, an 8-bit entity (everything else, e.g. int, long etc., is up to the architecture). And that can be done by software, or more typically by the CPU having opcodes to access 8-bit fields within its native addressable word size.
The comment was about why CPUs still use byte addressing even today. And it's my belief that's due to incomparably wide proliferation of 8bit computers.
Even CPUs that were 32bit with a 16bit data bus, like the 68000 series, required the ability to read and write single bytes to support the wide range of 8bit I/O chips including UARTs, timers, floppy-disk controllers, video controllers that were common at the time. The 8bit bus was king for a long time.
The C "char" type need not be 8-bit at all. *nix operating systems enforce 8-bit bytes, but that's historically due to the primacy of text streams on that platform, and is to some extent an arbitrary choice.
10 bit is even better according to all these criteria AND it fits 0-1000 into one byte which meshes really well with metric system (0 to 1 km in meters, 0 to 1 liter in ml, etc.)
You could even do binary-encoded-metric-numbers that you can decode as needed one byte at a time - the first byte is tonnes, the second is kilograms, the third is grams, the 4th is milligrams, and you only lose 23 out of 1024 values at each level.
Same (but without loses) with data sizes. 1st bit is gigabytes, 2nd is megabytes, 3rd is kilobytes, 4th is bytes.
And of course at one point many computers used 40-bit floating point format which would fit nicely into our 4 bytes.
10-bit bytes would consist of two 5-bit nibbles, which you could use for two case-insensitive letters (for example Baudot Code was 5-bit). So you could still do hex-like 2-letter representation. Or you could send case-insensitive letters at 2 letters per byte.
40 bit could address 1 TB of memory (of 10-bit values - so much more than 1TB of 8-bit values). We could still be on 4-byte memory addressing to this day which would make all pointers 4-byte which would save us memory.
And so on.
But ultimately it always had to be power-of-two for cheaper hardware.
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.
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.
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.
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, a lucky coincidence meaning the consumer internet would largely require another transition anyway. 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.
I used to think, how the history of computing and Internet would look like, if computers converged on 3-base system, with trits instead of bits, and trytes instead of bytes.
If one tryte was 9 trites, it would have 3^3=19693 values. All the European characters and a lot of others can be encoded with this. There would be no need to invent char/int integer types in C (with the added mess of short, short short, long, and long long) int would be enough at the time. Maybe at the point when it would become necessary to add different integer types, C would choose a saner approach of stdint.h, and there would be no legacy code playing with legacy integer types?
And 27 trites (or 3 trytes) is around 2^42.8 values, like 42 bits. It would be enough even now, I think.
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.
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.
Perhaps the reason modern programs use so much memory vs what I remember from the Windows XP era is precisely because we went to 64 bits. Imagine how many pointers are used in the average program. When we switched over to 64 bits, the memory used by all those pointers instantly doubled. It's clear that 32 bits wasn't enough, but maybe some intermediate number between 32 and 64 would have added sufficient capacity without wasting a ton of extra space.
> Imagine how many pointers are used in the average program. When we switched over to 64 bits, the memory used by all those pointers instantly doubled.
This is a very real issue (not just on the Windows platform, either) but well-coded software can recover much of that space by using arena allocation and storing indexes instead of general pointers. It would also be nice if we could easily restrict the system allocator to staying within some arbitrary fraction of the program's virtual address space - then we could simply go back to 4-byte general pointers (provided that all library code was updated in due course to support this too) and not even need to mess with arenas.
(We need this anyway to support programs that assume a 48-bit virtual address space on newer systems with 56-bit virtual addresses. Might as well deal with the 32-bit case too.)
I agree that's wasteful, but if software were only 2x bigger, we'd be in really good shape now. Unfortunately there are still another one or two more orders of magnitude to account for somehow.
SGI used three ABIs for their 64-bit computers.. O32, N32, N64. N32 was 64-bit except for pointers which were still 32 bits for exactly that reason - to avoid doubling the memory needed for storing pointers.
Imagine an alternative world that used 7-bit bytes. In that world, Pavel Panchekha wrote a blog post titled "We'd be Better Off with 8-bit Bytes". It was so popular that most people in that world look up to us, the 8-bit-byters.
So to summarize, people that don't exist* are looking up to us now.
Didn't follow how Github not supporting IPv6 is caused by the "wrong" byte size. Wouldn't 36 bit IP adresses have made that a non-topic?
The author seems to assume Github! is a leader. The masses in IT never have followed leading technology. How many Microsoft engineers do you need to change a light bulb? Zero, MS makes darkness an industry standard.
Most proposals for 9 bit bytes weren't for adopting 8 bits of data in a byte, they were to have 8 bits for data and 1 bit for something else, typically either error detection or differentiating between control/data. Very few folks argued for 9 bit bytes in the sense of having 9 bits of data per byte.
9 bit bytes never made significant headway because a 12.5% overhead cost for any of these alternatives is pretty wild. But there are folks and were folks then who thought it was worth debating and there certainly are advantages to it, especially if you look at use beyond memory storage. (i.e. closer to "Harvard" architecture separation between data / code and security implications around strict separation of control / data in applications like networking.)
It's worth noting that SECDED ECC memory adds about a 20% overhead, though it can correct single bit flips whereas 9-bit bytes with a parity bit can only detect (but not correct) bit flips which makes it useful in theory but not very useful in practice.
This article's setup seems to be: we could go back and change bytes to be 9 bits, but make all the same decisions for sizes of things as we did, so that everything would be the same now except we'd have a little more room.
A measly factor 16 doesn't really make it worth having to deal with non-power of two sizes. You're also assuming that everything would have used the same number of bites when most sizes are chosen based on how much was needed at the time or in the foreseeable future - with 9 bit bytes that would just have meant that we're just going to run out earlier for different things than with 8 bit bytes.
> IPv4: Everyone knows the story: IPv4 had 32-bit addresses, so about 4 billion total.44 Less due to various reserved subnets. That's not enough in a world with 8 billion humans, and that's lead to NATs, more active network middleware, and the impossibly glacial pace of IPv6 roll-out. It's 2025 and Github—Github!—doesn't support IPv6. But in a world with 9-bit bytes 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.
Only if you assume there is only one device per human, which is ridiculous.
> Unicode: In our universe, there are 65 thousand 16-bit characters, which looked like maybe enough for all the world's languages, assuming you're really careful about which Chinese characters you let in.77 Known as CJK unification, a real design flaw in Unicode that we're stuck with. With 9-bit bytes we'd have 262 thousand 18-bit characters instead, which would totally be enough—there are only 155 thousand Unicode characters today, and that's with all the cat smileys and emojis we can dream of. UTF-9 would be thought of more as a compression format and largely sidelined by GZip.
Which would be a lot worse than the current situation because most text like data only uses 8 bits per character. Text isn't just what humans type and includes tons of computer generated ASCII constructs.
Not to mention that now it becomes an active process to upgrade ASCII data to Unicode, which would have the argument of increased size against it for many files and thus files and formats without Unicode support would have stuck around for much longer.
UTF-8 might have been an accident of history in many ways but we really couldn't have wished for something better.
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...)
The term "octet" is still widely used in protocol descriptions and some other fields (source: All those interface specifications I have to read through my job)
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?)
Author here. I agree that this would have a similar effect; we'd probably still end up with 36-bit or 48-bit IP addresses (though 30-bit would have been possible and bad). We'd probably end up with a transition from 24-bit to 48-bit addresses. 18-bit Unicode still seems likely. Not sure how big timestamps would end up being; 30-bit is possible and bad, but 48-bit seems more likely.
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.
What if the first bits told you how long the byte was, and you just kept reading the length of the byte until you got some terminating sequence, then that would be followed by some error correction for the length and terminating sequence with a couple more terminating sequences, one could be ignored since once might be corrupted, following by a variable length byte, with its own error correction and more error correction? It’s just so obvious y’all!
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?)
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.
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.
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.
You'd define architecture-specific typedefs to deal with these cases in a portable way. The C standard already has types like int_fast8_t that are similar in principle.
See, why would you need an "architecture specific typedef" in order to represent the day of the month, or the number of arguments in main "in a portable way".
int does it in a portable way already.
int is architecture specific too, and it's been "muddled" plenty due to backward compatibility concerns. Using typedefs throughout would be a cleaner choice if we were starting from scratch.
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.
I can think of only one flavor in favor of 9 bit bytes: variable length integers. The 9th bit would indicate there is more data to come. This would apply to instructions too. A homo iconic ISA, anyone?
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).
10-bit bytes would also be tempting, as 1024 is so close to 1000 and it would make bytes follow an orders of magnitude progression. It would just be so much easier on mental arithmetic too.
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 :)
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.
The point of Base64 is to represent binary data using a familiar character repertoire. At least for the latin-script world, any collection of 256 characters won’t be a familiar character repertoire.
Who told you that? Don’t talk to that person anymore.
Base64 and uuencode before it are about transmitting binary data over systems that cannot handle binary. There are a bunch of systems in the early Internet that could only communicate 7 bits per byte, which is why uuencode uses only printable low ASCII characters. Has nothing to do with familiarity.
Systems that supported eight bits per byte were referred to as “8 bit clean”, to distinguish them from legacy systems you might still have to support.
PNG file format was specced in 1995, and it was still worried about 8 bit clean transmission. The first byte of the PNG magic number has the high bit set because they didn’t want the decoder to even have to bother with broken PNG files.
> Base64 is also widely used for sending e-mail attachments, because SMTP – in its original form – was designed to transport 7-bit ASCII characters only. Encoding an attachment as Base64 before sending, and then decoding when received, assures older SMTP servers will not interfere with the attachment.
I think it’s reasonable to assume that in a world with 9 bit bytes, someone may have chosen 8 bits for SMTP, or moved to 8 bit sooner. Which would give you at least Base128.
A 12.5% increase, or 1/8. Yes, a little. Compared to, say, hexadecimal, which would be a 50% increase. Or URL percent-encoding, which would be a 125% increase.
I understand the author's point to be that, if RFC writers understood "byte" to imply eight bits, they wouldn't go out of their way to use the word "octet" instead when referring to eight bits.
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.
This is such a dumb article. All of those examples are nonsense. We can also have thousands of examples about how 6 bits is enough or 10 bits is just right.
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.
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.
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.
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.
> I contains (sic) factual errors that stand out like lighthouses showing the author had an idea about an article but doesn't actually know the material.
Whoops ^ To be fair, technically, I also contain some factual errors, if you consider the rare genetic mutation or botched DNA transcription.
So far, I haven't found anything that I would consider to be a glaring factual error. What did I miss?
I'm not talking merely about a difference in imagination of how the past might have unfolded. If you view this as an alternative history, I think the author made a plausible case. Certainly not the only way; reasonable people can disagree.
I meant it was readable. It's speculative but it's well-informed speculation, not clueless nonsense. I agree that fact checking becomes more important because LLMs hallucinate. I feel the same about vibe coding. If you don't know much about programming then running vibe code is a risky bet (depending on the criticality of the problem)
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.
The Nintendo 64 RDP(graphics/memory controller) used 9 bit bytes.
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.
> 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
> In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers.
Usually the size of general purpose registers is what defines the bitness of a CPU, not anything else (how much memory it can address, data bus width, etc).
For instance, the 80386SX was considered a 32-bit CPU because its primary register set is 32-bit, despite the fact it had a 24-bit external address bus and a 16-bit external data bus (32-bit requests are split into two 16-bit requests, this was done to allow the chip to be used on cheaper motherboards such as those initially designed with the 80286 in mind).
Note that this is for general purpose registers only: a chip may have 80-bit floating point registers in its FPU parts (supporting floating point with a 64-bit mantissa) but that doesn't make it an 80-bit chip. That was a bit more obvious when FPUs where external add-ons like the 8087 (the co-pro for the 16-bit 8086 family back in the day, which like current FPUs read & wrote IEEE754 standard 32- & 64- bit format floats and computed/held intermediate results in an extended 80-bit format).
>Usually the size of general purpose registers is what defines the bitness of a CPU
The Motorola 68000 has 32-bit registers but it's usually considered a 16-bit CPU because it has 16-bit ALU and 16-bit data bus (both internal and external).
Motorola 68k is a curious case because it originally was supposed to be a 16bit cpu, not 32bit, and the 24bit addressing that ignored upper 8 bits didn't help the perception.
Ultimately, 68k being "16bit" is a marketing thing from home computers that upgraded from 8bit 6502 and the like to m68k but didn't use it fully.
That is an odd case.
I'd still call it a 32-bit CPU as it had 32-bit registers and instructions (and not just a few special case 32-bit instructions IIRC). Like the 386SX it had a 16-bit external data bus, but some of its internal data routes were 16-bit also (where the 386SX had the full 32-bit core of a 386, later renamed 386DX, with the changes needed to change the external data bus) as were some of its ALUs hence the confusion abaout its bit-ness.
In a way, the fact that you have home computer market calling it 16bit, while at the same time you have workstation systems that plainly talk about 32bit ISA, shows how much of marketing issue it is :)
Would you call the 6809 a 16 bit device?
I'm not aware of that one off the top of my head. If it naturally operated over 16-bit values internally (i.e. it had 16-bit registers and a primarily 16-bit¹ instruction set), at least as fast as it could work with smaller units, then probably yes.
----
[1] So not a mostly 8-bit architecture with 16-bit add-ons. The 8086 had a few instructions that could touch 32 bits, multiply being able to give a 32-bit output from two 16-bit inputs for instance (though the output was always to a particular pair of its registers), but a few special cases like that doesn't count so it is definitely 16-bit.
Well, the 6809 was basically the same in these respects.
Internal registers are 16 bit, with the accumulator (A) being provisioned as two 8 bit registers (A, B) as needed. Index X, Y, Stack, User Stack, PC, are all 16 bit registers.
The Hitachi 6309, adds to that with up to 32 bit register sizes in specific cases.
In any case, the ALU and data transfers are 8 bits and I am not sure I ever saw the 6809 referenced as a 16 bit device.
Maybe 16 bit curious, LMAO.
I'd say that it's a somewhat extended 8bit device because it's still 8bit focused architecture (6800) with extensions towards better handling of 16bit values and certain common parts involved including the zero/direct page are also effectively an increase in flexibility for 8bit code not so much move to 16bit.
That said, "16bit curious" is a great term :D
But in the n64’s case the GPU _could_ use the extra bit, so it’s fine. It was more trivia than anything about what the cpu could see.
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.
Plato is being annoying, and not for the first time. Sure, 7! has a lot of factors. But one person dies and you've got 5039. That's prime[1], so I guess your society breaks down? [1] https://prime-numbers.fandom.com/wiki/5,039#:~:text=5%2C039%...
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.
But why wasn't the handcounting inherited too?
It sounds useful to be able to count up until 60 on two hands.
Probably because it was too contrived. I mean, if you can count up to 12 on one, why can't you do up to 144 on both?
Could have something to do with right-handedness.
> That's why there are 360 degrees.
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 believe the 360 degrees is attributed to Babylonians, who were using the Sumerian base 60 number system (6*60=360)
I just can't resist, pointing out that a "minute" is what you get when you split up an hour into 60 minute (i.e. the word pronounced my-newt) pieces, and a "second" is what you get if you break a minute into 60 pieces (i.e. you've performed the division a "second" time).
By this logic, 0.016 (recurring) seconds should be a called a "third".
> (i.e. the word pronounced my-newt)
"minute" comes from latin "pars minuta" and the "i" should be pronounced like in "minimum"
> By this logic, 0.016 (recurring) seconds should be a called a "third".
It should be "tertia". I found that in German and Polish it was used that way, but don't know about english:
https://de.wikipedia.org/wiki/Tertie_(Winkel)
https://pl.wikipedia.org/wiki/Tercja_k%C4%85towa
Should be the etymology of trice (but isn't). Odd omission from English.
Commodores had a 1/60 second "jiffy" for timing interrupts, that's all I could find.
Unix V1 also used 1/60 seconds
To elaborate a little, an advantage of this is there are many numbers it’s evenly divisible by.
60: 2, 3, 4, 5, 6, 10, 12, 15, 20, 30
100: 2, 4, 5, 10, 20, 25, 50
360: 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 18, 20, 24, 30, 36, 40, 45, 60, 72, 90, 120, 180
60 and 360 are superior highly composite numbers¹.
¹ https://mathworld.wolfram.com/SuperiorHighlyCompositeNumber....
It's attributed, but the Babylonians knew a year was about 360 days.
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.
> "(like you just need to remember 2 more digits)"
"The standard among mathematicians for writing larger bases is to extend the Arabic numerals using the Latin alphabet, so ten is written with the letter A and eleven is written with the letter B. But actually doing it that way makes ten and eleven look like they're too separate from the rest of the digits so you can use an inverted two for ten and an inverted three for eleven. But those don't display in most fonts so you can approximate them with the letters T and E which also happen to be the first letters of the English words ten and eleven. But actually as long as we're okay for using the Latin alphabet characters for these digits then we might as well use X for ten like in Roman numerals. But actually now we're back to having them look too different from the other ten digits so how about instead we use the Greek letters Chi and Epsilon but actually if we're using Greek letters then there's no association between the X looking letter and the number ten, so maybe you can write ten with the Greek letter delta instead.
And all you really need to learn is those 'two new digits' and you're ready to use dozenal."
- Jan Misali in his comedy video on why base 6 is a better way to count than base 12 or base 10 https://www.youtube.com/watch?v=qID2B4MK7Y0 (which is a pisstake and ends up making the point that Base 10 isn't so bad).
("in dozenal, a seventh is written as 0.186X35 recurring because it's equal to one gross eight dozen ten great gross ten gross three dozen five eleven gross eleven dozen eleven great gross eleven dozen eleventh's").
>...one gross eight dozen ten great gross ten gross three dozen five eleven gross eleven dozen eleven great gross eleven dozen eleventh's
Now do PI!
Then Tom Lehrer's New Math.
Ideally you learn with what you are both with. It’s easy to have base 10 as you have ten fingers. If we only had 8 fingers we could have ended up with octal
Civilisations of the past used various numeric systems, including 5, 8 and 12. It's not like 10 was universal truth across all the lands.
You must be an AI, since I only have 8 fingers and two thumbs. ;)
Yeah, metric is cool and all, you can divide by ten and multiply by ten. But even better would be a hexadecimal system so that you could halve, third and quarter it. Plus it's n^2 so it's a perfect square \s
Or 60 minutes in an hour
1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, and 60
Or 5280 feet in a mile.
And one feet is 4 small foot toes and one big foot toe!
Wonder why we don’t have 720 degrees… (6!)
Maybe because 360 is already divisible by 6, so 720 is not much of an upgrade over 5!. 7! On the other hand adds another prime factor to it.
7! 5040 has the less than useful property of being quite large for interacting with human scales.
5! 120 however lacks fine precision required at human scale. Haven't done the math but it's probably something like using 3.1 as the analog of Pi.
360 seems like it might have been chosen based on a mix of precision and practicality. Many small prime factors ( 2 2 2 3 3 5 ). Also an extra prior prime factor for every added prime. 75600 too big, and 12 what analog clock faces use as their primary number.
360 is base 60. (6*60)
Like minutes and seconds.
The 12 hours in a day and the 12 months are also 60 / 5.
This all connects to ancient Mesopotamia somehow.
> 12 hours in a day
I guess, for a sufficiently large value of 12.
Yes, the original day was 12 hours. (Hence the legacy of "AM" and "PM" that some countries still use.)
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.
It wasn’t designed with British miles in mind.
https://en.m.wikipedia.org/wiki/History_of_the_metre
https://en.m.wikipedia.org/wiki/Arc_measurement_of_Delambre_...
I don’t think any common conversions fall near there other than miles->km. It’s certainly not the case that the systems were designed to have the golden ratio as conversions between the two.
1 mile = 1,000 [double] paces of 0.8m each = 1,600m
1m = 1e-10 times half-meridian from the North Pole to the equator, via Paris for a croissant, apparently.
So kind of a coincindence... But a very neat one. Meanwhile, ratio of adjacent Fibonacci numbers converves to some expression involving sqrt(5) which is approx 1.6
converges
Factorio logic applies as always - powers of 2 for trains belts etc. makes evenly splitting resources trivial.
Unfortunately belt speed gain per tier is linear and 1:3 blue:yellow belt.
but we have green belts now!
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.
> Some hardware circuits are a bit nicer with power-of-two sizes
Basically all FIFOs or addressable memory works far nicer with power-of-two sizes.
- Why not 12 bits?
Why not 10? 1 byte ~= 1k values. Nice easy conversions.
Weird bytelengths were very much the norm in early computing but noone (seemingly) ever mass-produced a 10 bit computer[1].
[1] https://en.wikipedia.org/wiki/Comparison_of_instruction_set_...I used to use a 32 bit bite! Then I has my wisdom teeth removed, and now I have a 28 bit bite.
hehe a bit nicer
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.
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.
Personally I think 12/48/96 would be more practical than the current 8/32/64. 32 bits is almost trivially easy to overflow whereas 48 bits is almost always enough when working with integers. And 64 bits is often insufficient or at least uncomfortably tight when packing bits together. Whereas by the time you've blown past 96 you should really just bust out the arrays and eat any overhead. Similarly I feel that 24 bits is also likely to be more practical than 16 bits in most cases.
12 bit color would have been great. In the old days 4 bits for each of RGB, or even packing 2 pixels per byte. Today 12 bit per channel would be awesome, although high end cameras seem to be at 14 (which doesn't fit bytes well either).
Instruction sets - 12 bits for small chips and 24 for large ones. RISC-V instructions encode better in 24bits if you use immediate data after the opcode instead of inside it.
Physical memory is topping out near 40bits of address space and some virtual address implementations don't even use 64 bits on modern systems.
Floating point is kinda iffy. 36 bits with more than 24bit mantissa would be good. not sure what would replace doubles.
Yeah it would be much more practical for color. 12 bit rgb4, 24 bit rgb8 or rgba6, and 48 bit rgb16 or rgba12 would all have proper alignment. The obvious rgb12 would obviate the need for the unholy mess of asymmetric 32 bit packed rgb formats we "enjoy" today.
Physical memory - Intel added support for 57 bits (up from 48 bits) in 2019, and AMD in 2022. 48 bit pointers obviously address the vast majority of needs. 96 bit pointers would make the developers of GC'd languages and VMs very happy (lots of tag bits).
For floats presumably you'd match the native sizes to maintain alignment. An f48 with a 10 bit exponent and an f96 with a 15 or 17 bit exponent. I doubt the former has any downsides relative to an f32 and the latter we've already had the equivalent of since forever in the form of 80 bit extended precision floats with a 16 bit exponent.
Amusingly I'm just now realizing that the Intel 80 bit representation has a wider exponent than IEEE binary128.
I guess high end hardware that supports f128 would either be f144 or f192. The latter maintains alignment so presumably that would win out. Anyway pretty much no one supports f128 in hardware to begin with.
The fixed point TI dsp chips always had a long int that was 48. Intel had 84 bit floating point registers before simd registers took over. And the pdp-11... Powers of two aren't as ubiquitous as it seems. If anything, the hardware uses whatever sizes it wants and that gets abstracted from the rest of the world by compilers and libraries.
The pdp-11 was 16-bit.
Thanks! I picked the only pdp that was actually a power of 2.
They probably meant PDP-8.
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
Mpact 2?
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.
Yup, M2 had 81-bit instructions, M1 had 72-bit ones
I mean the post is silly, why not just say 10 bit bytes lol, shit then bits/bytes could be metric lol
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.
We just need 3 valued electronics
The Soviets had ternary computers: https://en.wikipedia.org/wiki/Setun
Then they decided to abandon their indigenous technology in favour of copying Western designs
There was a very good reasons for it, indigenous designs were obsolete by the time they left the drawing boards and countless design bureaus cost stupid amounts of money while producing dozens of incompatible computers. By the time they decided to adopt ES EVM they lagged by some 5 years and continued to lag further behind.
Conversely, the Soviet Union took the PDP-11 ISA to its limits... including home computers with framebuffers and programmable calculators.
Setun apparently used two bits to represent a ternary value, wasting the 4th state.
We call that 1.58 bit now..
It already exists: True, False and FileNotFound.
If you don't believe me, just ask Paula Bean.
Paula Bean? Mr Bean photoshopped?
https://scontent-lax3-2.xx.fbcdn.net/v/t39.30808-6/476277134...
https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth
And https://thedailywtf.com/articles/The_Brillant_Paula_Bean
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.
But, but, what about Strange?
on, off, and the other thing
True, False and file not found
https://thedailywtf.com/articles/What_Is_Truth_0x3f_
hi-z is one choice. Though I don't know how well that does past a certain speed.
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.
I wasn't pitching it as a solid commercial idea. Just that you can get (perhaps fiddly) three states out into the real world with something cheap that already exists. Like: https://idle-spark.blogspot.com/2015/04/low-cost-n-ary-dacs-...
Using 8 way quadrature and high-z, you have 16 values packed into 1 quasi-hexalogic gate. May your hydration prove fruitful.
On, off, and ooh shiny!
null :)
Technically e would be best IIRC, but hard to implement, so 3 is the closest.
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.
why not 10 bit bytes and 40 bit addresses and nice 2 based metric based measures :)
If something is painful you aren't doing it often enough, right? So my (completely uninformed) idea would be 27 bit addresses that are only routable on the local LAN and then a second optional 27 bit address to route between LANs on the WAN. The effective 54 bit address space would have been more than large enough, and if you support modularly extending addresses like that then there's no reason not to keep going beyond the initial 2 by eating into the payload.
Being completely uninformed I have no idea how severe the negative consequences of this scheme would be for the efficiency of routing hardware but I assume it would probably be catastrophic for some reason or another.
That's very loosely how IPv6 works. Your ISP will typically assign your router a prefix and will route any address starting with that 56 or 64 bit prefix to you. Then devices on your network pick the remaining bits and they get their full address.
Well IPv4 also used to work that way back before address exhaustion. What I'm describing isn't an arbitrary allocation of a subset of a single fixed bit width address but rather two (or more) entirely disjoint address spaces.
Nothing NAT can't solve /s.
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.
Your first paragraph implies 8-bit bytes are a coincidence, which is not true. It was a design decision.
A byte in computer is the smallest addressable memory location and this location at that time contained a character. The way characters are encoded is called code. Early computers used 5-bits, which was not enough for alphabetics and numerals, 6 bits was not enough to encode numbers and lower and upper case characters, which eventually lead to ASCII.
ASCII was also designed(!) to make some operations simple, eg. turning text to upper or lower case only meant setting or clearing one bit if the code point was in a given range. This made some text operations much simpler and more performant, that is why pretty much everybody adopted ASCII.
Doing 7-bit ASCII operations with a 6-bit bytes is almost impossible and doing them with 18-bit words is wasteful.
When IBM was deciding on byte size a number of other options were considered, but the most advantageous was the 8-bit byte. Note that already with 8-bit bytes, this was over-provisioning space for character code, as ASCII was 7-bit. The extra bit offered quite some space for extra characters, which gave rise to character encodings. This isn't something I would expect a person living in the USA to know about, but users of other languages used upper 128 bytes for local and language specific characters.
When going with 8-bit byte, they also made the bytes individually addressable, making 32-bit integers actually 4 8-bit bytes. 8-bit byte also allowed to pack two BCD in one byte and you were able to get them out with a relatively simple operation.
Even though 8-bits was more than needed, they were deemed cost effective and "reasonably economical of storage space". And being a power of two allowed addressing a bit in a cost effective way, if a programmer needed to do so.
I think your post discounts and underestimates the amount of performance gain and cost optimisations 8-bit byte gave us at the time it mattered most, at the time computing power was low, and the fact that 8-bit bytes were just "good enough" and we didn't get anything usable from 9, 10, 12, 14 or 16 bit bytes.
On the other hand you overestimate the gains with imaginary problems, such as IPv4, which didn't even exist in 1960s (yes, we ran out of public space quite some time ago, no, not really a problem, even on pure IPv6 one has 6to4 NAT), or negative unix time - how on Earth did you get the idea that someone would use negative unix time stamps to represent historic datings, when most of the time we can't even be sure what year it was?
I think the most scary thing is having and odd-bit bytes; there would be a lot more people raging against the machine, if byte was 9 bits.
If you want to know why 8 bits, this is a good recap - https://jvns.ca/blog/2023/03/06/possible-reasons-8-bit-bytes... - along with the link to the book from the engineers who designed 8-bit bytes.
Given how many early computers had 18-bit or 36-bit words, the possibility of 9-bit bytes doesn’t seem as unrealistic as you suggest. I don’t see 8-bit bytes as being so inevitable.
8-bit bytes were not inevitable, but they are definitely not natural and they were designed. Clearly this design outcompeted alternatives.
> 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.
You don't want to switch code pages while processing the data unless you add extra fields to indicate code page, ISO 2022 style (or in fact old baudot shifts style)
Wouldn't the government department use the same code page at all times?
In EBCDIC world, not exactly, but all the place names being in one codepage is literally a return to why the accented names disappeared :)
I need you to explain your argument better.
If you were saying they lost accents outside the main 50 or whatever, I'd understand why 8 bits were a problem. But you're saying they lost accents as a general rule, right? Why did they lose accents that were right there on the US code pages? Why would that reason not extend to a 9 bit semi-universal EBCDIC?
I read the original mention as trying to claim that it could have been solved by allowance for multiple codepages.
But for processing data in one common database, especially back then, you wanted to keep to single variation - main reason for using a different codepage if you didn't work in language other than english was to use APL (later, special variant of US codepage was added to support writing C, which for hysterical raisins wasn't exactly nice to work with in US default EBCDIC codepage).
So there would not be an allowance for multiple codepages if only because codepage identifier could cut into 72 characters left on punched card after including sort numbers
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.
I'm curious what would have happened with gaming.. would we have gotten the NES?
I didn't recognise the word 'dren'. Asked an LLM.
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.
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.
There is certainly a well known bias or fallacy that describes this
> 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.
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.
> 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.
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.
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.
Android was nearly my real life example a la "IPv6 doesn't mandate anything be different, some guy at Android just likes doing things that way more". I.e. nothing needs to be changed in the IPv6 standard, there's just some guy on the Android team who really likes SLAAC and thinks DHCPv6 is an abomination.
Okay, but that's not useful. In practice in the real world you cannot run a v6 network the way you would a v4 network even if you want to. That you theoretically could go implement changes to bring them into line doesn't really affect that.
I think we're saying the same thing except I'm splitting the blame from IPv6 (which was very much about adding more bits) and placing it on the unrelated hobby horses people like whats-his-name on Android ride in on. Intentionally not supporting DHCP in the new protocol had nothing to do with the design of IPv6, it's just something they prefer.
To put it from another perspective: If the situation was reversed would you be blaming IPv4 and saying IPv4 should have been designed differently or would you just be asking why this guy from Android doesn't want to add DHCPv4 when DHCPv6 is supported? In both situations it's not IPv4/IPv6 to blame for the inconvenience, it's the guy taking advantage of the transition between protocols to do something stupid at the same time. No amount of changing the definition of IP is going to make them like DHCP, they'll always push some SLAAC-like address assignment onto users. The only reason they didn't for IPv4 was they came in after it was already the way instead of before networks were deployed and they could force it.
It's often very difficult to use IPv6 in practice, but not because IPv6 made it that way.
Oh, yes, we do (mostly) agree then. Thanks for clarifying:)
> 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.
Side note: I'm not sure why folks downvoted you. Even if they disagree it seems like an honest question.
> 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 (from whatever network configuration tool you use):
Which maps directly to: If you're also doing a static ARP to be "fully" static then you'll also have an additional config which boils down to something akin to: Which maps to this config to statically set the MAC instead of using ND: In both cases you either need to still locally respond to dynamic ARP/ND request or also statically configure the rest of the devices in the subnet (including the router) in a similar fashion, but there's not really much difference beyond the extra bits in the address.> 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 for IPv6 than IPv4 then that's entirely on what AWS likes to do rather than what IPv6 requires. E.g. if they only give you a dynamic link local gateway it's because they just don't want you to use a public address as the static gateway, not because IPv6 said it had to be so by not supporting unicast gateways or something.
There's also nothing about IPv6 ND that would make it take longer to discover the gateway from a statically configured unicast address than IPv4 ARP would take, but AWS may be doing a lot of optional stuff beyond just being a dumb gateway in their IPv6 implementation - again, not because IPv6 itself said it should be so but because they want to do whatever they are doing.
That's really helpful, thank you; I'll give that a try the next time I'm attempting to make this work.
(I'm doing this using direct netlink calls from my init; this is all about booting as fast as possible. The IPv6 address information is coming from instance metadata.)
You probably want to add the "optimistic" or "nodad" flags when adding the address, or you'll need to wait for DAD to finish.
I'd figured that specific detail out already, though it was hard-won knowledge. But there's a lot more where that came from before getting to the point of bringing up IPv6 and sending packets without dealing with slow RA and various other slow processes of waiting for data from the network, for instance.
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.
Author here. The point is that with 9-bit bytes we'd have designed IPv4 to have 36-bit addresses from the beginning. There wouldn't have been a transition.
The post I replied to was speculating on IPv4's life being extended by "simply making the numbers bigger" rather than having more bits per byte, but nevertheless... there still would've been a transition, delayed by at most a few years.
Exhaustion was raised for 32-bit IPv4 in the very early 90s, when we had a few million active Internet users. Allocations were very sparsely used and growth in Internet usage was exponential. It didn't take much of an imagination to foresee a problem.
A 36-bit Internet would be little better. By the middle of the 90s we had ~45 million active Internet users, ending our 16x space advantage, even assuming we didn't just squander that with 8x as wasteful Class A allocations and bigger spaces reserved for uses that will never arise.
Today, we have ~70 billion connected devices: 5-6 billion home subscribers each with multiple devices in the home, 7.5 billion smartphones, 20 billion IoT devices, and all growing rapidly.
We'd need NAT. But NAT was a response to exhaustion concerns, as a stop-gap measure to provide time to design and transition to a proper solution. If we didn't have exhaustion concerns, there'd be no NAT. If we did have exhaustion concerns, brought on perhaps by the lack of NAT, we'd still have invented IPv6, because we'd still have been able to forecast that the Internet would rapidly outgrow 36 bits of address space.
edit: disclaimer, I work in this space, but my comments reflect my own opinion and are not necessarily those of my employer.
Great reply, much appreciated. I searched a bit for a number like ~70B and didn't find one. Perhaps 36 bits wouldn't have actually worked. I do think we'd have wasted more Class As, but that's where the "minor market mechanisms" would have happened—most of the class As did get sold and would in this universe too. Again, if total internet-connected devices is now 70B that wouldn't help, you'd still need NATs.
It's extremely hard to get an accurate count of connected devices, so we're all just estimating. There's lots of sources giving rough values for things like smartphones or IoT devices, there's a reasonably common estimate of 5.6 billion connected Internet users, but it's largely guesswork for connected devices per user.
It's improbable that I'm off by an order of magnitude: 7 billion is far too low (we have 7.5 billion smartphones in the world!) and 700 billion is far too high; how low an estimate could we make without being unreasonably optimistic? 40b seems quite low to me - 7.5b smartphones, 5.6b connected users, 20b IoT devices, and commercial use of IPs - but if we took that value we'd be sitting at saturation for 36 bits of address space (60% utilisation is pretty darn good!) and the next decade would kind of suck.
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.
It's definitely more of an education issue. I still run into "IT" people that instinctively disable IPv6 no matter what. How do we fix this? The sad thing is IPv6 is actually easier in many respects: subnetting is simpler, no NAT hackery, SLAAC...
> I still run into "IT" people that instinctively disable IPv6 no matter what. How do we fix this?
- force ISPs to follow RIPE guidance on addressing (static prefix, at least /56 for every site, DHCPv6-PD)
- force the manufacturers of low-end routers (e.g. provided by ISPs) to have good IPv6 support (good firewalling, DHCPv6-PD, mDNS, PCP/UPNP, advertise static ULA prefix to have working local network even if internet connection is cut)
- force Android team to support DHCPv6
- force browsers to support full IPv6 addresses in URLs / URIs (link local addresses, scope id)
- force avahi / mDNS to support IPv6 scope id - make operating system manufacturers to have a better unified socket API which can resolve any type of address (IPv4, IPv6, DNS, mDNS, etc. maybe even URLs directly) and deprecate all other API
- make software developers to use this new API and don't try to parse IP addresses or URLs themselves
- have a good solution for multi-homing / WAN failover (without BGP and PI address space)
- have a good solution for mobile / roaming devices (phones, notebooks)
and maybe we could make IPv6 stable and universally working
(Waste a /40 for every company, get low on available prefixes and start over designing IPv8 to have 256 bit addresses with 184 bit host part...)
I'll assume you are speaking in good faith, so i'll reply so as well:
I do not want to be a "reasonably-skilled admin". Not my job nor desire. I want DHCP to work and NAT to exist which acts as a de-facto firewall and hides my internal network config from the outside world. All with zero or fewer clicks in my home router's config. With IPv4 this works. With IPv6 it does not. Simple choice for me then: find the IPv6 checkbox and turn it off, as usual.
> I do not want to be a "reasonably-skilled admin" > NAT to exist which acts as a de-facto firewall
My option is you should not handle router config at all and leave it to the ISP.
That's the fault of whoever designed the router, not IPv6.
As a consumer, I don’t care if it’s Santa Claus’s fault. IPv4: works, IPv6: doesn’t. I don’t even need to know what IPv6 means. I just need to know: Turn it off to make things work.
As a technologist, growing up involves learning not to blame the consumer. They are not holding it wrong, you just designed it in a dumb way.
And I'm not blaming the consumer.
If you want to come into a topic and say the problem is that IPv6 did too much, you can't fall back on "it doesn't matter who's at fault". Yes it does matter, that's what this thread is about, that and looking at how technological changes would have affected deployment.
It is forever tainted and I will put down money on a bet that when IPv4 is replaced (in the 2040s), it will be by something that will not be IPv6.
My main man, It is already IPv6 !
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.
The first transition was to IPv4, and it was reportedly (I wasn’t in the workforce yet :-) relatively easy…
https://www.internetsociety.org/blog/2016/09/final-report-on...
Some more interesting history reading here:
https://datatracker.ietf.org/doc/html/rfc33
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.
In early 00s my university in Poland had all computers at the campus connected to the internet with public IPs :) Thousands of computers - every lab, every room at dormitories and some for public use standing at the corridors at campus, all with unique public IPs cause they had so many :)
I think they had 19 bits of IP addresses available or sth crazy like that :) They were one of the institutions introducing internet in Poland back in 90s, so they had a huge portion of the addresses assigned and kept them.
Your argument can't be so strong as to imply that IPv4 should actually have used 24-bit addresses, though.
I thought the PDP 10 had 6-bit bytes, or at least 6-bit characters
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.
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.
-- 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.
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.
> It did have a Load Byte and a Store Byte instruction, which allowed you to select the byte size.
Were these instructions atomic regarding interrupts? If not, then these look like shorthands for masking/shifting bit-fields out of words, leaving the word as the smallest atomically addressable unit.
They are atomic, indeed. The underlying implementation might have used masking and shifting, especially in bit-slice implementations like KS-10, but as far as operation of the computer was concerned they were atomic.
It becomes problematic for multiprocessor systems but you could probably build a communications fabric and memory model that works.
My fantasy CPU lets you write to the (say) 15 bits starting at the 43rd but of a 48 bit word which a real CPU would have to do a lot of work to implement but with the right kind of cache it is probably not so bad, it also has an instruction to read a UTF-8 character at a deep pointer and increment the pointer which a real system could satisfy out of the cache except when it can’t.
For PDP-10, because it operated only on word values, you can easily assume that every bus and memory operation passes a full 36 bit word every time.
In fact, recent-ish x86 CPUs have similar instructions, and as of Zen4 they are fast not just on Intel but also on AMD (previously they were microcoded as a bunch of shifts AFAIK with pretty lousy latency)
The PDP-10 didn't really have bytes; it had 36-bit words.
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.
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
Multics never ran on PDP-10s, but on other 36-bit mainframes.
You are correct. The Sperry-Univac 1100 series though did have 36 bit words and 9 bit bytes.
IIRC, its instruction set supported words (36 bits), half words (18 bits), third words (12 bits), quad words (9 bits), and sixth words (6 bits).
For characters, 6 bits also was used at times, for example in its disk format. There, a severely limited character set wasn’t problematic.
> quad words
Shouldn't that be quarter words? Quad means quadruple.
The later versions (1100/60 and later) had loadable microcode. This allowed for some pretty nifty emulation options.
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.
That explains a lot.
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.
[flagged]
What do you think they missed? What they said seems accurate: You're putting a lot of faith in ChatGPT that doesn't seem warranted.
It's not an argument for longer roads or can kicking? The thesis is stated at the top: with 9 bit bytes we'd avoid a couple of bad numerological coincidence (like that the number of Chinese characters is vague but plausibly around 50k, or the population of the earth is small integer billions). By avoiding the coincidences we'd avoid certain problems entirely. Unicode is growing but we're not discovering another Chinese! Not will world population ever hit 130B, at least as it looks now.
If you think there's some equally bad coincidence go ahead and tell me but no one has yet. I think I do a good job of that in the post. (Also it's amazing you and maybe everyone else assume I know nothing except what ChatGPT told me? There are no ads on the website, it's got my name face and job on it, etc. I stand by what I wrote.)
Perhaps I misinterpreted your reply? It sounded like you were saying "read better" in response to the ChatGPT part, not the can-kicking part.
...but I do agree about the can-kicking. Why not 4, or 10? You'd have different pros and cons with each.
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.
What other cases are you thinking of?
> In what cases does doing from 8-bit bytes to 9-bit bytes result in something like a 2X penalty?
Self-correction: In what cases does going from 8-bit bytes to 9-bit bytes result in a penalty, and how much is it?
This must be the real reason of using 8-bit. But then why did they make 9-bit machine instead of 16-bit?
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.
[1] https://web.archive.org/web/20170404160423/http://archive.co...
[2] https://web.archive.org/web/20170404161611/http://archive.co...
> 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.
This is ignoring the natural fact that we have 8 bit bytes because programmers have 8 fingers.
No, we still have 10. Real programmers think in octal. ;)
Available. As they suck on their thumbs.
Most have 10. That's the reason we use base 10 for numbers, even though 12 would make a lot of things easier: https://en.wikipedia.org/wiki/Duodecimal
ISO reserves programmers thumbs to LGTM on pull requests
"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.
Author here. The argument was that by numerological coincidence, a couple of very important numbers (world population, written characters, seconds in an epoch, and plausible process memory usage) just happen to lie right near 2^16 / 2^32. I couldn't think of equally important numbers (for a computer) near ~260k or ~64B. We just got unlucky with the choice of 8-bit bytes.
Yeah, but hear me out - 10-bit bytes!
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.
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".
That's a very interesting bit of lore, I knew those were peculiar CPUs but I never know about these details, thank you!
I grew up down the road from a GI factory, so assumed everyone knew these things ;)
Crockford base32 would be great. it is 0–9, A–Z minus I, L, O, U.
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).
> 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.
When you think end-to-end for a whole system and do a cost-benefit analysis and find that skipping some letters helps, why wouldn't you do it?
But I'm guessing you have thought of this? Are you making a different argument? Does it survive contact with system-level thinking under a utilitarian calculus?
Designing good codes for people isn't just about reducing transcription errors in the abstract. It can have real-world impacts to businesses and lives.
Safety engineering is often considered boring until it is your tax money on the line or it hits close to home (e.g. the best friend of your sibling dies in a transportation-related accident.) For example, pointing and calling [1] is a simple habit that increases safety with only a small (even insignificant) time loss.
[1] https://en.wikipedia.org/wiki/Pointing_and_calling
You misunderstood me.
I started off by saying that 0-9a-v digits was "a bit extreme", which was a pretty blatant euphemism — I think that's a terrible idea.
Visually ambiguous symbols are a well-known problem, and choosing your alphabet carefully to avoid ambiguity is a tried and true way to make that sort of thing less terrible. My point was, rather, that the moment you suggest changing the alphabet you're using to avoid ambiguity should also be the moment you wonder whether using such a large number base is a good idea to begin with.
In the context of the original discussion around using larger bytes, the fact that we're even having a discussion about skipping ambiguous symbols is an argument against using 10-bit bytes. The ergonomics or actually writing the damned things is just plain poor. Forget skipping o, O, l and I, 5 bit nibbles are just a bad idea no matter what symbols you use, and this is a good enough reason to prefer either 9-bit bytes (three octal digits) or 12-bit bytes (four octal or three hex digits).
Clearly it should be 12 bits, that way you could use either 3 hex digits or 4 octal ones. ~
Alternate world where the pdp-8 evolved into our modern processors.
5 bit nibbles could just be Baudot Code (A-Z + some control characters).
Came here to say that. But to my knowledge there has never been any computers based on 5 bits.
why stop there? 16-bit bytes would be so much cleaner
UTF-16 enters the chat..
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.
Having 0-1000 fit inside a byte would be great. 1 byte for tonnes, 1 for kg, 1 for g, 1 for mg. Same with meters, liters, etc. Would work great with metric.
Or addressing 1 TB of memory with 4 bytes, and each byte is the next unit: 1st byte is GB, 2nd byte is MB, 3rd byte is KB, 4th byte is just bytes.
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.
Uh oh. Looks like humanity has been bitten by the bit byte bug.
deleted
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?
Same, we all have access to the LLM too, but I go to forums for human thoughts.
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.
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
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.
This article reminds me a lot of a conversation with an expert DBA recently. We were talking about performance improvements and he said that upgrading hardware is almost negligible. Upgrading from HDD to SSD gives you 10x boost. SSD to nvme maybe 4x. But optimizing queries and fixing indexes can give you 100x or 1000x improvements.
Of course, every little bit counts, so we still did upgrade the hardware, but (at least in our area), almost all speed improvements came from code optimization.
This article is talking about kicking the ipv4 can down down the road only 10 years and increasing process memory from 2G to 32G. Seems like such small fries when we could just double it and move on. If you brought the 2038 problem to Unix devs, I'm sure they would have said "thanks! We'll start with 64-bit" instead of "yes... Let's use an unaligned 36 bits so the problem is hidden slightly longer".
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.
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.
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.
As well as extra bits in the Z buffer to give it a 15.3 fixed point format.
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.
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.
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.
There was a time, however, where CPUs operated almost exclusively on on 8bit bytes (and had 8bit data buses). Everything else is merely the consequence of that.
Quick note that this isn't true. 8-bit CPUs are newer than 36-bit CPUs, and 8-bit bytes were established long before 8-bit CPUs came on the scene. Prior to the mid-70s most machines were word-addressed. The adoption of byte addressing (the subject of the grandparent) gained traction after C and similar languages became popular. C was developed on the pdp-11 which supported byte addressing and it provided a compatible memory model: any pointer value could be de-referenced to a byte. The VAX followed, also with byte addressing and by 1980 you couldn't sell a CPU that didn't support byte addressing (because C wouldn't work with it). 8-bit CPUs had nothing to do with any of this.
What you say is correct except for the very last part which is inaccurate. C works with word-addressed CPUs (I can see one from here, and it has a C compiler. And was, incidentally, sold into the early nineties). What C needs is a way to work with 8-bit characters, that's all (and even that isn't 100% true, just widely expected). So what a C compiler needs on, say, a 16-bit addressable computer, is a way to access a char, an 8-bit entity (everything else, e.g. int, long etc., is up to the architecture). And that can be done by software, or more typically by the CPU having opcodes to access 8-bit fields within its native addressable word size.
The comment was about why CPUs still use byte addressing even today. And it's my belief that's due to incomparably wide proliferation of 8bit computers.
Even CPUs that were 32bit with a 16bit data bus, like the 68000 series, required the ability to read and write single bytes to support the wide range of 8bit I/O chips including UARTs, timers, floppy-disk controllers, video controllers that were common at the time. The 8bit bus was king for a long time.
The evolution of Intel CPUs started with 4-bits
The C "char" type need not be 8-bit at all. *nix operating systems enforce 8-bit bytes, but that's historically due to the primacy of text streams on that platform, and is to some extent an arbitrary choice.
Byte addressing is really useful for string handling.
10 bit is even better according to all these criteria AND it fits 0-1000 into one byte which meshes really well with metric system (0 to 1 km in meters, 0 to 1 liter in ml, etc.)
You could even do binary-encoded-metric-numbers that you can decode as needed one byte at a time - the first byte is tonnes, the second is kilograms, the third is grams, the 4th is milligrams, and you only lose 23 out of 1024 values at each level.
Same (but without loses) with data sizes. 1st bit is gigabytes, 2nd is megabytes, 3rd is kilobytes, 4th is bytes.
And of course at one point many computers used 40-bit floating point format which would fit nicely into our 4 bytes.
10-bit bytes would consist of two 5-bit nibbles, which you could use for two case-insensitive letters (for example Baudot Code was 5-bit). So you could still do hex-like 2-letter representation. Or you could send case-insensitive letters at 2 letters per byte.
40 bit could address 1 TB of memory (of 10-bit values - so much more than 1TB of 8-bit values). We could still be on 4-byte memory addressing to this day which would make all pointers 4-byte which would save us memory.
And so on.
But ultimately it always had to be power-of-two for cheaper hardware.
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.
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.
Our capability to mispredict wouldn't have been different. We would have still picked the wrong size, and got stuck with scaling problems.
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.
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.
As the UTF encodings have shown you can put any encoding in any bitform if need be.
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.
Author here, copied from another comment above.
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, a lucky coincidence meaning the consumer internet would largely require another transition anyway. 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.
I used to think, how the history of computing and Internet would look like, if computers converged on 3-base system, with trits instead of bits, and trytes instead of bytes.
If one tryte was 9 trites, it would have 3^3=19693 values. All the European characters and a lot of others can be encoded with this. There would be no need to invent char/int integer types in C (with the added mess of short, short short, long, and long long) int would be enough at the time. Maybe at the point when it would become necessary to add different integer types, C would choose a saner approach of stdint.h, and there would be no legacy code playing with legacy integer types?
And 27 trites (or 3 trytes) is around 2^42.8 values, like 42 bits. It would be enough even now, I think.
binary is far easier to do in electronics (on or off)
> Thank you to GPT 4o and o4 for discussions, research, and drafting.
Yeah okay, this is completely pointless... so now we have to verify everything this guy published ?
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.
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.
Perhaps the reason modern programs use so much memory vs what I remember from the Windows XP era is precisely because we went to 64 bits. Imagine how many pointers are used in the average program. When we switched over to 64 bits, the memory used by all those pointers instantly doubled. It's clear that 32 bits wasn't enough, but maybe some intermediate number between 32 and 64 would have added sufficient capacity without wasting a ton of extra space.
> Imagine how many pointers are used in the average program. When we switched over to 64 bits, the memory used by all those pointers instantly doubled.
This is a very real issue (not just on the Windows platform, either) but well-coded software can recover much of that space by using arena allocation and storing indexes instead of general pointers. It would also be nice if we could easily restrict the system allocator to staying within some arbitrary fraction of the program's virtual address space - then we could simply go back to 4-byte general pointers (provided that all library code was updated in due course to support this too) and not even need to mess with arenas.
(We need this anyway to support programs that assume a 48-bit virtual address space on newer systems with 56-bit virtual addresses. Might as well deal with the 32-bit case too.)
I agree that's wasteful, but if software were only 2x bigger, we'd be in really good shape now. Unfortunately there are still another one or two more orders of magnitude to account for somehow.
SGI used three ABIs for their 64-bit computers.. O32, N32, N64. N32 was 64-bit except for pointers which were still 32 bits for exactly that reason - to avoid doubling the memory needed for storing pointers.
https://en.wikipedia.org/wiki/X32_ABI
The x32 ABI has 32-bit integers and pointers, while still running in long mode with full access to modern CPU features and instructions
Because of aligned reads any pointer size between 32-bit and 64-bit would end up using 64-bits anyway.
With 8-bit bytes, yes.
Maybe if we worked with 7-bit bytes folks would be more grateful.
For those that don't get it, I'll explain.
Imagine an alternative world that used 7-bit bytes. In that world, Pavel Panchekha wrote a blog post titled "We'd be Better Off with 8-bit Bytes". It was so popular that most people in that world look up to us, the 8-bit-byters.
So to summarize, people that don't exist* are looking up to us now.
* in our universe at least (see Tegmark's Level III Multiverse): https://space.mit.edu/home/tegmark/crazy.html or Wikipedia
Didn't follow how Github not supporting IPv6 is caused by the "wrong" byte size. Wouldn't 36 bit IP adresses have made that a non-topic?
The author seems to assume Github! is a leader. The masses in IT never have followed leading technology. How many Microsoft engineers do you need to change a light bulb? Zero, MS makes darkness an industry standard.
Are Github actions the leading CI technology?
Most proposals for 9 bit bytes weren't for adopting 8 bits of data in a byte, they were to have 8 bits for data and 1 bit for something else, typically either error detection or differentiating between control/data. Very few folks argued for 9 bit bytes in the sense of having 9 bits of data per byte.
9 bit bytes never made significant headway because a 12.5% overhead cost for any of these alternatives is pretty wild. But there are folks and were folks then who thought it was worth debating and there certainly are advantages to it, especially if you look at use beyond memory storage. (i.e. closer to "Harvard" architecture separation between data / code and security implications around strict separation of control / data in applications like networking.)
It's worth noting that SECDED ECC memory adds about a 20% overhead, though it can correct single bit flips whereas 9-bit bytes with a parity bit can only detect (but not correct) bit flips which makes it useful in theory but not very useful in practice.
I just consider ourselves lucky, that we're not stuck with 6- or 7-bit bytes in ASCII-land and made it to Code page 437.
https://en.wikipedia.org/wiki/Six-bit_character_code
That's what the PDP-10 community was saying decades ago.
I guess nibbles would be 3 bits and you'd 3 per byte?
This article's setup seems to be: we could go back and change bytes to be 9 bits, but make all the same decisions for sizes of things as we did, so that everything would be the same now except we'd have a little more room.
A measly factor 16 doesn't really make it worth having to deal with non-power of two sizes. You're also assuming that everything would have used the same number of bites when most sizes are chosen based on how much was needed at the time or in the foreseeable future - with 9 bit bytes that would just have meant that we're just going to run out earlier for different things than with 8 bit bytes.
> IPv4: Everyone knows the story: IPv4 had 32-bit addresses, so about 4 billion total.44 Less due to various reserved subnets. That's not enough in a world with 8 billion humans, and that's lead to NATs, more active network middleware, and the impossibly glacial pace of IPv6 roll-out. It's 2025 and Github—Github!—doesn't support IPv6. But in a world with 9-bit bytes 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.
Only if you assume there is only one device per human, which is ridiculous.
> Unicode: In our universe, there are 65 thousand 16-bit characters, which looked like maybe enough for all the world's languages, assuming you're really careful about which Chinese characters you let in.77 Known as CJK unification, a real design flaw in Unicode that we're stuck with. With 9-bit bytes we'd have 262 thousand 18-bit characters instead, which would totally be enough—there are only 155 thousand Unicode characters today, and that's with all the cat smileys and emojis we can dream of. UTF-9 would be thought of more as a compression format and largely sidelined by GZip.
Which would be a lot worse than the current situation because most text like data only uses 8 bits per character. Text isn't just what humans type and includes tons of computer generated ASCII constructs.
Not to mention that now it becomes an active process to upgrade ASCII data to Unicode, which would have the argument of increased size against it for many files and thus files and formats without Unicode support would have stuck around for much longer.
UTF-8 might have been an accident of history in many ways but we really couldn't have wished for something better.
> 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.
10-bt bytes seems a bit more logical as atleast its a recognizable base
Of course, if that happens we'll get an article demanding 10-bit bytes.
Got to stop somewhere.
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...)
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.
The term "octet" is still widely used in protocol descriptions and some other fields (source: All those interface specifications I have to read through my job)
PDP-8 has a 12-bit word size
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?)
Author here. I agree that this would have a similar effect; we'd probably still end up with 36-bit or 48-bit IP addresses (though 30-bit would have been possible and bad). We'd probably end up with a transition from 24-bit to 48-bit addresses. 18-bit Unicode still seems likely. Not sure how big timestamps would end up being; 30-bit is possible and bad, but 48-bit seems more likely.
Some early mainframes used 6-bit characters which is why they didn't have lowercase.
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.
What if the first bits told you how long the byte was, and you just kept reading the length of the byte until you got some terminating sequence, then that would be followed by some error correction for the length and terminating sequence with a couple more terminating sequences, one could be ignored since once might be corrupted, following by a variable length byte, with its own error correction and more error correction? It’s just so obvious y’all!
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?)
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.
Now a C++ proposal to define a byte as 8 bits
https://isocpp.org/files/papers/P3477R1.html
I worked in C for a DSP chip where the smallest data type was 16 bits. It was less than a decade ago.
was that assumption in C code really unnecessary? i suppose it made many things much easier.
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.
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.
Would you want the main function to be:
How about struct tm? What for? Or do we "shrink wrap" every field to the smallest type? "uint8_t tm_hour"?You'd define architecture-specific typedefs to deal with these cases in a portable way. The C standard already has types like int_fast8_t that are similar in principle.
See, why would you need an "architecture specific typedef" in order to represent the day of the month, or the number of arguments in main "in a portable way". int does it in a portable way already.
It's just muddled thinking.
int is architecture specific too, and it's been "muddled" plenty due to backward compatibility concerns. Using typedefs throughout would be a cleaner choice if we were starting from scratch.
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. :)
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.
[flagged]
But why stop there? based on your arguments 10-bit bytes would be even more better.
I can think of only one flavor in favor of 9 bit bytes: variable length integers. The 9th bit would indicate there is more data to come. This would apply to instructions too. A homo iconic ISA, anyone?
I don't think at the time ASCII was being "upgraded" with localized 8-bit codepages, Greek would have had primacy over, say, Cyrillic.
I wonder what came first, CP737 for Greek or CP855 and CP866 for Cyrillic.
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).
Funny thing is we sort-of got 36bit addressing mainstream with PAE in the 32bit x86 age.
We sort of got 16 + 4 = 20 bit addressing in the 16 bit x86 age too.
Then people would be saying we’d be better off with 10-bits!
Seriously though we can always do more with one more bit. That doesn’t mean we’d be better off. 8-bits is a nice symmetry with powers of two
10-bit bytes would also be tempting, as 1024 is so close to 1000 and it would make bytes follow an orders of magnitude progression. It would just be so much easier on mental arithmetic too.
If we had gone the way of -1, 0, and 1 like some Soviet systems did this would be two "bits"
Look I'm not a computer scientist, I admit this is naive. But for the thought experiment...
Rather than extra bits, we may end up with ternary computers for AI. That's right, ternary is back with a new name: 1.58 bits
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 :)
I worked on 29 bit machine and never actually noticed it, probably because it's the least of your problem when you use 1960's hardware lol
> Thank you to GPT 4o and o4 for discussions, research, and drafting.
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.
I often wondered why not make the word 10 bits, so that unsigned char is 0..1023 (basically 1,000). I guess hardware considerations make sense.
9-bit bytes could easily make the common case ~12.5% slower everywhere. Most integers and chars fit in 8 bits no problem.
Panchekha is on a roll lately, I just read all of his recent posts a week ago. I really liked his AI vs Herbie series.
Thanks
If bytes weren't 8 bits, why would IPv4 addresses contain 4 bytes? Shouldn't they contain 3, or 9?
It would also make Base64 a bit simpler (pun intended), at the cost of a little more overhead (50% instead of 33%).
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.
The point of Base64 is to represent binary data using a familiar character repertoire. At least for the latin-script world, any collection of 256 characters won’t be a familiar character repertoire.
Who told you that? Don’t talk to that person anymore.
Base64 and uuencode before it are about transmitting binary data over systems that cannot handle binary. There are a bunch of systems in the early Internet that could only communicate 7 bits per byte, which is why uuencode uses only printable low ASCII characters. Has nothing to do with familiarity.
Systems that supported eight bits per byte were referred to as “8 bit clean”, to distinguish them from legacy systems you might still have to support.
PNG file format was specced in 1995, and it was still worried about 8 bit clean transmission. The first byte of the PNG magic number has the high bit set because they didn’t want the decoder to even have to bother with broken PNG files.
> Base64 is also widely used for sending e-mail attachments, because SMTP – in its original form – was designed to transport 7-bit ASCII characters only. Encoding an attachment as Base64 before sending, and then decoding when received, assures older SMTP servers will not interfere with the attachment.
I think it’s reasonable to assume that in a world with 9 bit bytes, someone may have chosen 8 bits for SMTP, or moved to 8 bit sooner. Which would give you at least Base128.
> a little more overhead (50% instead of 33%)
a little?
A 12.5% increase, or 1/8. Yes, a little. Compared to, say, hexadecimal, which would be a 50% increase. Or URL percent-encoding, which would be a 125% increase.
I will think about this post every time I hear the expression "it won't change things one bit".
> Though you still see RFCs use "octet"
Author seems to be unaware that octet is etymologically linked to 8.
I understand the author's point to be that, if RFC writers understood "byte" to imply eight bits, they wouldn't go out of their way to use the word "octet" instead when referring to eight bits.
Ah indeed that's it, my misunderstanding!
Lisp implementors would love additional bits for tagging pointers more efficiently.
Many old 8-bit processors was basically 9-bit processors once you considered the carry flag.
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.
also: https://imgs.xkcd.com/comics/standards_2x.png
Let's go ternary!
They call it the programmer's dozen, 9 bits for a byte
And if a foot were 13 inches, the numbers on your car's speedometer would be smaller. What is the point of this post?
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.
someone suggested 10-bit bytes. this will not be enough. 11-bit bytes should be plenty, though
Yeah uh, moving ISP's from IPv4 to IPv6 has been a headache, moving backwards to IPv4-9BIT would fuck things even harder.
This is such a dumb article. All of those examples are nonsense. We can also have thousands of examples about how 6 bits is enough or 10 bits is just right.
Hacker News needs, “potentially slop” button.
If 9 bits sounds nice wait until you hear about 16 bits
“It goes up to 1011!”
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.
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.
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.
As soon as that's my baseline assumption, I think I'm done with the internet. I can get LLM slop on my own.
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.
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.
> I contains (sic) factual errors that stand out like lighthouses showing the author had an idea about an article but doesn't actually know the material.
Whoops ^ To be fair, technically, I also contain some factual errors, if you consider the rare genetic mutation or botched DNA transcription.
So far, I haven't found anything that I would consider to be a glaring factual error. What did I miss?
I'm not talking merely about a difference in imagination of how the past might have unfolded. If you view this as an alternative history, I think the author made a plausible case. Certainly not the only way; reasonable people can disagree.
Sorry about that 't'. It was (very) late.
I meant it was readable. It's speculative but it's well-informed speculation, not clueless nonsense. I agree that fact checking becomes more important because LLMs hallucinate. I feel the same about vibe coding. If you don't know much about programming then running vibe code is a risky bet (depending on the criticality of the problem)
Author here, in fact all the words you read I wrote, LLMs are not very good at writing.
That matches my experience too.
[flagged]
We detached this comment from https://news.ycombinator.com/item?id=44818867 and marked it off topic.