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

341–350 of 359 posts

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

#341

Post by Dagger2 »

JoshTriplett wrote: post #340
zamadatix wrote: post #120

Earlier quoted context omitted.

Side note: I'm not sure why folks downvoted you. Even if they disagree it seems like an honest question. > For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configurati…

That's really helpful, thank you; I'll give that a try the next time I'm attempting to make this work. (I'm doing this using direct netlink calls from my init; this is all about booting as fast as possible. The IPv6 address information is coming from instance metadata.)

You probably want to add the "optimistic" or "nodad" flags when adding the address, or you'll need to wait for DAD to finish.

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

#342

Post by pdpi »

xpe wrote: post #137
pdpi wrote: post #36

Earlier quoted context omitted.

The moment you feel the need to skip letters due to propensity for errors should also be the moment you realise you're doing something wrong, though. It's kind of fine if you want a case insensitive encoding scheme, but it's kind of nasty for human-first purposes (e.g. in source code).

> The moment you feel the need to skip letters due to propensity for errors should also be the moment you realise you're doing something wrong, though. When you think end-to-end for a whole system and do a cost-benefit analysis and find that skipping some letters helps, why wouldn't you do it? But I'm guessing you have thought of this? Are you making a different argument? Does it survive contact with system-level thi…

You misunderstood me.

I started off by saying that 0-9a-v digits was "a bit extreme", which was a pretty blatant euphemism — I think that's a terrible idea.

Visually ambiguous symbols are a well-known problem, and choosing your alphabet carefully to avoid ambiguity is a tried and true way to make that sort of thing less terrible. My point was, rather, that the moment you suggest changing the alphabet you're using to avoid ambiguity should also be the moment you wonder whether using such a large number base is a good idea to begin with.

In the context of the original discussion around using larger bytes, the fact that we're even having a discussion about skipping ambiguous symbols is an argument against using 10-bit bytes. The ergonomics or actually writing the damned things is just plain poor. Forget skipping o, O, l and I, 5 bit nibbles are just a bad idea no matter what symbols you use, and this is a good enough reason to prefer either 9-bit bytes (three octal digits) or 12-bit bytes (four octal or three hex digits).

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

#343

Post by JoshTriplett »

Dagger2 wrote: post #341
JoshTriplett wrote: post #340

Earlier quoted context omitted.

That's really helpful, thank you; I'll give that a try the next time I'm attempting to make this work. (I'm doing this using direct netlink calls from my init; this is all about booting as fast as possible. The IPv6 address information is coming from instance metadata.)

You probably want to add the "optimistic" or "nodad" flags when adding the address, or you'll need to wait for DAD to finish.

I'd figured that specific detail out already, though it was hard-won knowledge. But there's a lot more where that came from before getting to the point of bringing up IPv6 and sending packets without dealing with slow RA and various other slow processes of waiting for data from the network, for instance.

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

#344

Post by p_l »

Dylan16807 wrote: post #338
p_l wrote: post #299

Earlier quoted context omitted.

You don't want to switch code pages while processing the data unless you add extra fields to indicate code page, ISO 2022 style (or in fact old baudot shifts style)

Wouldn't the government department use the same code page at all times?

In EBCDIC world, not exactly, but all the place names being in one codepage is literally a return to why the accented names disappeared :)

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

#345

Post by p_l »

PaulHoule wrote: post #337
p_l wrote: post #301

Earlier quoted context omitted.

They are atomic, indeed. The underlying implementation might have used masking and shifting, especially in bit-slice implementations like KS-10, but as far as operation of the computer was concerned they were atomic.

It becomes problematic for multiprocessor systems but you could probably build a communications fabric and memory model that works. My fantasy CPU lets you write to the (say) 15 bits starting at the 43rd but of a 48 bit word which a real CPU would have to do a lot of work to implement but with the right kind of cache it is probably not so bad, it also has an instruction to read a UTF-8 character at a deep pointer and…

For PDP-10, because it operated only on word values, you can easily assume that every bus and memory operation passes a full 36 bit word every time.

In fact, recent-ish x86 CPUs have similar instructions, and as of Zen4 they are fast not just on Intel but also on AMD (previously they were microcoded as a bunch of shifts AFAIK with pretty lousy latency)

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

#346

Post by kps »

handsclean wrote: post #256
jalk wrote: post #229

Earlier quoted context omitted.

I believe the 360 degrees is attributed to Babylonians, who were using the Sumerian base 60 number system (6*60=360)

To elaborate a little, an advantage of this is there are many numbers it’s evenly divisible by. 60: 2, 3, 4, 5, 6, 10, 12, 15, 20, 30 100: 2, 4, 5, 10, 20, 25, 50 360: 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 18, 20, 24, 30, 36, 40, 45, 60, 72, 90, 120, 180

60 and 360 are superior highly composite numbers¹.

¹ https://mathworld.wolfram.com/SuperiorHighlyCompositeNumber....

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

#347

Post by codebje »

pavpanchekha wrote: post #331
codebje wrote: post #210

Earlier quoted context omitted.

The post I replied to was speculating on IPv4's life being extended by "simply making the numbers bigger" rather than having more bits per byte, but nevertheless... there still would've been a transition, delayed by at most a few years. Exhaustion was raised for 32-bit IPv4 in the very early 90s, when we had a few million active Internet users. Allocations were very sparsely used and growth in Internet usage was expo…

Great reply, much appreciated. I searched a bit for a number like ~70B and didn't find one. Perhaps 36 bits wouldn't have actually worked. I do think we'd have wasted more Class As, but that's where the "minor market mechanisms" would have happened—most of the class As did get sold and would in this universe too. Again, if total internet-connected devices is now 70B that wouldn't help, you'd still need NATs.

It's extremely hard to get an accurate count of connected devices, so we're all just estimating. There's lots of sources giving rough values for things like smartphones or IoT devices, there's a reasonably common estimate of 5.6 billion connected Internet users, but it's largely guesswork for connected devices per user.

It's improbable that I'm off by an order of magnitude: 7 billion is far too low (we have 7.5 billion smartphones in the world!) and 700 billion is far too high; how low an estimate could we make without being unreasonably optimistic? 40b seems quite low to me - 7.5b smartphones, 5.6b connected users, 20b IoT devices, and commercial use of IPs - but if we took that value we'd be sitting at saturation for 36 bits of address space (60% utilisation is pretty darn good!) and the next decade would kind of suck.

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

#348

Post by unused0 »

aidenn0 wrote: post #181
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…

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.

Multics ran on Honeywell 6180 and DPS8/M machines. They had 36 bit words like the PDP-10. They also had instructions that would operate o in 6 or 9 bit characters in the word

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

#349

Post by Dylan16807 »

p_l wrote: post #344
Dylan16807 wrote: post #338

Earlier quoted context omitted.

Wouldn't the government department use the same code page at all times?

In EBCDIC world, not exactly, but all the place names being in one codepage is literally a return to why the accented names disappeared :)

I need you to explain your argument better.

If you were saying they lost accents outside the main 50 or whatever, I'd understand why 8 bits were a problem. But you're saying they lost accents as a general rule, right? Why did they lose accents that were right there on the US code pages? Why would that reason not extend to a 9 bit semi-universal EBCDIC?

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

#350

Post by p_l »

Dylan16807 wrote: post #349
p_l wrote: post #344

Earlier quoted context omitted.

In EBCDIC world, not exactly, but all the place names being in one codepage is literally a return to why the accented names disappeared :)

I need you to explain your argument better. If you were saying they lost accents outside the main 50 or whatever, I'd understand why 8 bits were a problem. But you're saying they lost accents as a general rule, right? Why did they lose accents that were right there on the US code pages? Why would that reason not extend to a 9 bit semi-universal EBCDIC?

I read the original mention as trying to claim that it could have been solved by allowance for multiple codepages.

But for processing data in one common database, especially back then, you wanted to keep to single variation - main reason for using a different codepage if you didn't work in language other than english was to use APL (later, special variant of US codepage was added to support writing C, which for hysterical raisins wasn't exactly nice to work with in US default EBCDIC codepage).

So there would not be an allowance for multiple codepages if only because codepage identifier could cut into 72 characters left on punched card after including sort numbers

Post reply on HN