Exotic architectures the standards committees care about

Take a look at this one

Unisys ClearPath Dorado Servers

offering backward compatibility for people who have not yet migrated all their Univac software.

Key points:

• 36-bit words
• CHAR_BIT == 9
• one's complement
• 72-bit non-IEEE floating point
• separate address space for code and data
• word-addressed
• no dedicated stack pointer

Don't know if they offer a C++ compiler though, but they could.

And now a link to a recent edition of their C manual has surfaced:

Unisys C Compiler Programming Reference Manual

Section 4.5 has a table of data types with 9, 18, 36, and 72 bits.

None of your assumptions hold for mainframes. For starters, I don't knowof a mainframe which uses IEEE 754: IBM uses base 16 floating point, andboth of the Unisys mainframes use base 8. The Unisys machines are a bitspecial in many other respects: Bo has mentioned the 2200 architecture,but the MPS architecture is even stranger: 48 bit tagged words.(Whether the word is a pointer or not depends on a bit in the word.)And the numeric representations are designed so that there is no realdistinction between floating point and integral arithmetic: the floatingpoint is base 8; it doesn't require normalization, and unlike everyother floating point I've seen, it puts the decimal to the right of themantissa, rather than the left, and uses signed magnitude for theexponent (in addition to the mantissa). With the results that anintegral floating point value has (or can have) exactly the same bitrepresentation as a signed magnitude integer. And there are no floatingpoint arithmetic instructions: if the exponents of the two values areboth 0, the instruction does integral arithmetic, otherwise, it doesfloating point arithmetic. (A continuation of the tagging philosophy inthe architecture.) Which means that while int may occupy 48 bits, 8of them must be 0, or the value won't be treated as an integer.

Full IEEE 754 compliance is rare in floating-point implementations. And weakening the specification in that regard allows lots of optimizations.

For example the subnorm support differers between x87 and SSE.

Optimizations like fusing a multiplication and addition which were separate in the source code slightly change the results too, but is nice optimization on some architectures.

Or on x86 strict IEEE compliance might require certain flags being set or additional transfers between floating point registers and normal memory to force it to use the specified floating point type instead of its internal 80bit floats.

And some platforms have no hardware floats at all and thus need to emulate them in software. And some of the requirements of IEEE 754 might be expensive to implement in software. In particular the rounding rules might be a problem.

My conclusion is that you don't need exotic architectures in order to get into situations were you don't always want to guarantee strict IEEE compliance. For this reason were few programming languages guarantee strict IEEE compliance.