251–260 of 359 posts
Yeah, but hear me out - 10-bit bytes!
One of the nice features of 8 bit bytes is being able to break them into two hex nibbles. 9 bits breaks that, though you could do three octal digits instead I suppose. 10 bit bytes would give us 5-bit nibbles. That would be 0-9a-v digits, which seems a bit extreme.
Yeah, but hear me out - 10-bit bytes!
No! No, no, not 10! He said 9. Nobody's comin' up with 10. Who processing with 10 bits? What’s the extra bit for? You’re just wastin’ electrons.
Or addressing 1 TB of memory with 4 bytes, and each byte is the next unit: 1st byte is GB, 2nd byte is MB, 3rd byte is KB, 4th byte is just bytes.
Earlier quoted context omitted.
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…
Author here. Really great comment; I've linked it from the OP. (Could do without the insults!) Most of the changes you point out sound... good? Maybe having fewer arbitrary limits would have sapped a few historically significant coders of their rage against the machine, but maybe it would have pulled in a few more people by being less annoying in general. On colors, I did mention that in the post but losing an alpha…
A byte in computer is the smallest addressable memory location and this location at that time contained a character. The way characters are encoded is called code. Early computers used 5-bits, which was not enough for alphabetics and numerals, 6 bits was not enough to encode numbers and lower and upper case characters, which eventually lead to ASCII.
ASCII was also designed(!) to make some operations simple, eg. turning text to upper or lower case only meant setting or clearing one bit if the code point was in a given range. This made some text operations much simpler and more performant, that is why pretty much everybody adopted ASCII.
Doing 7-bit ASCII operations with a 6-bit bytes is almost impossible and doing them with 18-bit words is wasteful.
When IBM was deciding on byte size a number of other options were considered, but the most advantageous was the 8-bit byte. Note that already with 8-bit bytes, this was over-provisioning space for character code, as ASCII was 7-bit. The extra bit offered quite some space for extra characters, which gave rise to character encodings. This isn't something I would expect a person living in the USA to know about, but users of other languages used upper 128 bytes for local and language specific characters.
When going with 8-bit byte, they also made the bytes individually addressable, making 32-bit integers actually 4 8-bit bytes. 8-bit byte also allowed to pack two BCD in one byte and you were able to get them out with a relatively simple operation.
Even though 8-bits was more than needed, they were deemed cost effective and "reasonably economical of storage space". And being a power of two allowed addressing a bit in a cost effective way, if a programmer needed to do so.
I think your post discounts and underestimates the amount of performance gain and cost optimisations 8-bit byte gave us at the time it mattered most, at the time computing power was low, and the fact that 8-bit bytes were just "good enough" and we didn't get anything usable from 9, 10, 12, 14 or 16 bit bytes.
On the other hand you overestimate the gains with imaginary problems, such as IPv4, which didn't even exist in 1960s (yes, we ran out of public space quite some time ago, no, not really a problem, even on pure IPv6 one has 6to4 NAT), or negative unix time - how on Earth did you get the idea that someone would use negative unix time stamps to represent historic datings, when most of the time we can't even be sure what year it was?
I think the most scary thing is having and odd-bit bytes; there would be a lot more people raging against the machine, if byte was 9 bits.
If you want to know why 8 bits, this is a good recap - https://jvns.ca/blog/2023/03/06/possible-reasons-8-bit-bytes... - along with the link to the book from the engineers who designed 8-bit bytes.
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…
This is not the case for 18 or 36 bits; I would imagine an architecture like this wouldn’t have a swap/swapb but a shuffle type instructions to specify where each nyte is expected to end up, encoded in 4x2 bit in the most generic case.
With this, I think I can get behind the 9-bit archs with the niceties described in the post..
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> 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)
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
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.
I think they had 19 bits of IP addresses available or sth crazy like that :) They were one of the institutions introducing internet in Poland back in 90s, so they had a huge portion of the addresses assigned and kept them.
Earlier quoted context omitted.
Author here. Really great comment; I've linked it from the OP. (Could do without the insults!) Most of the changes you point out sound... good? Maybe having fewer arbitrary limits would have sapped a few historically significant coders of their rage against the machine, but maybe it would have pulled in a few more people by being less annoying in general. On colors, I did mention that in the post but losing an alpha…
Your first paragraph implies 8-bit bytes are a coincidence, which is not true. It was a design decision. A byte in computer is the smallest addressable memory location and this location at that time contained a character. The way characters are encoded is called code. Early computers used 5-bits, which was not enough for alphabetics and numerals, 6 bits was not enough to encode numbers and lower and upper case charac…
Earlier quoted context omitted.
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.
See, why would you need an "architecture specific typedef" in order to represent the day of the month, or the number of arguments in main "in a portable way". int does it in a portable way already. It's just muddled thinking.
Earlier quoted context omitted.
If something is painful you aren't doing it often enough, right? So my (completely uninformed) idea would be 27 bit addresses that are only routable on the local LAN and then a second optional 27 bit address to route between LANs on the WAN. The effective 54 bit address space would have been more than large enough, and if you support modularly extending addresses like that then there's no reason not to keep going bey…
That's very loosely how IPv6 works. Your ISP will typically assign your router a prefix and will route any address starting with that 56 or 64 bit prefix to you. Then devices on your network pick the remaining bits and they get their full address.