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

91–100 of 359 posts

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

#91

Post by AlotOfReading »

Retr0id wrote: post #10

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.

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.

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

#94

Post by oasisbob »

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…

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.

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

#96

Post by [deleted] »

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

[deleted]

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

#97

Post by codebje »

dmitrygr wrote: post #38
bigstrat2003 wrote: post #31

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.

If you "simply" added more bits to IPv4, you'd have a transition every bit (ahaha, ahem, sorry) as complex as the transition to IPv6 anyway, because IPv4+ would be a new protocol in exactly the same way as IPv6. A new DNS response record. Updates to routing protocols. New hardware. New software.

And no interoperability between the two without stateful network address translation.

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

#98

Post by willis936 »

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…

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.

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

#99

Post by duskwuff »

tyingq wrote: post #80
percentcer wrote: post #70

Earlier quoted context omitted.

on, off, and the other thing

hi-z is one choice. Though I don't know how well that does past a certain speed.

It works poorly at any speed. Hi-Z is an undriven signal, not a specific level, so voltage-driven logic like (C)MOS can't distinguish it from an input that's whatever that signal happens to be floating at. In current-driven logic like TTL or ECL, it's completely equivalent to a lack of current.
Post reply on HN