We had quite a bit of existing FP hardware before the IEEE spec. Code using that hardware was not portable, because each FP unit did things subtly (and sometim

We had quite a bit of existing FP hardware before the IEEE spec. Code using that hardware was not portable, because each FP unit did things subtly (and sometimes not that subtly) different. All those already existing hardware units were already doing this type of bit trickery. That's one of the main things that differentiated units from each other. The people that developed these units all had a stake and were involved in the IEEE process. That's what "standardization" used to mean. Once you have enough implementations of something that compatibility is an issue, then, with the hindsight of all those implementations, you create a standard. Today, the meaning of "standardization" is lost. I've seen so many standards that are based on zero actual experience, that had no implementations before the process began, and that 10 years later after many people invested thousands of man hours into a standard document, still have no implementation, some of which, like OpenCL 2 and OpenCL 3 have ended up being "retracted" and we are back to OpenCL 1. This is particularly true for Khronos standards, Vulkan being the most recent exception. Khronos failures include OpenCL 2, OpenCL 3, OpenMP, SyCL (getting first implementations now, 5-6 years before the first standard was written....). Even for the relatively widely used OpenMP standard, now at version 5, there are still so many features of OpenMP3 that have never been implemented and are arguably useless, that it isn't even funny. Same for OpenMP4 and 5 which mainly added "useless" GPU support (GPU support is important, but the way it was added makes it useless). The reason Khronos standard suck is because "designers" that can't program hello world write some idea on toilet paper, and sign it off as a standard. Then they ask "the community" to implement it for them, and either nobody cares, or the problem the standard solves are problems nobody has, or the ideas are just wishful thinking that aren't implementable, etc. The C++ standard is going the same route with signing off on tons of stuff that has little implementation experience, zero proven actual practical value delivered to users. The best C++ standard spectacular failure example is Concepts. 15 years and thousands of man years invested in designing Concepts, a feature whose main goal is to improve template error messages. Turns out, concepts actually make template error messages worse. They aren't completely useless, but still... who would have thought, right? Well, turns out that every standard that was standardizing standard practice would have... known this... you know... from actual experience...