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

221–230 of 359 posts

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

#221

Post by Ekaros »

pavpanchekha wrote: post #165
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…

Author here. Actually 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 internet infrastructure that holds back transiti…

Might have ended up with 27-bit. If you do not really expect personal computer usage and just want to essentially make some proof of concept of interoperability which you will later upgrade or replace.

Maybe there would have been push to change at some point as there would have been real limits in place.

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

#222

Post by nicman23 »

pavpanchekha wrote: post #162
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…

Author here. It's true that you'd need one more bit to represent a bit position in a word, like for shifts, but we're already vastly over-provisioned; even in 64-bit registers we're only using six of eight bits. (Plus, in a lot of places we'd have that extra bit around!) Some hardware circuits are a bit nicer with power-of-two sizes but I don't think it's a huge difference, and hardware has to include weird stuff lik…

hehe a bit nicer

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

#223

Post by Someone »

jacquesm wrote: post #106
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…

You are correct. The Sperry-Univac 1100 series though did have 36 bit words and 9 bit bytes.

IIRC, its instruction set supported words (36 bits), half words (18 bits), third words (12 bits), quad words (9 bits), and sixth words (6 bits).

For characters, 6 bits also was used at times, for example in its disk format. There, a severely limited character set wasn’t problematic.

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

#224

Post by adastra22 »

DrNosferatu wrote: post #216
pavpanchekha wrote: post #162

Earlier quoted context omitted.

Author here. It's true that you'd need one more bit to represent a bit position in a word, like for shifts, but we're already vastly over-provisioned; even in 64-bit registers we're only using six of eight bits. (Plus, in a lot of places we'd have that extra bit around!) Some hardware circuits are a bit nicer with power-of-two sizes but I don't think it's a huge difference, and hardware has to include weird stuff lik…

- Why not 12 bits?

Why not 10? 1 byte ~= 1k values. Nice easy conversions.

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

#225

Post by zozbot234 »

kazinator wrote: post #141
pratyahava wrote: post #85

Earlier quoted context omitted.

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

You'd define architecture-specific typedefs to deal with these cases in a portable way. The C standard already has types like int_fast8_t that are similar in principle.

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

#226

Post by wvenable »

dboreham wrote: post #213
wvenable wrote: post #156

Earlier quoted context omitted.

There was a time, however, where CPUs operated almost exclusively on on 8bit bytes (and had 8bit data buses). Everything else is merely the consequence of that.

Quick note that this isn't true. 8-bit CPUs are newer than 36-bit CPUs, and 8-bit bytes were established long before 8-bit CPUs came on the scene. Prior to the mid-70s most machines were word-addressed. The adoption of byte addressing (the subject of the grandparent) gained traction after C and similar languages became popular. C was developed on the pdp-11 which supported byte addressing and it provided a compatible…

The comment was about why CPUs still use byte addressing even today. And it's my belief that's due to incomparably wide proliferation of 8bit computers.

Even CPUs that were 32bit with a 16bit data bus, like the 68000 series, required the ability to read and write single bytes to support the wide range of 8bit I/O chips including UARTs, timers, floppy-disk controllers, video controllers that were common at the time. The 8bit bus was king for a long time.

The evolution of Intel CPUs started with 4-bits

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

#227

Post by nxobject »

jojobas wrote: post #186
skissane wrote: post #78

Earlier quoted context omitted.

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.

Conversely, the Soviet Union took the PDP-11 ISA to its limits... including home computers with framebuffers and programmable calculators.

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

#229

Post by jalk »

rich_sasha wrote: post #190
willis936 wrote: post #98

Earlier quoted context omitted.

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.

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

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

#230

Post by zozbot234 »

calebh wrote: post #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 wit…

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

This is a very real issue (not just on the Windows platform, either) but well-coded software can recover much of that space by using arena allocation and storing indexes instead of general pointers. It would also be nice if we could easily restrict the system allocator to staying within some arbitrary fraction of the program's virtual address space - then we could simply go back to 4-byte general pointers (provided that all library code was updated in due course to support this too) and not even need to mess with arenas.

(We need this anyway to support programs that assume a 48-bit virtual address space on newer systems with 56-bit virtual addresses. Might as well deal with the 32-bit case too.)

Post reply on HN