Just mandate that everything must be run on an Intel or ARM chip and be done with it. Stop pretending anything else is viable.
C++ proposal: There are exactly 8 bits in a byte
281–290 of 357 posts
Re: C++ proposal: There are exactly 8 bits in a byte
#282Just mandate that everything must be run on an Intel or ARM chip and be done with it. Stop pretending anything else is viable.
C++ is the second-most-widely-available language (behind C). Many other things are viable. Everything from a Z15 IBM mainframe to almost every embedded chip in existence. ("Viable" meaning "still being produced and used in volume, and still being used in new designs".)
The next novel chip design is going to have a C++ compiler too. No, we don't yet know what its architecture will be.
Re: C++ proposal: There are exactly 8 bits in a byte
#283Is C++ capable of deprecating or simplifying anything? Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated. Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"
[deleted]
Re: C++ proposal: There are exactly 8 bits in a byte
#284Not sure about that, seems pretty controversial to me. Are we forgetting about the UNIVACs?
This would be a great setup for a time travelling science fiction where there is some legacy UNIVAC software that needs to be debugged, and John Titor, instead of looking for an IBM 5100, came back to the year 2024 to find a pre-P3477R0 compiler.
Steins;byte
Re: C++ proposal: There are exactly 8 bits in a byte
#285Is C++ capable of deprecating or simplifying anything? Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated. Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"
How is rand() broken? It seems to produce random-ish values, which is what it's for. It obviously doesn't produce cryptographically secure random values, but that's expected (and reflects other languages' equivalent functions). For a decently random integer that's quick to compute, rand() works just fine.
> The function rand() is not reentrant or thread-safe, since it uses hidden state that is modified on each call.
It cannot be called safely from a multi-threaded application for one
Re: C++ proposal: There are exactly 8 bits in a byte
#286Earlier quoted context omitted.
This is basically the reason. Another part of it is the fact that it's a lot easier to represent stuff with hex if the bytes line up. I can represent "255" with "0xFF" which fits nice and neat in 1 byte. However, now if a byte is 10bits that hex no longer really works. You have 1024 values to represent. The max value would be 0x3FF which just looks funky. Coming up with an alphanumeric system to represent 2^10 cleanl…
We probably wouldn't have chosen hex in a theoretical world where bytes were 10 bits, right? It would probably be two groups of 5 like 02:21 == 85 (like an ip address) or five groups of two 0x01111 == 85. It just has to be one of its divisors.
02:21
Re: C++ proposal: There are exactly 8 bits in a byte
#287Just mandate that everything must be run on an Intel or ARM chip and be done with it. Stop pretending anything else is viable.
RISC V is gaining ground.
Re: C++ proposal: There are exactly 8 bits in a byte
#288Earlier quoted context omitted.
I'm literally giving a talk next week who's first slide is essentially "Why IEEE 754 is not a sufficient description of floating-point semantics" and I'm sitting here trying to figure out what needs to be thrown out of the talk to make it fit the time slot. One of the most surprising things about floating-point is that very little is actually IEEE 754; most things are merely IEEE 754-ish, and there's a long tail of f…
The IEEE 754 standard has been updated several times, often by relaxing previous mandates in order to make various hardware implementations become compliant retroactively (eg, adding Intel's 80-bit floats as a standard floating point size). It'll be interesting if the "-ish" bits are still "-ish" with the current standard.
The first 754 standard (1985) was essentially formalization of the x87 arithmetic; it defines a "double extended" format. It is not mandatory:
> Implementations should support the extended format corresponding to the widest basic format supported.
_if_ it exists, it is required to have at least as many bits as the x87 long double type.¹
The language around extended formats changed in the 2008 standard, but the meaning didn't:
> Language standards or implementations should support an extended precision format that extends the widest basic format that is supported in that radix.
That language is still present in the 2019 standard. So nothing has ever really changed here. Double-extended is recommended, but not required. If it exists, the significand and exponent must be at least as large as those of the Intel 80-bit format, but they may also be larger.
---
¹ At the beginning of the standardization process, Kahan and Intel engineers still hoped that the x87 format would gradually expand in subsequent CPU generations until it became what is now the standard 128b quad format; they didn't understand the inertia of binary compatibility yet. So the text only set out minimum precision and exponent range. By the time the standard was published in 1985, it was understood internally that they would never change the type, but by then other companies had introduced different extended-precision types (e.g. the 96-bit type in Apple's SANE), so it was never pinned down.
Re: C++ proposal: There are exactly 8 bits in a byte
#289Earlier quoted context omitted.
Maybe specifying that floats are always IEEE floats should be next? Though that would obsolete this Linux kernel classic so maybe not. https://github.com/torvalds/linux/blob/master/include/math-e...
Which one? Remember the decimal IEEE 754 floating point formats exist too. Do folks in banking use IEEE decimal formats? I remember we used to have different math libs to link against depending, but this was like 40 years ago.
Binding float to the IEEE 754 binary32 format would not preclude use of decimal formats; they have their own bindings (e.g. _Decimal64 in C23). (I think they're still a TR for C++, but I haven't been keeping track).
Re: C++ proposal: There are exactly 8 bits in a byte
#290Just mandate that everything must be run on an Intel or ARM chip and be done with it. Stop pretending anything else is viable.
C++ is the second-most-widely-available language (behind C). Many other things are viable. Everything from a Z15 IBM mainframe to almost every embedded chip in existence. ("Viable" meaning "still being produced and used in volume, and still being used in new designs".) The next novel chip design is going to have a C++ compiler too. No, we don't yet know what its architecture will be.
Oh, but we do know - In order to be compatible with the existent languages, it's going to have to look similar to what we have now. It will have to keep 8 bit bytes instead of going wider that's what IBM came up with in the 1950s, and it will have to be a stack-oriented machine that looks like a VAX so it can run C programs. Unicode will always be a second-class character set behind ASCII because it has to look like it runs Unix, and we will always use IEEE floating point with all its inaccuracy because using scaling decimal data types just makes too much sense and we can't have that.