Earlier quoted context omitted.
Zig allows any uX and iX in the range of 1 - 65,535, as well as u0
u0?? Why?
To avoid corner cases in auto-generated code?
C++ proposal: There are exactly 8 bits in a byte
301–310 of 357 posts
Re: C++ proposal: There are exactly 8 bits in a byte
#302Earlier quoted context omitted.
Henceforth, it follows that a doublesnack is called a lunch. And a quadruplesnack a fourthmeal.
There's only one right answer: Nybble - 4 bits Byte - 8 bits Snyack - 16 bits Lyunch - 32 bits Dynner - 64 bits
This is incompatible with cultures where lunch is bigger than dinner.
Re: C++ proposal: There are exactly 8 bits in a byte
#303Earlier quoted context omitted.
What's the right way?
I would say anyone mentioning a specific encoding / size just wants to see the world burn. Unicode is variable length on various levels, how many people want to deal with the fact that the unicode of their text could be non normalized or want the ability to cut out individual "char" elements only to get a nonsensical result because the following elements were logically connected to that char? Give developers a decent…
I think this is what Rust does, if I remember correctly, it provides APIs in string to enumerate the characters accurately. That meaning, not necessarily byte by byte.
Re: C++ proposal: There are exactly 8 bits in a byte
#304Earlier quoted context omitted.
I wrote code on a DECSYSTEM-20, the C compiler was not officially supported. It had a 36-bit word and a 7-bit byte. Yep, when you packed bytes into a word there were bits left over. And I was tasked with reading a tape with binary data in 8-bit format. Hilarity ensued.
That is so strange. If it were 9-bit bytes, that would make sense: 8bits+parity. Then a word is just 32bits+4 parity.
8 bits in a byte exist in the first place because "obviously" a byte is a 7 bit char + parity.
(*) For some value of "obviously".
Re: C++ proposal: There are exactly 8 bits in a byte
#305Earlier quoted context omitted.
>A 9-bit byte is found on 36-bit machines in quarter-word mode. I've only programmed in high level programming languages in 8-bit-byte machines. I can't understand what you mean by this sentence. So in a 36-bit CPU a word is 36 bits. And a byte isn't a word. But what is a word and how does it differ from a byte? If you asked me what 32-bit/64-bit means in a CPU, I'd say it's how large memory addresses can be. Is that…
A word is the unit of addressing. A 36-bit machine has 36 bits of data stored at address 1, and another 36 bits at address 2, and so forth. This is inconvenient for text processing. You have to do a lot of shifting and masking. There's a bit of hardware help on some machines. UNIVAC hardware allowed accessing one-sixth of a word (6 bits), or one-quarter of a word (8 bits), or one-third of a word (12 bits), or a half…
I see. I never realized that machines needed to be random number of bits because they couldn't do double-precision so it was easier to make the word larger and do "half" precision instead.
Thanks a lot for your explanation, but does that mean "byte" is any amount of data that can be fetched in a given mode in such machines?
e.g. you have 6-bit, 9-bit, 12-bit, and 18-bit bytes in a 36-bit machine in sixth-word mode, quarter-word mode, third-word mode, and half-word mode, respectively? Which means in full-word mode the "byte" would be 36 bits?
Re: C++ proposal: There are exactly 8 bits in a byte
#306Earlier quoted context omitted.
>A 9-bit byte is found on 36-bit machines in quarter-word mode. I've only programmed in high level programming languages in 8-bit-byte machines. I can't understand what you mean by this sentence. So in a 36-bit CPU a word is 36 bits. And a byte isn't a word. But what is a word and how does it differ from a byte? If you asked me what 32-bit/64-bit means in a CPU, I'd say it's how large memory addresses can be. Is that…
A word is the unit of addressing. A 36-bit machine has 36 bits of data stored at address 1, and another 36 bits at address 2, and so forth. This is inconvenient for text processing. You have to do a lot of shifting and masking. There's a bit of hardware help on some machines. UNIVAC hardware allowed accessing one-sixth of a word (6 bits), or one-quarter of a word (8 bits), or one-third of a word (12 bits), or a half…
36 bits also gave you 10 decimal digits for fixed point calculations. My mom says that this was important for atomic calculations back in the 1950s - you needed that level of precision on the masses.
Re: C++ proposal: There are exactly 8 bits in a byte
#307Earlier quoted context omitted.
A word is the unit of addressing. A 36-bit machine has 36 bits of data stored at address 1, and another 36 bits at address 2, and so forth. This is inconvenient for text processing. You have to do a lot of shifting and masking. There's a bit of hardware help on some machines. UNIVAC hardware allowed accessing one-sixth of a word (6 bits), or one-quarter of a word (8 bits), or one-third of a word (12 bits), or a half…
I see. I never realized that machines needed to be random number of bits because they couldn't do double-precision so it was easier to make the word larger and do "half" precision instead. Thanks a lot for your explanation, but does that mean "byte" is any amount of data that can be fetched in a given mode in such machines? e.g. you have 6-bit, 9-bit, 12-bit, and 18-bit bytes in a 36-bit machine in sixth-word mode, q…
I don't think so. In the "normal" world, you can't address anything smaller than a byte, and you can only address in increments of a byte. A "word" is usually the size of the integer registers in the CPU. So the 36-bit machine would have a word size of 36 bits, and either six-bit bytes or nine-bit bytes, depending on how it was configured.
At least, if I understood all of this...
Re: C++ proposal: There are exactly 8 bits in a byte
#308D made a great leap forward with the following: 1. bytes are 8 bits 2. shorts are 16 bits 3. ints are 32 bits 4. longs are 64 bits 5. arithmetic is 2's complement 6. IEEE floating point and a big chunk of wasted time trying to abstract these away and getting it wrong anyway was saved. Millions of people cried out in relief! Oh, and Unicode was the character set. Not EBCDIC, RADIX-50, etc.
That's a bit self-pat-on-the-back-ish, isn't it, Mr. Bright, the author of D language? :)
Re: C++ proposal: There are exactly 8 bits in a byte
#309Earlier quoted context omitted.
A word is the unit of addressing. A 36-bit machine has 36 bits of data stored at address 1, and another 36 bits at address 2, and so forth. This is inconvenient for text processing. You have to do a lot of shifting and masking. There's a bit of hardware help on some machines. UNIVAC hardware allowed accessing one-sixth of a word (6 bits), or one-quarter of a word (8 bits), or one-third of a word (12 bits), or a half…
I see. I never realized that machines needed to be random number of bits because they couldn't do double-precision so it was easier to make the word larger and do "half" precision instead. Thanks a lot for your explanation, but does that mean "byte" is any amount of data that can be fetched in a given mode in such machines? e.g. you have 6-bit, 9-bit, 12-bit, and 18-bit bytes in a 36-bit machine in sixth-word mode, q…
The term "byte" was introduced by IBM at the launch of the IBM System/360 in 1964. [1], which event also introduced the term "throughput". IBM never used it officially in reference to their 36-bit machines. By 1969, IBM had discontinued selling their 36-bit machines. UNIVAC and DEC held onto 36 bits for several more decades, though.
Re: C++ proposal: There are exactly 8 bits in a byte
#310Earlier quoted context omitted.
Nope! Because then you will also define an alias, and Suzy will define an alias, and Bob will define an alias, ... We should all agree on int and uint ; not some isize nonsense, and not bobint or suzyint .
Ok, it is obvious that you are looking for something to complaint about and don't want to find a solution. That is not a productive attitude in life, but whatever floats your boat. Have a good day.
> looking for something to complaint about
You know, that describes pretty much everyone who has anything to do with Rust.
"My ls utility isn't written in Rust, yikes! Let's fix that!"
"The comments under this C++-related HN submission aren't talking about Rust enough, yikes! Let's fix that!"
I'm obviously pointing to a solution: have a standard module that any Rust program can depend on coming from the language, which has a few sanely named types. Rather than every program defining its own.