First: IEEE 754 computers are not all the same.
It would seem we are hardly flexible at all at the machine arithmetic level. We generally expect close conformance to IEEE 754! Yet there are several ``almost IEEE'' systems like the Alpha in default mode and the UltraSPARC flushing to zero. There is great (unwarranted) variability in how fast processors operate on NaNs, infinities, and subnormals. This great speed penalty for operation on those values can stymie calculations that would ordinarily benefit from these additions to the number domain.
So we don't really have a completely common base. (In fact, there may be variations in conformance that change with operating system version!)
A Principle
Combining numeric portability, speed and quality, and use of a high-level language suggests a few rules based on this principle:
The language design should provide access to allowed extensions of the IEEE 754 standard that are implemented on a particular architecture to show through to the programmer in a systematic way.
a. The availability of such extensions should be detectable at run-time;
b. The access to such extensions should be as uniform as possible relative to the language design. (E.g. support of types, generic operations);
c. To the extent that the results of calculations in such extensions may not be bit-for-bit specified by agreed-upon hardware standards, they should not be specified by language standards.
Problems with Java
This portability issue crops up in particular in the Java milieu, where it is plausible on some architectures (Intel and clones) to exploit extra-width registers for floating-point calculations, when other architectures (Sun, for example) does not have such capabilities.
(a) Javasoft/Sun wants Java as it runs on Sun, Motorola, (non-Intel) to run at full speed and provide the bit-for-bit results specified as a language requirement.
Therefore anyone running on Intel architecture is forced, in effect, to emulate registers that are no longer than those on Sun. They are forced to "round to double" or store in memory to accomplish the same thing. In practice, rounding to double in registers is inadequate because the extended format has more exponent range too. (In effect one may be forced to do about the most expensive operation available these days: store to memory!)
(b) Intel advocates ask why they should be forced to slow down AND get worse answers than their superior wider (80 bit!) arithmetic will produce, just to be bit-compatible with others' inferior design.
(c) Solution offered by Borneo modification of Java is to support types float (= single) double and indigenous. Indigenous is the largest fp format with direct hardware execution on a given processor, in practice IEEE 754 double or double extended. Indigenous is therefore range and precision platform-dependent (complications result if constants are computed before runtime..) There are yet more suggestions for numerical types for Borneo including DoubledDouble (128 bit) and arbitrary-length Extended, Interval, Complex and Imaginary.
(d) Solution offered by Javasoft (May, 1998) is to allow - not new types - but alternative formats for types float and double under the keyword modifiers widefp or strictfp. The strictfp is the write-once-run-everywhere semantics, and the widefp allows extended length. Default would apparently be widefp, but an implementation of Java would be free to ignore the widefp specification, and one would not necessarily have control over which was used for execution. In other words the compiler writer would not be required to provide access to indigenous. And at run-time one would not be able to specify and hence take advantage of known extra precision. The main problem with Sun's proposal is that the compiler doesn't have to use the extended formats consistently. It could could decide not to use extended formats certain days of the week, or only use extended formats after something is jit'ed but not while interpreting, or only spill 64 bit values instead of 80.
(e) August, 1998, WK/JD revision of Java FP, concessions by Javasoft.