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

331–340 of 359 posts

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

#331

Post by pavpanchekha »

codebje wrote: post #210
pavpanchekha wrote: post #168

Earlier quoted context omitted.

Author here. The point is that with 9-bit bytes we'd have designed IPv4 to have 36-bit addresses from the beginning. There wouldn't have been a transition.

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.

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

#332

Post by pavpanchekha »

bawolff wrote: post #231
pavpanchekha wrote: post #167

Earlier quoted context omitted.

Author here. I kind of doubt it. Copied from a comment earlier: I doubt we'd have picked 27-bit addresses. That's about 134M addresses; that's less than the US population (it's about the number of households today?) and Europe was also relevant when IPv4 was being designed. In any case, if we had chosen 27-bit addresses, we'd have hit exhaustion just a bit before the big telecom boom that built out most of the intern…

IPv4 was designed in 1981. The idea of every household in america having a computer in 1981 probably would have sounded insane. According to google there was only 213 hosts on the internet in 1981.

Your argument can't be so strong as to imply that IPv4 should actually have used 24-bit addresses, though.

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

#333

Post by raron »

icedchai wrote: post #164
bigstrat2003 wrote: post #72

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.

It's definitely more of an education issue. I still run into "IT" people that instinctively disable IPv6 no matter what. How do we fix this? The sad thing is IPv6 is actually easier in many respects: subnetting is simpler, no NAT hackery, SLAAC...

> I still run into "IT" people that instinctively disable IPv6 no matter what. How do we fix this?

- force ISPs to follow RIPE guidance on addressing (static prefix, at least /56 for every site, DHCPv6-PD)

- force the manufacturers of low-end routers (e.g. provided by ISPs) to have good IPv6 support (good firewalling, DHCPv6-PD, mDNS, PCP/UPNP, advertise static ULA prefix to have working local network even if internet connection is cut)

- force Android team to support DHCPv6

- force browsers to support full IPv6 addresses in URLs / URIs (link local addresses, scope id)

- force avahi / mDNS to support IPv6 scope id - make operating system manufacturers to have a better unified socket API which can resolve any type of address (IPv4, IPv6, DNS, mDNS, etc. maybe even URLs directly) and deprecate all other API

- make software developers to use this new API and don't try to parse IP addresses or URLs themselves

- have a good solution for multi-homing / WAN failover (without BGP and PI address space)

- have a good solution for mobile / roaming devices (phones, notebooks)

and maybe we could make IPv6 stable and universally working

(Waste a /40 for every company, get low on available prefixes and start over designing IPv8 to have 256 bit addresses with 184 bit host part...)

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

#334

Post by p_l »

ddingus wrote: post #329
p_l wrote: post #296

Earlier quoted context omitted.

Motorola 68k is a curious case because it originally was supposed to be a 16bit cpu, not 32bit, and the 24bit addressing that ignored upper 8 bits didn't help the perception. Ultimately, 68k being "16bit" is a marketing thing from home computers that upgraded from 8bit 6502 and the like to m68k but didn't use it fully.

Well, the 6809 was basically the same in these respects. Internal registers are 16 bit, with the accumulator (A) being provisioned as two 8 bit registers (A, B) as needed. Index X, Y, Stack, User Stack, PC, are all 16 bit registers. The Hitachi 6309, adds to that with up to 32 bit register sizes in specific cases. In any case, the ALU and data transfers are 8 bits and I am not sure I ever saw the 6809 referenced as a…

I'd say that it's a somewhat extended 8bit device because it's still 8bit focused architecture (6800) with extensions towards better handling of 16bit values and certain common parts involved including the zero/direct page are also effectively an increase in flexibility for 8bit code not so much move to 16bit.

That said, "16bit curious" is a great term :D

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

#335

Post by p_l »

dspillett wrote: post #328
p_l wrote: post #296

Earlier quoted context omitted.

Motorola 68k is a curious case because it originally was supposed to be a 16bit cpu, not 32bit, and the 24bit addressing that ignored upper 8 bits didn't help the perception. Ultimately, 68k being "16bit" is a marketing thing from home computers that upgraded from 8bit 6502 and the like to m68k but didn't use it fully.

That is an odd case. I'd still call it a 32-bit CPU as it had 32-bit registers and instructions (and not just a few special case 32-bit instructions IIRC). Like the 386SX it had a 16-bit external data bus, but some of its internal data routes were 16-bit also (where the 386SX had the full 32-bit core of a 386, later renamed 386DX, with the changes needed to change the external data bus) as were some of its ALUs hence…

In a way, the fact that you have home computer market calling it 16bit, while at the same time you have workstation systems that plainly talk about 32bit ISA, shows how much of marketing issue it is :)

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

#336

Post by dspillett »

ddingus wrote: post #330
dspillett wrote: post #328

Earlier quoted context omitted.

That is an odd case. I'd still call it a 32-bit CPU as it had 32-bit registers and instructions (and not just a few special case 32-bit instructions IIRC). Like the 386SX it had a 16-bit external data bus, but some of its internal data routes were 16-bit also (where the 386SX had the full 32-bit core of a 386, later renamed 386DX, with the changes needed to change the external data bus) as were some of its ALUs hence…

Would you call the 6809 a 16 bit device?

I'm not aware of that one off the top of my head. If it naturally operated over 16-bit values internally (i.e. it had 16-bit registers and a primarily 16-bit¹ instruction set), at least as fast as it could work with smaller units, then probably yes.

----

[1] So not a mostly 8-bit architecture with 16-bit add-ons. The 8086 had a few instructions that could touch 32 bits, multiply being able to give a 32-bit output from two 16-bit inputs for instance (though the output was always to a particular pair of its registers), but a few special cases like that doesn't count so it is definitely 16-bit.

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

#337

Post by PaulHoule »

p_l wrote: post #301
leni536 wrote: post #263

Earlier quoted context omitted.

> It did have a Load Byte and a Store Byte instruction, which allowed you to select the byte size. Were these instructions atomic regarding interrupts? If not, then these look like shorthands for masking/shifting bit-fields out of words, leaving the word as the smallest atomically addressable unit.

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 increment the pointer which a real system could satisfy out of the cache except when it can’t.

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

#338

Post by Dylan16807 »

p_l wrote: post #299
Dylan16807 wrote: post #142

Earlier quoted context omitted.

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

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?

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

#339

Post by fc417fc802 »

phkahler wrote: post #324
fc417fc802 wrote: post #204

Earlier quoted context omitted.

Personally I think 12/48/96 would be more practical than the current 8/32/64. 32 bits is almost trivially easy to overflow whereas 48 bits is almost always enough when working with integers. And 64 bits is often insufficient or at least uncomfortably tight when packing bits together. Whereas by the time you've blown past 96 you should really just bust out the arrays and eat any overhead. Similarly I feel that 24 bits…

12 bit color would have been great. In the old days 4 bits for each of RGB, or even packing 2 pixels per byte. Today 12 bit per channel would be awesome, although high end cameras seem to be at 14 (which doesn't fit bytes well either). Instruction sets - 12 bits for small chips and 24 for large ones. RISC-V instructions encode better in 24bits if you use immediate data after the opcode instead of inside it. Physical…

Yeah it would be much more practical for color. 12 bit rgb4, 24 bit rgb8 or rgba6, and 48 bit rgb16 or rgba12 would all have proper alignment. The obvious rgb12 would obviate the need for the unholy mess of asymmetric 32 bit packed rgb formats we "enjoy" today.

Physical memory - Intel added support for 57 bits (up from 48 bits) in 2019, and AMD in 2022. 48 bit pointers obviously address the vast majority of needs. 96 bit pointers would make the developers of GC'd languages and VMs very happy (lots of tag bits).

For floats presumably you'd match the native sizes to maintain alignment. An f48 with a 10 bit exponent and an f96 with a 15 or 17 bit exponent. I doubt the former has any downsides relative to an f32 and the latter we've already had the equivalent of since forever in the form of 80 bit extended precision floats with a 16 bit exponent.

Amusingly I'm just now realizing that the Intel 80 bit representation has a wider exponent than IEEE binary128.

I guess high end hardware that supports f128 would either be f144 or f192. The latter maintains alignment so presumably that would win out. Anyway pretty much no one supports f128 in hardware to begin with.

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

#340

Post by JoshTriplett »

zamadatix wrote: post #120
JoshTriplett wrote: post #65

Earlier quoted context omitted.

> They're almost always deployed though because people end up liking the ideas. Or they're deployed because it's difficult to use IPv6 without them, even if you want to. 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 seco…

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

Post reply on HN