List of platforms supported by the C standard

Question

Does anyone know of any platforms supported by the C standard, for which there is still active development work, but which are:

• not 2's complement or
• the integer width is not 32 bits or 64 bits or
• some integer types have padding bits or
• if you worked on a 2's complement machine, the bit pattern with sign bit 1 and all value bits zero is not a valid negative number or
• integer conversion from signed to unsigned (and vice versa) is not via verbatim copying of bit patterns or
• right shift of integer is not arithmetic shift or
• the number of value bits in an unsigned type is not the number of value bits in the corresponding signed type + 1 or
• conversion from a wider int type to a smaller type is not by truncation of the left most bits which would not fit

EDIT: Alternatively, if there are platforms in the period 1995 to 1998 which influenced the C99 decision to include the above, but which were discontinued, I would be interested in them also.

EDIT: The C rationale has this to say about padding bits:

Padding bits are user-accessible in an unsigned integer type. For example, suppose a machine uses a pair of 16-bit shorts (each with its own sign bit) to make up a 32-bit int and the sign bit of the lower short is ignored when used in this 32-bit int. Then, as a 32-bit signed int, there is a padding bit (in the middle of the 32 bits) that is ignored in determining the value of the 32-bit signed int. But, if this 32-bit item is treated as a 32-bit unsigned int, then that padding bit is visible to the user’s program. The C committee was told that there is a machine that works this way, and that is one reason that padding bits were added to C99.

Footnotes 44 and 45 mention that parity bits might be padding bits. The committee does not know of any machines with user-accessible parity bits within an integer. Therefore, the committee is not aware of any machines that treat parity bits as padding bits.

So another question is, what is that machine which C99 mentioned?

EDIT: It seems that C99 was considering removing support for 1's complement and signed magnitude: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n873.htm (search for 6.2.6.2)

Answer 1

I recently worked at a company which still used a version of the PDP-10, and a port of GCC to that platform. The 10 we used had a few of the attributes you list:

• Integers are not 32 or 64 bits they are 36 bits wide.
• Padding bits are used for some representations. For extended precision integers (e.g. of long long type), the underlying representation was 72-bits in which each of the 36-bit words had a sign-bit.

In addition to the above unusual attributes, there was the issue that the machine had several different byte addressing mechanisms. Bytes with widths in the range of 6-12 bits wide could be addressed by using special bits in the address itself which indicated which width and word alignment was being used. To represent a char* one could use a representation which would address 8-bit bytes, all of which were left-aligned in the word, leaving 4-bits in each 36-bit word which were not addressed at all. Alternatively 9-bit bytes could be used which would fit evenly into the 36-bit word. Both such approaches had there pitfalls for portability, but at the time I left it was deemed more practical to use the 8-bit bytes because of interaction with TCP/IP networking and standard devices which often think in terms of 16, 24, or 32-bit fields which also have an underlying structure of 8-bit bytes.

As far as I know this platform is still being used in products in the field, and there is a compiler developer at this company keeping relatively recent versions of GCC up to date in order to allow for further C development on this platform.

Answer 2

It should be noted that you cannot rely on undefined behaviour even on commonly used platforms, because modern optimizing compilers perform program transformations that only preserve defined behaviour.

In particular, you cannot rely on two's complement arithmetic giving you INT_MAX+1 == INT_MIN. For example, gcc 4.6.0 optimizes the following into an infinite loop:

#include <stdio.h> int main() {      int i = 0;      while (i++ >= 0)           puts(".");      return 0; } 

EDIT: See here for more on signed overflow and GCC optimizations.