Exotic architectures the standards committees care about

user_277176 0
Viewed 15139

I know that the C and C++ standards leave many aspects of the language implementation-defined just because if there is an architecture with other characteristics, it would be very difficult or impossible to write a standard conforming compiler for it.

I know that 40 years ago any computer had its own unique specification. However, I don't know of any architectures used today where:

  • CHAR_BIT != 8
  • signed is not two's complement (I heard Java had problems with this one).
  • Floating point is not IEEE 754 compliant (Edit: I meant "not in IEEE 754 binary encoding").

The reason I'm asking is that I often explain to people that it's good that C++ doesn't mandate any other low-level aspects like fixed sized types†. It's good because unlike 'other languages' it makes your code portable when used correctly (Edit: because it can be ported to more architectures without requiring emulation of low-level aspects of the machine, like e.g. two's complement arithmetic on sign+magnitude architecture). But I feel bad that I cannot point to any specific architecture myself.

So the question is: what architectures exhibit the above properties?

† uint*_ts are optional.

architecture c c++
7 Answers

CHAR_BITS

According to gcc source code:

CHAR_BIT is 16 bits for 1750a, dsp16xx architectures.
CHAR_BIT is 24 bits for dsp56k architecture.
CHAR_BIT is 32 bits for c4x architecture.

You can easily find more by doing:

find $GCC_SOURCE_TREE -type f | xargs grep "#define CHAR_TYPE_SIZE"

or

find $GCC_SOURCE_TREE -type f | xargs grep "#define BITS_PER_UNIT"

if CHAR_TYPE_SIZE is appropriately defined.

IEEE 754 compliance

If target architecture doesn't support floating point instructions, gcc may generate software fallback witch is not the standard compliant by default. More than, special options (like -funsafe-math-optimizations witch also disables sign preserving for zeros) can be used.

user_12827730

IEEE 754 binary representation was uncommon on GPUs until recently, see GPU Floating-Point Paranoia.

EDIT: a question has been raised in the comments whether GPU floating point is relevant to the usual computer programming, unrelated to graphics. Hell, yes! Most high performance thing industrially computed today is done on GPUs; the list includes AI, data mining, neural networks, physical simulations, weather forecast, and much much more. One of the links in the comments shows why: an order of magnitude floating point advantage of GPUs.

Another thing I'd like to add, which is more relevant to the OP question: what did people do 10-15 years ago when GPU floating point was not IEEE and when there was no API such as today's OpenCL or CUDA to program GPUs? Believe it or not, early GPU computing pioneers managed to program GPUs without an API to do that! I met one of them in my company. Here's what he did: he encoded the data he needed to compute as an image with pixels representing the values he was working on, then used OpenGL to perform the operations he needed (such as "gaussian blur" to represent a convolution with a normal distribution, etc), and decoded the resulting image back into an array of results. And this still was faster than using CPU!

Things like that is what prompted NVidia to finally make their internal data binary compatible with IEEE and to introduce an API oriented on computation rather than image manipulation.

user_25404070
Related