We'd be better off with 9-bit bytes
pavpanchekha.com
pavpanchekha.com
Then they decided to abandon their indigenous technology in favour of copying Western designs
If you don't believe me, just ask Paula Bean.
You could have the equivalent of 45-bit numbers ( 44 + parity ). And you could have the operands of two 15 bit numbers and their result encoded in 9 quint-bits or quits. Go pro or go home.
"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.
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.
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.
It had 512 72-bit registers and was very SIMD/VLIW, was probably the only machine ever with 81-bit instructions
If memory serves, I had a Creative Labs DXR2 that I almost immediately regretted.
PDP-10 could do 9-bit (or 7, or 6) bytes into 36-bit words. It seems like something that would be fun for 1-2 days.
1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, and 60
Obviously not an emergent property but shows how these things were designed.
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
https://en.m.wikipedia.org/wiki/History_of_the_metre
https://en.m.wikipedia.org/wiki/Arc_measurement_of_Delambre_...
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.
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.
I guess, for a sufficiently large value of 12.
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.
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
¹ https://mathworld.wolfram.com/SuperiorHighlyCompositeNumber....
By this logic, 0.016 (recurring) seconds should be a called a "third".
"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:
Commodores had a 1/60 second "jiffy" for timing interrupts, that's all I could find.
Later societies inherited that from them along with 60 minutes in and hour.
It sounds useful to be able to count up until 60 on two hands.
"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").
Now do PI!
Then Tom Lehrer's New Math.
This was done for graphics reasons, native antialiasing if I understand it. The cpu can't use it. it still only sees 8-bit bytes.
https://www.youtube.com/watch?v=DotEVFFv-tk (Kaze Emanuar - The Nintendo 64 has more RAM than you think)
To summarize the relevant part of the video. The RDP wants to store pixel color in 18 bits 5 bits red 5 bits blue 5 bits green 3 bits triangle coverage it then uses this coverage information to calculate a primitive but fast antialiasing. so SGI went with two 9-bit bytes for each pixel and magic in the RDP(remember it's also the memory controller) so the cpu sees the 8-bit bytes it expects.
Memory on N64 is very weird it is basicly the same idea as PCIE but for the main memory. PCI big fat bus that is hard to speed up. PCIE small narrow super fast bus. So the cpu was clocked at 93 MHz but the memory was a 9-bit bus clocked at 250 MHz. They were hoping this super fast narrow memory would be enough for everyone but having the graphics card also be the memory controller proved to make the graphics very sensitive to memory load. to the point that the main thing that helps a n64 game get higher frame rate is to have the cpu do as few memory lookups as possible. which in practical terms means having it idle as much as possible. This has a strange side effect that while a common optimizing operation for most architectures is to trade calculation for memory(unroll loops, lookup tables...) on the N64 it can be the opposite. If you can make your code do more calculation with less memory you can utilize the cpu better because it is mostly sitting idle to give the RDP most of the memory bandwidth.
That really depends. A cache miss adds eons of latency thus is far worse than doing a few extra cycles of work but depending on the workload the reorder buffer might manage to negate the negative impact entirely. Memory bandwidth as a whole is also incredibly scarce relative to CPU clock cycles.
The only time it's a sure win is if you trade instruction count for data in registers or L1 cache hits but those are themselves very scarce resources.
In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers. It doesn't address more than 4 GB of anything ever
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).
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).
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.
----
[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.
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.
That said, "16bit curious" is a great term :D
It certainly can punch well above its weight class, at least when compared with 6502 z80 and some others.
I really can't call it 16 bit, because of the small address space, and the fact that the ALU is 8-bit. But you can't always go by the ALU because I believe the z80 and 8080 have four bit ALUs. And I don't think there's anyone that would call those chips four bit.
Motorola seemed to design things in a specific way that people really liked, and this pushing the limits of what is an expert design seems to be one of those because even going back to the 6800, the one index register was 16 bit.
And lastly the 68k is an exemplary design, but in the same design language is 32 bit curious.
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.
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).
Basically all FIFOs or addressable memory works far nicer with power-of-two sizes.
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..
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.
I don't think this is enough of a reason, though.
Thinking about the number of bits in the address is only one of the design parameters. The partitioning between network masks and host space is another design decision. The decision to reserve class D and class E space yet another. More room for hosts is good. More networks in the routing table is not.
Okay, so if v4 addresses were composed of four 9-bit bytes instead of four 8-bit octets, how would the early classful networks shaken out? It doesn't do a lot of good if a class C network is still defined by the last byte.
With so many huge changes like those the alternate history by today would be far diverged from this universe.
The knock-on effect of EBCDIC having room for accented characters would have been the U.S.A. not changing a lot of placenames when the federal government made the GNIS in the 1970s and 1980s, for example. MS-DOS might have ended up with a 255-character command-tail limit, meaning that possibly some historically important people would never have been motivated to learn the response file form of the Microsoft LINK command. People would not have hit a 256-character limit on path lengths on DOS+Windows.
Teletext would never have needed national variants, would have had different graphics, would have needed a higher bitrate, might have lasted longer, and people in the U.K. would have possibly never seen that dog on 4-Tel. Octal would have been more convenient than hexadecimal, and a lot of hexadecimal programming puns would never have been made. C-style programming languages might have had more punctuation to use for operators.
Ð or Ç could have been MS-DOS drive letters. Microsoft could have spelled its name with other characters, and we could all be today reminiscing about µs-dos. The ZX Spectrum could have been more like the Oric. The FAT12 filesystem format would never have happened. dBase 2 files would have had bigger fields. People could have put more things on their PATHs in DOS, and some historically important person would perhaps have never needed to learn how to write .BAT files and gone on to a career in computing.
The Domain Name System would have had a significantly different history, with longer label limits, more characters, and possibly case sensitivity if non-English letters with quirky capitalization rules had been common in SBCS in 1981. EDNS0 might never have happened or been wildly different. RGB 5-6-5 encoding would never have happened; and "true colour" might have ended up as a 12-12-12 format with nothing to spare for an alpha channel. 81-bit or 72-bit IEEE 754 floating point might have happened.
"Multimedia" and "Internet" keyboards would not have bumped up against a limit of 127 key scancodes, and there are a couple of luminaries known for explaining the gynmastics of PS/2 scancodes who would have not had to devote so much of their time to that, and possibly might not have ended up as luminaries at all. Bugs in several famous pieces of software that occurred after 49.7 days would have either occurred much sooner or much later.
Actual intelligence is needed for this sort of science fiction alternative history construction.
I 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.
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?
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
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.
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.
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.
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.
Maybe there would have been push to change at some point as there would have been real limits in place.
After all, we were supposed to switch off IPv4 in 1990...
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.
Or we would have had 27 bit addresses and ran into problems sooner.
But on the other hand, if we had run out sooner, perhaps IPv4 wouldn't be as entrenched and people would've been more willing to switch. Maybe not, of course, but it's at least a possibility.
Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.
They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.
Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.
Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
> 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
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
ip neigh add 192.168.1.50 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent
ip -6 neigh add 2001:db8:abcd:0012::2 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent
> 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.
(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.)
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.
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 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.
My option is you should not handle router config at all and leave it to the ISP.
- 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...)
And no interoperability between the two without stateful network address translation.
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.
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.
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.
https://www.internetsociety.org/blog/2016/09/final-report-on...
Some more interesting history reading here:
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.
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.
https://en.wikipedia.org/wiki/Six-bit_character_code#DEC_SIX...
Notably the PDP 8 had 12 bit words (2x6) and the PDP 10 had 36 bit words (6x6)
Notably the PDP 10 had addressing modes where it could address a run of bits inside a word so it was adaptable to working with data from other systems. I've got some notes on a fantasy computer that has 48-bit words (fit inside a Javascript double!) and a mechanism like the PDP 10 where you can write "deep pointers" that have a bit offset and length that can even hang into the next word, with the length set to zero bits this could address UTF-8 character sequences. Think of a world where something like the PDP 10 inspired microcomputers, was used by people who used CJK characters and has a video system that would make the NeoGeo blush. Crazy I know.
The article says:
> A number of 70s computing systems had nine-bit bytes, most prominently the PDP-10
This is false. If you ask ChatGPT "Was the PDP-10 a 9 bit computer?" it says "Yes, the PDP-10 used a 36-bit word size, and it treated characters as 9-bit bytes."
But if you ask any other LLM or look it up on Wikipedia, you see that:
> Some aspects of the instruction set are unusual, most notably the byte instructions, which operate on bit fields of any size from 1 to 36 bits inclusive, according to the general definition of a byte as a contiguous sequence of a fixed number of bits.
-- https://en.wikipedia.org/wiki/PDP-10
So PDP-10 didn't have 9-bit bytes, but could support them. Characters were typically 6 bytes, but 7-bit and 9-bit characters were also sometimes used.
My first machines were the IBM 7044 (36-bit word) and the PDP-8 (12-bit word), and I must admit to a certain nostalgia for that style of machine (as well as the fact that a 36-bit word gives you some extra floating-point precision), but as others have pointed out, there are good reasons for power-of-2 byte and word sizes.
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.
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.
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)
For characters, 6 bits also was used at times, for example in its disk format. There, a severely limited character set wasn’t problematic.
Shouldn't that be quarter words? Quad means quadruple.
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.
> Thank you to GPT 4o and o4 for discussions, research, and drafting.
That explains a lot.
[1] https://web.archive.org/web/20170404160423/http://archive.co...
[2] https://web.archive.org/web/20170404161611/http://archive.co...
One possibility would be bit-indexed addressing. For the 9-bit case, yes, such an index would need 4 bits. If one wanted to keep nice instruction set encoding nice and clean, that would result in an underutilized 4th bit. Coming up with a more complex encoding would cost silicon.
What other cases are you thinking of?
Self-correction: In what cases does going from 8-bit bytes to 9-bit bytes result in a penalty, and how much is it?
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.
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.
10 bit bytes would give us 5-bit nibbles. That would be 0-9a-v digits, which seems a bit extreme.
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).
GI made 10-bit ROMs so that you wouldn't waste 37.5% of your ROM space storing those 6 reserved bits for every opcode. Storing your instructions in 10-bit ROM instead of 16-bit ROM meant that if you needed to store 16-bit data in your ROM you would have to store it in two parts. They had a special instruction that would handle that.
The Mattel Intellivision used a CP1610 and used the 10-bit ROM.
The term Intellivision programmers used for a 10-bit quantity was "decle". Half a decle was a "nickel".
What's the point?
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.
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".
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.
If accessing a bit is really accessing a larger block and throwing away most of it in every case, then the additional byte grouping isn't really helping much.
A one-bit wide bus ... er, wire, now, I guess ... Could work just fine, but now we are extremely limited with the number of operations achievable, as well as the amount of addressable data: an eight-bit address can now only reference a maximum of 32 bytes of data, which is so small as to be effectively useless.
It's an arbitrary grouping, and worse, it's rarely useful to think in terms of it. If you are optimizing access patterns, then you are thinking in terms of CPU words, cache line sizes, memory pages, and disk sectors. None of those are bytes.
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
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.
64-bit pointers are pretty spacious and have "spare" bits for metadata (e.g. PAC, NaN-boxing). 72-bit pointers are even better I suppose, but their adoption would've come later.
A big part of the move to 8bit systems was that it allowed expanded text systems with letter casing, punctuation and various ASCII stuff.
We could move to the world of Fortran 36bit if really needed and solve all these problems while introducing a problem called Fortran.
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.
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.
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.
Yeah okay, this is completely pointless... so now we have to verify everything this guy published ?
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.
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.)
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
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?
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.
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.
> 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.
Got to stop somewhere.
A reminder of that past history is that in Internet standards documents, the word "octet" is used to unambiguously refer to an 8-bit byte. Also, "octet" is the French word for byte, so a "gigaoctet (Go)" is a gigabyte (GB) in English.
(Now, if only we could pin down the sizes of C/C++'s char/short/int/long/long-long integer types...)
Octad/octade was unambiguously about 8 bit bytes, but fell out of popular usage.
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.
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.
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.
int32_t main(int32_t argc, char **argv)?
struct tm {$
int32_t tm_sec; /* Seconds (0-60) */$
int32_t tm_min; /* Minutes (0-59) */$
int32_t tm_hour; /* Hours (0-23) */$
int32_t tm_mday; /* Day of the month (1-31) */$
int32_t tm_mon; /* Month (0-11) */$
int32_t tm_year; /* Year - 1900 */$
int32_t tm_wday; /* Day of the week (0-6, Sunday = 0) */$
int32_t tm_yday; /* Day in the year (0-365, 1 Jan = 0) */$
int32_t tm_isdst; /* Daylight saving time */$
};
It's just muddled thinking.
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. :)
I wonder what came first, CP737 for Greek or CP855 and CP866 for Cyrillic.
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
Look I'm not a computer scientist, I admit this is naive. But for the thought experiment...
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.
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?
Author seems to be unaware that octet is etymologically linked to 8.
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.
At first I thought that was a nice way to handle credit, but on further thought I wonder if this is necessary because the base line assumption is that everyone is using LLMs to help them write.
Thank you to Android for mobile Internet connectivity, browsing, and typing.
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.