We'd be better off with 9-bit bytes

https://pavpanchekha.com/blog/9bit.html

by luu • 12 months ago

188 342 12 months ago

pavpanchekha.com

FrankWilhoit• 12 months ago

That's what the PDP-10 community was saying decades ago.

Keyframe• 12 months ago

Yeah, but hear me out - 10-bit bytes!

Waterluvian• 12 months ago

Uh oh. Looks like humanity has been bitten by the bit byte bug.

pdpi3• 12 months ago

One of the nice features of 8 bit bytes is being able to break them into two hex nibbles. 9 bits breaks that, though you could do three octal digits instead I suppose.

10 bit bytes would give us 5-bit nibbles. That would be 0-9a-v digits, which seems a bit extreme.

pratyahava7• 12 months ago

Crockford base32 would be great. it is 0–9, A–Z minus I, L, O, U.

int_19h• 12 months ago

Clearly it should be 12 bits, that way you could use either 3 hex digits or 4 octal ones. ~

tzs• 12 months ago

10-bit has sort of been used. The General Instrument CP1600 family of microprocessors used 16-bit words but all of the instruction opcodes only used 10 bits, with the remaining 6 bits reserved for future use.

GI made 10-bit ROMs so that you wouldn't waste 37.5% of your ROM space storing those 6 reserved bits for every opcode. Storing your instructions in 10-bit ROM instead of 16-bit ROM meant that if you needed to store 16-bit data in your ROM you would have to store it in two parts. They had a special instruction that would handle that.

The Mattel Intellivision used a CP1610 and used the 10-bit ROM.

The term Intellivision programmers used for a 10-bit quantity was "decle". Half a decle was a "nickel".

ajuc4• 12 months ago

5 bit nibbles could just be Baudot Code (A-Z + some control characters).

pratyahava7• 12 months ago

deleted

relevant_stats• 12 months ago

I really don't get why some people like to pollute conversations with LLMs answers. Particularly when they are as dumb as your example.

What's the point?

iosjunkie• 12 months ago

No! No, no, not 10! He said 9. Nobody's comin' up with 10. Who processing with 10 bits? What’s the extra bit for? You’re just wastin’ electrons.

ajuc4• 12 months ago

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.

titzer• 12 months ago

10 bit bytes would be awesome! Think of 20 bit microcontrollers and 40 bit workstations. 40 bits makes 5 byte words, that'd be rad. Also, CPUs could support "legacy" 32 bit integers and use a full 8 bits for tags, which are useful for implementing dynamic languages.

phpnode• 12 months ago

why stop there? 16-bit bytes would be so much cleaner

dboreham3• 12 months ago

UTF-16 enters the chat..

zamadatix5• 12 months ago

Because we have 8 bit bytes we are familiar with the famous or obvious cases multiples-of-8-bits ran out, and those cases sound a lot better with 12.5% extra bits. What's harder to see in this kind of thought experiment is what the famously obvious cases multiples-of-9-bits ran out would have been. The article starts to think about some of these towards the end, but it's hard as it's not immediately obvious how many others there might be (or, alternatively, why it'd be significantly different total number of issues than 8 bit bytes had). ChatGPT particularly isn't going to have a ton of training data about the problems with 9 bit multiples running out to hand feed you.

It also works in the reverse direction too. E.g. knowing networking headers don't even care about byte alignment for sub fields (e.g. a VID is 10 bits because it's packed with a few other fields in 2 bytes) I wouldn't be surprised if IPv4 would have ended up being 3 byte addresses = 27 bits, instead of 4*9=36, since they were more worried with small packet overheads than matching specific word sizes in certain CPUs.

marcosdumay• 12 months ago

Well, there should be half as many cases of multiples-of-9-bits ran out than for multiples-of-8-bits.

I don't think this is enough of a reason, though.

foxglacier• 12 months ago

If you're deciding between using 8 bits or 16 bits, you might pick 16 because 8 is too small. But making the same decision between 9 and 18 bits could lead to picking 9 because it's good enough at the time. So no I don't think there would be half as many cases. They'd be different cases.

oasisbob• 12 months ago

The IPv4 networking case is especially weird to think about because the early internet didn't use classless-addressing before CIDR.

Thinking about the number of bits in the address is only one of the design parameters. The partitioning between network masks and host space is another design decision. The decision to reserve class D and class E space yet another. More room for hosts is good. More networks in the routing table is not.

Okay, so if v4 addresses were composed of four 9-bit bytes instead of four 8-bit octets, how would the early classful networks shaken out? It doesn't do a lot of good if a class C network is still defined by the last byte.

JdeBP• 12 months ago

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.

Dylan168075• 12 months ago

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.

pavpanchekha13• 12 months ago

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.

deafpolygon• 12 months ago

I'm curious what would have happened with gaming.. would we have gotten the NES?

topspin• 12 months ago

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.

andai• 12 months ago

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.

windward2• 12 months ago

I didn't recognise the word 'dren'. Asked an LLM.

cdaringe• 12 months ago

There is certainly a well known bias or fallacy that describes this

pavpanchekha13• 12 months ago

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.

mrheosuper• 12 months ago

Nothing NAT can't solve /s.

cchance2• 12 months ago

why not 10 bit bytes and 40 bit addresses and nice 2 based metric based measures :)

Ekaros• 12 months ago

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.

p_l9• 12 months ago

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...

windward2• 12 months ago

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.

MangoToupe• 12 months ago

Maybe if we worked with 7-bit bytes folks would be more grateful.

xpe5• 12 months ago

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

folsom• 12 months ago

I don't know what if we ended up with a 27 bit address space?

As far as ISPs competing on speeds in the mid 90s, for some reason it feels like historical retrospectives are always about ten years off.

pavpanchekha13• 12 months ago

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.

jayd16• 12 months ago

I guess nibbles would be 3 bits and you'd 3 per byte?

monocasa3• 12 months ago

Ohh, and then we could write the digits in octal.

Interestingly, the N64 internally had 9 bit bytes, just accesses from the CPU ignored one of the bits. This wasn't a parity bit, but instead a true extra data bit that was used by the GPU.

ethan_smith• 12 months ago

The N64's Reality Display Processor actually used that 9th bit as a coverage mask for antialiasing, allowing per-pixel alpha blending without additional memory lookups.

monocasa3• 12 months ago

As well as extra bits in the Z buffer to give it a 15.3 fixed point format.

kazinator7• 12 months ago

36 bit addresses would be better than 32, but I like being able to store a 64 bit double or pointer or integer in a word using NaN tagging (subject to the limitation that only 48 bits of the pointer are significant).

consp2• 12 months ago

Funny thing is we sort-of got 36bit addressing mainstream with PAE in the 32bit x86 age.

kazinator7• 12 months ago

We sort of got 16 + 4 = 20 bit addressing in the 16 bit x86 age too.

Retr0id• 12 months ago

Aside from memory limits, one of the problems with 32-bit pointers is that ASLR is weakened as a security mitigation - there's simply fewer bits left to randomise. A 36-bit address space doesn't improve on this much.

64-bit pointers are pretty spacious and have "spare" bits for metadata (e.g. PAC, NaN-boxing). 72-bit pointers are even better I suppose, but their adoption would've come later.

AlotOfReading2• 12 months ago

ASLR has downsides as well. The address sanitizers have a shadow memory overhead that depends on the entropy in the pointer. If you have too much entropy, it becomes impossible for the runtime linker to map things correctly. Generally they'll just disable ASLR when they start, but it's one of the problems you'd have to solve to use them in production like ubsan even though that'd be extremely useful.

kazinator7• 12 months ago

Problem is, not only did we have decades of C code that unnecessarily assumed 8/16/32, this all-the-world-is-a-VAX view is now baked into newer languages.

C is good for portability to this kind of machine. You can have a 36 bit int (for instance), CHAR_BIT is defined as 9 and so on.

With a little bit of extra reasoning, you can make the code fit different machines sizes so that you use all the available bits.

pratyahava7• 12 months ago

was that assumption in C code really unnecessary? i suppose it made many things much easier.

kazinator7• 12 months ago

In my experience, highly portable C is cleaner and easier to understand and maintain than C which riddles abstract logic with dependencies on the specific parameters of the abstract machine.

Sometimes the latter is a win, but not if that is your default modus operandi.

Another issue is that machine-specific code that assumes compiler and machine characteristics often has outright undefined behavior, not making distinctions between "this type is guaranteed to be 32 bits" and "this type is guaranteed to wrap around to a negative value" or "if we shift this value 32 bits or more, we get zero so we are okay" and such.

There are programmers who are not stupid like this, but those are the ones who will tend to reach for portable coding.

0cf8612b2e1e• 12 months ago

Now a C++ proposal to define a byte as 8 bits

https://isocpp.org/files/papers/P3477R1.html

kazinator7• 12 months ago

I worked in C for a DSP chip where the smallest data type was 16 bits. It was less than a decade ago.

TruffleLabs• 12 months ago

PDP-8 has a 12-bit word size

bawolff2• 12 months ago

But in a world with 9-bit bytes IPv4 would have had 36-bit addresses, about 64 billion total.

Or we would have had 27 bit addresses and ran into problems sooner.

bigstrat20032• 12 months ago

That might've been better, actually. The author makes the mistake of "more time would've made this better", but we've had plenty of time to transition to IPv6. People simply don't because they are lazy and IPv4 works for them. More time wouldn't help that, any more than a procrastinating student benefits when the deadline for a paper gets extended.

But on the other hand, if we had run out sooner, perhaps IPv4 wouldn't be as entrenched and people would've been more willing to switch. Maybe not, of course, but it's at least a possibility.

dmitrygr4• 12 months ago

simply don't because they are lazy and IPv4 works for them

Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.

SchemaLoad• 12 months ago

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.

ay• 12 months ago

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

pavpanchekha13• 12 months ago

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.

bawolff2• 12 months ago

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.

SlowTao• 12 months ago

Can you imagine the argument for 8bit bytes if we still lived in the original 6bit world of the 1950s?

A big part of the move to 8bit systems was that it allowed expanded text systems with letter casing, punctuation and various ASCII stuff.

We could move to the world of Fortran 36bit if really needed and solve all these problems while introducing a problem called Fortran.

LegionMammal978• 12 months ago

There was already more than enough space for characters with 12-bit systems like the PDP-8. If anything, the convergence on 8-bit words just made it more efficient to use 7-bit codepages like ASCII.

consp2• 12 months ago

As the UTF encodings have shown you can put any encoding in any bitform if need be.

duskwuff2• 12 months ago

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.

falcor842• 12 months ago

We just need 3 valued electronics

percentcer• 12 months ago

on, off, and the other thing

skissane• 12 months ago

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

pif• 12 months ago

It already exists: True, False and FileNotFound.

If you don't believe me, just ask Paula Bean.

ForOldHack4• 12 months ago

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.

magicalhippo• 12 months ago

Technically e would be best IIRC, but hard to implement, so 3 is the closest.

AnotherGoodName• 12 months ago

Factorio logic applies as always - powers of 2 for trains belts etc. makes evenly splitting resources trivial.

lock1• 12 months ago

Unfortunately belt speed gain per tier is linear and 1:3 blue:yellow belt.

phkahler2• 12 months ago

Good points! I was going to say I think 12 bits would have been a nice choice, but yeah optimizing for circuits is kind of important.

ForOldHack4• 12 months ago

Brillant, that 36 bits would be three bytes.

"DEC's 36-bit computers were primarily the PDP-6 and PDP-10 families, including the DECSYSTEM-10 and DECSYSTEM-20. These machines were known for their use in university settings and for pioneering work in time-sharing operating systems. The PDP-10, in particular, was a popular choice for research and development, especially in the field of artificial intelligence. "

"Computers with 36-bit words included the MIT Lincoln Laboratory TX-2, the IBM 701/704/709/7090/7094, the UNIVAC 1103/1103A/1105 and 1100/2200 series, the General Electric GE-600/Honeywell 6000, the Digital Equipment Corporation PDP-6/PDP-10 (as used in the DECsystem-10/DECSYSTEM-20), and the Symbolics 3600 series.

Smaller machines like the PDP-1/PDP-9/PDP-15 used 18-bit words, so a double word was 36 bits.

Oh wait. Its already been done.

Taniwha2• 12 months ago

Not really - I worked on a DSP with 9-bit bytes in the 90's (largely because it was focused on MPEG decode for DVDs, new at the time) largely because memory was still very expensive and MPEG2 needed 9-bit frame difference calculations (most people do this as 16-bits these days but back then as I said memory was expensive and you could buy 9-bit parity RAM chips)

It had 512 72-bit registers and was very SIMD/VLIW, was probably the only machine ever with 81-bit instructions

chaboud• 12 months ago

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.

willis936• 12 months ago

Plato argued that 7! was the ideal number of citizens in a city because it was a highly factorable number. Being able to cut numbers up is an time-tested favorite. That's why there are 360 degrees.

gxs• 12 months ago

Or 60 minutes in an hour

1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, and 60

ljm• 12 months ago

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.

BobbyTables2• 12 months ago

Wonder why we don’t have 720 degrees… (6!)

rich_sasha3• 12 months ago

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.

almost• 12 months ago

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.

vbezhenar2• 12 months ago

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.

nyeah2• 12 months ago

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%...

mouse_• 12 months ago

Times have changed. Gnome people will yell at you for mentioning things as innocuous as pixel measurements. You'd probably be crucified for suggesting there's a hardware-correct way of handling address space.

fouc• 12 months ago

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.

somat• 12 months ago

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.

fc417fc8025• 12 months ago

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.

01HNNWZ0MV43FF• 12 months ago

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

pavpanchekha13• 12 months ago

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.

DrNosferatu• 12 months ago

- Why not 12 bits?

nicman23• 12 months ago

hehe a bit nicer

15155• 12 months ago

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.

cchance2• 12 months ago

I mean the post is silly, why not just say 10 bit bytes lol, shit then bits/bytes could be metric lol

Narishma3• 12 months ago

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.

chexum• 12 months ago

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..

smallstepforman• 12 months ago

The elephant in the room nobody talks about is silicon cost (wires, gates, multiplexirs, AND and OR gates etc). With a 4th lane, you may as well go straight to 16 bits to a byte.

pratyahava7• 12 months ago

This must be the real reason of using 8-bit. But then why did they make 9-bit machine instead of 16-bit?

AlotOfReading2• 12 months ago

The original meaning of byte was a variable number of bits to represent a character, joined into a larger word that reflected the machine's internal structure. The IBM STRETCH machines could change how many bits per character. This was originally only 1-6 bits [1] because they didn't see much need for 8 bit characters and it would have forced them to choose 64 bit words, when 60 bit words was faster and cheaper. A few months later they had a change of heart after considering how addressing interacted with memory paging [2] and added support for 8 bit bytes for futureproofing and 64 bit words, which became dominant with the 360.

[1] https://web.archive.org/web/20170404160423/http://archive.co...

[2] https://web.archive.org/web/20170404161611/http://archive.co...

xpe5• 12 months ago

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?

xpe5• 12 months ago

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?

alphazard2• 12 months ago

When you stop to think about it, it really doesn't make sense to have memory addresses map to 8-bit values, instead of bits directly. Storage, memory, and CPUs all deal with larger blocks of bits, which have names like "pages" and "sectors" and "words" depending on the context.

If accessing a bit is really accessing a larger block and throwing away most of it in every case, then the additional byte grouping isn't really helping much.

SpaceNoodled• 12 months ago

It makes sense for the address to map to a value the same width as the data bus.

A one-bit wide bus ... er, wire, now, I guess ... Could work just fine, but now we are extremely limited with the number of operations achievable, as well as the amount of addressable data: an eight-bit address can now only reference a maximum of 32 bytes of data, which is so small as to be effectively useless.

alphazard2• 12 months ago

If each memory address mapped to a CPU word sized value, that would make sense, and that is closer to the reality of instructions reading a word of memory at a time. Instead of using the CPU word size as the smallest addressable value, or the smallest possible value (a bit) as the smallest addressable value, we use a byte.

It's an arbitrary grouping, and worse, it's rarely useful to think in terms of it. If you are optimizing access patterns, then you are thinking in terms of CPU words, cache line sizes, memory pages, and disk sectors. None of those are bytes.

wmf2• 12 months ago

Byte addressing is really useful for string handling.

m463• 12 months ago

We have already solved this problem many times.

In clothing stores, numerical clothes sizes have steadily grown a little larger.

The same make and model car/suv/pickup have steadily grown larger in stance.

I think what is needed is to silently add 9-bit bytes, but don't tell anyone.

also: https://imgs.xkcd.com/comics/standards_2x.png

nottorp• 12 months ago

Of course, if that happens we'll get an article demanding 10-bit bytes.

Got to stop somewhere.

NelsonMinar• 12 months ago

This is ignoring the natural fact that we have 8 bit bytes because programmers have 8 fingers.

mkl• 12 months ago

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

alserio• 12 months ago

ISO reserves programmers thumbs to LGTM on pull requests

classichasclass• 12 months ago

No, we still have 10. Real programmers think in octal. ;)

childintime2• 12 months ago

Available. As they suck on their thumbs.

skort• 12 months ago

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.

js8• 12 months ago

I have thought for fun about a little RISC microcomputer with 6-bit bytes, and 4-byte words (12 MiB of addressable RAM). I think 6-bit bytes would have been great at a point in history, and in something crazy fun like Minecraft. (It's actually interesting question, if we were to design early microprocessors with today's knowledge of HW methods, things like RISC, caches or pipelining, what would we do differently?)

zokier• 12 months ago

Another interesting thought experiment would what if we went down to 6 bit bytes instead? Then the common values probably would be 24 and especially 48 bits (4 and 8 bytes), but 36 bit values might have appeared also in some places. In many ways 6 bit bytes would have had similar effect than 9 bit bytes; 18 and 36 bits would have been 3 and 6 bytes instead of 2 and 4 bytes. Notably with 6 bit bytes text encoding would have needed to be multibyte from the get-go, which might have been significant benefit (12 bit ASCII?)

wmf2• 12 months ago

Some early mainframes used 6-bit characters which is why they didn't have lowercase.

pavpanchekha13• 12 months ago

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.

HappyPanacea• 12 months ago

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.

pavpanchekha13• 12 months ago

Thanks

sedatk• 12 months ago

Our capability to mispredict wouldn't have been different. We would have still picked the wrong size, and got stuck with scaling problems.

labrador5• 12 months ago

At the end: "Thank you to GPT 4o and o4 for discussions, research, and drafting."

At first I thought that was a nice way to handle credit, but on further thought I wonder if this is necessary because the base line assumption is that everyone is using LLMs to help them write.

xandrius• 12 months ago

Yeah, I don't remember ever thanking the spellchecker anything in the past. Maybe we are kinder to technology nowadays that we even credit it?

Thank you to Android for mobile Internet connectivity, browsing, and typing.

labrador5• 12 months ago

A counter point is that googling "thank you linux" turns up a lot of hits. "thank you linux for opening my eyes to a bigger world" is a typical comment.

svachalek2• 12 months ago

As soon as that's my baseline assumption, I think I'm done with the internet. I can get LLM slop on my own.

labrador5• 12 months ago

I thought the article was well written. I'm assuming the author did most of the writing because it didn't sound like AI slop. I also assume he meant he uses AI to assist, not as the main driver.

PaulHoule2• 12 months ago

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.

xdennis• 12 months ago

This is what happens when you write articles with AI (the article specifically mentions ChatGPT).

The article says:

A number of 70s computing systems had nine-bit bytes, most prominently the PDP-10

This is false. If you ask ChatGPT "Was the PDP-10 a 9 bit computer?" it says "Yes, the PDP-10 used a 36-bit word size, and it treated characters as 9-bit bytes."

But if you ask any other LLM or look it up on Wikipedia, you see that:

Some aspects of the instruction set are unusual, most notably the byte instructions, which operate on bit fields of any size from 1 to 36 bits inclusive, according to the general definition of a byte as a contiguous sequence of a fixed number of bits.

-- 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.

vincent-manis• 12 months ago

Actually, the PDP-10 didn't have any byte size at all, it was a word-addressed machine. (An early attempt to implement C on this machine came a cropper because of this.) It did have a Load Byte and a Store Byte instruction, which allowed you to select the byte size. Common formats were Sixbit (self-explanatory), ASCII (5 7-bit bytes and an unused bit), and (more rarely, I think), 9-bit bytes.

My first machines were the IBM 7044 (36-bit word) and the PDP-8 (12-bit word), and I must admit to a certain nostalgia for that style of machine (as well as the fact that a 36-bit word gives you some extra floating-point precision), but as others have pointed out, there are good reasons for power-of-2 byte and word sizes.

jacquesm5• 12 months ago

You are correct. The Sperry-Univac 1100 series though did have 36 bit words and 9 bit bytes.

Someone• 12 months ago

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.

aidenn0• 12 months ago

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.

msla• 12 months ago

Multics never ran on PDP-10s, but on other 36-bit mainframes.

unused0• 12 months ago

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

nayuki• 12 months ago

Today, we all agree that "byte" means 8 bits. But half a century ago, this was not so clear and the different hardware manufacturers were battling it out with different sized bytes.

A reminder of that past history is that in Internet standards documents, the word "octet" is used to unambiguously refer to an 8-bit byte. Also, "octet" is the French word for byte, so a "gigaoctet (Go)" is a gigabyte (GB) in English.

(Now, if only we could pin down the sizes of C/C++'s char/short/int/long/long-long integer types...)

gnabgib• 12 months ago

An octet is unambiguously Latin for 8 of something; instruments, players, people, bytes, spider's legs, octopus' arms, molecules (see: octane).

Octad/octade was unambiguously about 8 bit bytes, but fell out of popular usage.

Tor33• 12 months ago

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)

Dwedit• 12 months ago

Many old 8-bit processors was basically 9-bit processors once you considered the carry flag.

apt-apt-apt-apt• 12 months ago

We may have been stuck with slower, more expensive machines for 40+ years while computers that couldn't fully use the higher limits wasted time and energy.

brudgers• 12 months ago

I'm writing this on a four-year-old Macbook Pro and it only has 16 GB of RAM. Server-class machines would still need to address more memory than that, but they're usually running specialized software or virtualizing; databases and hypervisors are already tricky code and segmentation wouldn't be the end of the world.

Because, I have a ten year old Dell laptop with 40GB of RAM, 16GB seems like an arbitrary limitation, an engineering compromise, or something like that.

I don’t see how it is a result of 8 bit bytes because 64bits has a lot of address space.

And because my laptop is running Windows 10 currently and ram Ubuntu before that, ordinary operating systems are sufficient.

—-

Also ECC RAM is 9 bits per byte.

kyralis• 12 months ago

"We've guessed wrong historically on data sizes, and if we had 9 bit bytes those guesses (if otherwise unchanged) would have been less wrong, so 9 bit bytes would be better!" is an extremely tenuous argument. Different decisions would have been made.

We need to be better at estimating require sizes, not trying to trick ourselves into accomplishing that by slipping in an extra bit to our bytes.

pavpanchekha13• 12 months ago

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.

Nevermark• 12 months ago

1 extra (literally) odd bit would require a lot of changes...

What if instead of using single bytes, we used "doublebytes"?

8-bit software continues to work, while new 16-bit "doublebyte" software gets 256x the value capacity, instead of a meager 2x.

Nobody will ever need more byte space than that!

Without requiring any changes to CPU/GPU, RAM, SSD, Ethernet, WiFi ...

Magic. :)

LarMachinarum• 12 months ago

while none of the arguments of the article came even close to being convincing or to balancing out the disadvantages of a non-power-of-two orientation, there actually is one totally different argument/domain where the 9 bit per byte thing would hold true, that is: ECC bits in consumer devices (as opposed to just on servers):

The fact that Intel managed to push their shitty market segmentation strategy of only even supporting ECC RAM on servers has rather nefarious and long-lasting consequences.

shmerl• 12 months ago

It's 2025 and Github—Github!—doesn't support IPv6

Yeah, I wonder why. It's not IPv6's problem though, it's definitely Github's.

Anyway, it's not a good example, since IPv6 is vastly wider than 9-bit variant of IPv4 would have been.

crazygringo• 12 months ago

It's an interesting observation that 2^16 = 65K is a number that isn't quite big enough for things it's mostly big enough for, like characters.

And that 2^32 = 4B is similarly awkwardly not quite big enough for global things related to numbers of people, or for second-based timestamps.

But a 9th bit isn't going to solve those things either. The real problem is that powers-of-two-of-powers-of-two, where we jump from 256 to 65K to 4B to 18QN (quintillion), are just not fine-grained enough for efficient usage of space.

It might be nice if we could also have 2^12=4K, 2^24=16M, and 2^48=281T as more supported integer bit lengths used for storage both in memory and on disk. But, is it really worth the effort? Maybe in databases? Obviously 16M colors has a long history, but that's another example where color banding in gradients makes it clear where that hasn't been quite enough either.

montag• 12 months ago

Nah…We would have attempted to squeeze even bigger things into 18- and 36-bit address spaces that would have been equally short-sighted. But this is a tragedy of successes :)

protocolture• 12 months ago

Yeah uh, moving ISP's from IPv4 to IPv6 has been a headache, moving backwards to IPv4-9BIT would fuck things even harder.

adrianmonk• 12 months ago

IPv4 would have had 36-bit addresses, about 64 billion total. That would still be enough right now, and even with continuing growth in India and Africa it would probably be enough for about a decade more. [ ... ] When exhaustion does set in, it would plausibly at a time where there's not a lot of growth left in penetration, population, or devices, and mild market mechanisms instead of NATs would be the solution.

I think it's actually better to run out of IPv4 addresses before the world is covered!

The later-adopting countries that can't get IPv4 addresses will just start with IPv6 from the beginning. This gives IPv6 more momentum. In big, expensive transitions, momentum is incredibly helpful because it eliminates that "is this transition even really happening?" collective self-doubt feeling. Individual members of the herd feel like the herd as a whole is moving, so they ought to move too.

It also means that funds available for initial deployment get spent on IPv6 infrastructure, not IPv4. If you try to transition after deployment, you've got a system that mostly works already and you need to cough up more money to change it. That's a hard sell in a lot of cases.

elcritch• 12 months ago

And nothing like FOMO of developing markets not being able to access a product to drive VPs and CEOs to care about ensuring IPv6 support works with their products.

pavpanchekha13• 12 months ago

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.

qwerty2000• 12 months ago

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.

mhandley• 12 months ago

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.

layer83• 12 months ago

It would also make Base64 a bit simpler (pun intended), at the cost of a little more overhead (50% instead of 33%).

hinkley3• 12 months ago

We likely wouldn’t use base64 at all in that case, but Base256. But also more of Europe would have fit in ASCII and Unicode would be a few years behind.

layer83• 12 months ago

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.

theultdev• 12 months ago

a little more overhead (50% instead of 33%)

a little?

layer83• 12 months ago

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.

cwmoore• 12 months ago

“It goes up to 1011!”

croemer2• 12 months ago

Though you still see RFCs use "octet"

Author seems to be unaware that octet is etymologically linked to 8.

eurleif• 12 months ago

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.

croemer2• 12 months ago

Ah indeed that's it, my misunderstanding!

miiiiiike• 12 months ago

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.

klik99• 12 months ago

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

xwolfi• 12 months ago

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 ?

joshu• 12 months ago

someone suggested 10-bit bytes. this will not be enough. 11-bit bytes should be plenty, though

sentrysapper• 12 months ago

I will think about this post every time I hear the expression "it won't change things one bit".

willvarfar• 12 months ago

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.

billseng• 12 months ago

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!

ryukoposting• 12 months ago

And if a foot were 13 inches, the numbers on your car's speedometer would be smaller. What is the point of this post?

djcapelis• 12 months ago

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.

calebh• 12 months ago

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.

frutiger• 12 months ago

Because of aligned reads any pointer size between 32-bit and 64-bit would end up using 64-bits anyway.

IshKebab2• 12 months ago

With 8-bit bytes, yes.

zozbot2344• 12 months ago

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.)

Tor33• 12 months ago

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.

IshKebab2• 12 months ago

https://en.wikipedia.org/wiki/X32_ABI

iainmerrick• 12 months ago

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.

piperswe• 12 months ago

The x32 ABI has 32-bit integers and pointers, while still running in long mode with full access to modern CPU features and instructions

0xDEAFBEAD• 12 months ago

9-bit bytes could easily make the common case ~12.5% slower everywhere. Most integers and chars fit in 8 bits no problem.

rich_sasha3• 12 months ago

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.

Duanemclemore• 12 months ago

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...

usr1106• 12 months ago

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?

necovek• 12 months ago

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.

mparramon• 12 months ago

They call it the programmer's dozen, 9 bits for a byte

gblargg• 12 months ago

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.

ajuc4• 12 months ago

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.

danlitt• 12 months ago

If bytes weren't 8 bits, why would IPv4 addresses contain 4 bytes? Shouldn't they contain 3, or 9?

1GZ0• 12 months ago

But why stop there? based on your arguments 10-bit bytes would be even more better.

childintime2• 12 months ago

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?

ordu• 12 months ago

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.

fnord77• 12 months ago

binary is far easier to do in electronics (on or off)

dpassens• 12 months ago

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.

npn• 12 months ago

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.

praptak• 12 months ago

Lisp implementors would love additional bits for tagging pointers more efficiently.

blurbleblurble• 12 months ago

If 9 bits sounds nice wait until you hear about 16 bits

mxfh• 12 months ago

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

account42• 12 months ago

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.

hn92726819• 12 months ago

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".

stackedinserter• 12 months ago

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

whoomp12342• 12 months ago

10-bt bytes seems a bit more logical as atleast its a recognizable base

entaloneralie• 12 months ago

Let's go ternary!

vrajspandya1• 12 months ago

Hacker News needs, “potentially slop” button.

infogulch• 12 months ago

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

We'd be better off with 9-bit bytes

Related Stories