Live data from Hacker News

We'd be better off with 9-bit bytes

pavpanchekha.com

181–190 of 359 posts

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

#181

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.

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

#182

Earlier quoted context omitted.

Android was nearly my real life example a la "IPv6 doesn't mandate anything be different, some guy at Android just likes doing things that way more". I.e. nothing needs to be changed in the IPv6 standard, there's just some guy on the Android team who really likes SLAAC and thinks DHCPv6 is an abomination.

Okay, but that's not useful. In practice in the real world you cannot run a v6 network the way you would a v4 network even if you want to. That you theoretically could go implement changes to bring them into line doesn't really affect that.

[deleted]

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

#183
post #134

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.

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

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

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

#184

Earlier quoted context omitted.

Android was nearly my real life example a la "IPv6 doesn't mandate anything be different, some guy at Android just likes doing things that way more". I.e. nothing needs to be changed in the IPv6 standard, there's just some guy on the Android team who really likes SLAAC and thinks DHCPv6 is an abomination.

Okay, but that's not useful. In practice in the real world you cannot run a v6 network the way you would a v4 network even if you want to. That you theoretically could go implement changes to bring them into line doesn't really affect that.

I think we're saying the same thing except I'm splitting the blame from IPv6 (which was very much about adding more bits) and placing it on the unrelated hobby horses people like whats-his-name on Android ride in on. Intentionally not supporting DHCP in the new protocol had nothing to do with the design of IPv6, it's just something they prefer.

To put it from another perspective: If the situation was reversed would you be blaming IPv4 and saying IPv4 should have been designed differently or would you just be asking why this guy from Android doesn't want to add DHCPv4 when DHCPv6 is supported? In both situations it's not IPv4/IPv6 to blame for the inconvenience, it's the guy taking advantage of the transition between protocols to do something stupid at the same time. No amount of changing the definition of IP is going to make them like DHCP, they'll always push some SLAAC-like address assignment onto users. The only reason they didn't for IPv4 was they came in after it was already the way instead of before networks were deployed and they could force it.

It's often very difficult to use IPv6 in practice, but not because IPv6 made it that way.

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

#185

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.

[flagged]

What do you think they missed? What they said seems accurate: You're putting a lot of faith in ChatGPT that doesn't seem warranted.

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

#186

Earlier quoted context omitted.

We just need 3 valued electronics

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

There was a very good reasons for it, indigenous designs were obsolete by the time they left the drawing boards and countless design bureaus cost stupid amounts of money while producing dozens of incompatible computers. By the time they decided to adopt ES EVM they lagged by some 5 years and continued to lag further behind.

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

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

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

#188

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…

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.

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

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

#189

Earlier quoted context omitted.

Okay, but that's not useful. In practice in the real world you cannot run a v6 network the way you would a v4 network even if you want to. That you theoretically could go implement changes to bring them into line doesn't really affect that.

I think we're saying the same thing except I'm splitting the blame from IPv6 (which was very much about adding more bits) and placing it on the unrelated hobby horses people like whats-his-name on Android ride in on. Intentionally not supporting DHCP in the new protocol had nothing to do with the design of IPv6, it's just something they prefer. To put it from another perspective: If the situation was reversed would y…

Oh, yes, we do (mostly) agree then. Thanks for clarifying:)

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

#190

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…

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.

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

Post reply on HN