Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We'd be better off with 9-bit bytes

pavpanchekha.com

Post reply on HN
Print view View original

281–290 of 359 posts

Re: We'd be better off with 9-bit bytes

#281

Post by msla »

aidenn0 wrote: post #181
PaulHoule wrote: post #56

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…

The PDP-10 didn't really have bytes; it had 36-bit words. AFAIK only Multics used 4 9-byte characters on the PDP-10s; I believe 5 7-bit ASCII characters fairly common later on in the PDP7/10 lifetime.

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

Re: We'd be better off with 9-bit bytes

#282

Post by card_zero »

ralfd wrote: post #278
AndrewOMartin wrote: post #269

Earlier quoted context omitted.

I just can't resist, pointing out that a "minute" is what you get when you split up an hour into 60 minute (i.e. the word pronounced my-newt) pieces, and a "second" is what you get if you break a minute into 60 pieces (i.e. you've performed the division a "second" time). By this logic, 0.016 (recurring) seconds should be a called a "third".

> (i.e. the word pronounced my-newt) "minute" comes from latin "pars minuta" and the "i" should be pronounced like in "minimum" > By this logic, 0.016 (recurring) seconds should be a called a "third". It should be "tertia". I found that in German and Polish it was used that way, but don't know about english: https://de.wikipedia.org/wiki/Tertie_(Winkel) https://pl.wikipedia.org/wiki/Tercja_k%C4%85towa

Should be the etymology of trice (but isn't). Odd omission from English.

Commodores had a 1/60 second "jiffy" for timing interrupts, that's all I could find.

Re: We'd be better off with 9-bit bytes

#283

Post by jama211 »

01HNNWZ0MV43FF wrote: post #232
somat wrote: post #143

Earlier quoted context omitted.

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 bit…

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

But in the n64’s case the GPU _could_ use the extra bit, so it’s fine. It was more trivia than anything about what the cpu could see.

Re: We'd be better off with 9-bit bytes

#285

Post by dspillett »

01HNNWZ0MV43FF wrote: post #232
somat wrote: post #143

Earlier quoted context omitted.

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 bit…

Yeah but if the CPU can't use it then it's kinda like saying your computer has 1,000 cores, except they're in the GPU and can't run general-purpose branchy code In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers. It doesn't address more than 4 GB of anything ever

> In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers.

Usually the size of general purpose registers is what defines the bitness of a CPU, not anything else (how much memory it can address, data bus width, etc).

For instance, the 80386SX was considered a 32-bit CPU because its primary register set is 32-bit, despite the fact it had a 24-bit external address bus and a 16-bit external data bus (32-bit requests are split into two 16-bit requests, this was done to allow the chip to be used on cheaper motherboards such as those initially designed with the 80286 in mind).

Note that this is for general purpose registers only: a chip may have 80-bit floating point registers in its FPU parts (supporting floating point with a 64-bit mantissa) but that doesn't make it an 80-bit chip. That was a bit more obvious when FPUs where external add-ons like the 8087 (the co-pro for the 16-bit 8086 family back in the day, which like current FPUs read & wrote IEEE754 standard 32- & 64- bit format floats and computed/held intermediate results in an extended 80-bit format).

Re: We'd be better off with 9-bit bytes

#286

Post by Taniwha »

chaboud wrote: post #207
Taniwha wrote: post #86

Earlier quoted context omitted.

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…

Mpact 2? If memory serves, I had a Creative Labs DXR2 that I almost immediately regretted. PDP-10 could do 9-bit (or 7, or 6) bytes into 36-bit words. It seems like something that would be fun for 1-2 days.

Yup, M2 had 81-bit instructions, M1 had 72-bit ones

Re: We'd be better off with 9-bit bytes

#287

Post by account42 »

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.

Re: We'd be better off with 9-bit bytes

#288

Post by 15155 »

pavpanchekha wrote: post #162
duskwuff wrote: post #17

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…

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 lik…

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

Re: We'd be better off with 9-bit bytes

#289

Post by zveyaeyv3sfye »

rich_sasha wrote: post #193
ljm wrote: post #144

Earlier quoted context omitted.

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.

1 mile = 1,000 [double] paces of 0.8m each = 1,600m 1m = 1e-10 times half-meridian from the North Pole to the equator, via Paris for a croissant, apparently. So kind of a coincindence... But a very neat one. Meanwhile, ratio of adjacent Fibonacci numbers converves to some expression involving sqrt(5) which is approx 1.6

converges

Re: We'd be better off with 9-bit bytes

#290

Post by andai »

JdeBP wrote: post #126
zamadatix wrote: post #4

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…

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…

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.
Post reply on HN