Live data from Hacker News

We'd be better off with 9-bit bytes

pavpanchekha.com

41–50 of 359 posts

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

#41
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?)

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

#42
post #8

Ohh, and then we could write the digits in octal. Interestingly, the N64 internally had 9 bit bytes, just accesses from the CPU ignored one of the bits. This wasn't a parity bit, but instead a true extra data bit that was used by the GPU.

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

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

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

#43

Earlier quoted context omitted.

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…

> simply don't because they are lazy and IPv4 works for them Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.

Most of the "unwanted" things in IPv6 aren't actually required by IPv6. Temporary addresses, most of the feature complexity in NDP, SLAAC, link-local addresses for anything but the underlying stuff that happens automatically, "no NAT, you must use PD", probably more I'm forgetting. Another large portion is things related to trying to be dual stack like concurrent resolutions/requests, various forms of tunneling, NAT64, and others.

They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.

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

#44
post #18
post #3

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

One of the nice features of 8 bit bytes is being able to break them into two hex nibbles. 9 bits breaks that, though you could do three octal digits instead I suppose. 10 bit bytes would give us 5-bit nibbles. That would be 0-9a-v digits, which seems a bit extreme.

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

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

#45

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

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

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

#46
post #44
post #18

Earlier quoted context omitted.

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.

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

Alternate world where the pdp-8 evolved into our modern processors.

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

#48

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

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

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

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

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

#50

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…

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.

Post reply on HN