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

81–90 of 359 posts

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

#81

Post by LarMachinarum »

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.

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

#82

Post by AnotherGoodName »

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…

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

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

#83

Post by shmerl »

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

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

#84

Post by phkahler »

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…

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.

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

#85

Post by pratyahava »

kazinator wrote: post #67
pratyahava wrote: post #28

Earlier quoted context omitted.

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

In my experience, highly portable C is cleaner and easier to understand and maintain than C which riddles abstract logic with dependencies on the specific parameters of the abstract machine. Sometimes the latter is a win, but not if that is your default modus operandi. Another issue is that machine-specific code that assumes compiler and machine characteristics often has outright undefined behavior, not making distin…

yep, i remember when i tried coding for some atmega, i was wondering "how big are int and uint?" and wanted the types names to always include the size like uint8. but also there is char type, which should become char8 which looks even more crazy.

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

#86

Post by Taniwha »

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…

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

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

#87

Post by yjftsjthsd-h »

zamadatix wrote: post #43
dmitrygr wrote: post #38

Earlier quoted context omitted.

> 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, NAT6…

I'm not convinced that's true in practice. I would like to have an IPv6 network that I can connect Android devices to and on which I can connect to the devices by their host name. Android refuses to support DHCPv6, telling the local DNS server about SLAAC addresses involves awful and unreliable hacks, mDNS requires extra daemons and resolver configuration. I looked at just copying my v4 stack to v6; it doesn't appear possible.

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

#88

Post by xdennis »

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…

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.

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

#89

Post by crazygringo »

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.

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

#90

Post by pif »

falcor84 wrote: post #68
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…

We just need 3 valued electronics

It already exists: True, False and FileNotFound.

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

Post reply on HN