Live data from Hacker News

We'd be better off with 9-bit bytes

pavpanchekha.com

141–150 of 359 posts

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

#141

Earlier quoted context omitted.

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.

Would you want the main function to be:

  int32_t main(int32_t argc, char **argv)?
How about struct tm?

  struct tm {$
    int32_t tm_sec;    /* Seconds (0-60) */$
    int32_t tm_min;    /* Minutes (0-59) */$
    int32_t tm_hour;   /* Hours (0-23) */$
    int32_t tm_mday;   /* Day of the month (1-31) */$
    int32_t tm_mon;    /* Month (0-11) */$
    int32_t tm_year;   /* Year - 1900 */$
    int32_t tm_wday;   /* Day of the week (0-6, Sunday = 0) */$
    int32_t tm_yday;   /* Day in the year (0-365, 1 Jan = 0) */$
    int32_t tm_isdst;  /* Daylight saving time */$
  };
What for? Or do we "shrink wrap" every field to the smallest type? "uint8_t tm_hour"?

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

#142
post #126

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…

> The knock-on effect of EBCDIC having room for accented characters would have been the U.S.A. not changing a lot of placenames when the federal government made the GNIS in the 1970s and 1980s, for example.

I don't know about that, it had room for lots of accented characters with code pages. If that went unused, it probably would have also gone unused in the 9 bit version.

> Actual intelligence is needed for this sort of science fiction alternative history construction.

Why? We're basically making a trivia quiz, that benefits memorization far more than intelligence. And you actively don't want to get into the weeds of chaos-theory consequences or you forget the article you're writing.

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

#143

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…

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 bits green 3 bits triangle coverage it then uses this coverage information to calculate a primitive but fast antialiasing. so SGI went with two 9-bit bytes for each pixel and magic in the RDP(remember it's also the memory controller) so the cpu sees the 8-bit bytes it expects.

Memory on N64 is very weird it is basicly the same idea as PCIE but for the main memory. PCI big fat bus that is hard to speed up. PCIE small narrow super fast bus. So the cpu was clocked at 93 MHz but the memory was a 9-bit bus clocked at 250 MHz. They were hoping this super fast narrow memory would be enough for everyone but having the graphics card also be the memory controller proved to make the graphics very sensitive to memory load. to the point that the main thing that helps a n64 game get higher frame rate is to have the cpu do as few memory lookups as possible. which in practical terms means having it idle as much as possible. This has a strange side effect that while a common optimizing operation for most architectures is to trade calculation for memory(unroll loops, lookup tables...) on the N64 it can be the opposite. If you can make your code do more calculation with less memory you can utilize the cpu better because it is mostly sitting idle to give the RDP most of the memory bandwidth.

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

#144

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.

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.

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

#145

Earlier quoted context omitted.

I've run IPv6 on both corporate and home networks. Whether or not the additions were merited, they are not a formidable challenge for any reasonably-skilled admin. So no, I don't think that the reason you gave suffices as an excuse for why so many still refuse to deploy IPv6.

I'll assume you are speaking in good faith, so i'll reply so as well: I do not want to be a "reasonably-skilled admin". Not my job nor desire. I want DHCP to work and NAT to exist which acts as a de-facto firewall and hides my internal network config from the outside world. All with zero or fewer clicks in my home router's config. With IPv4 this works. With IPv6 it does not. Simple choice for me then: find the IPv6 c…

That's the fault of whoever designed the router, not IPv6.

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

#147

Earlier quoted context omitted.

As soon as that's my baseline assumption, I think I'm done with the internet. I can get LLM slop on my own.

I thought the article was well written. I'm assuming the author did most of the writing because it didn't sound like AI slop. I also assume he meant he uses AI to assist, not as the main driver.

Author here, in fact all the words you read I wrote, LLMs are not very good at writing.

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

#150

> Though you still see RFCs use "octet" Author seems to be unaware that octet is etymologically linked to 8.

I understand the author's point to be that, if RFC writers understood "byte" to imply eight bits, they wouldn't go out of their way to use the word "octet" instead when referring to eight bits.

Ah indeed that's it, my misunderstanding!
Post reply on HN