software - Lista de plataformas soportadas por el estándar C

plataforma software definicion (7)

Debe tenerse en cuenta que no puede confiar en un comportamiento indefinido incluso en las plataformas de uso común, ya que los compiladores de optimización modernos realizan transformaciones de programa que solo conservan el comportamiento definido.

En particular, no puede confiar en la aritmética de complemento de dos que le ofrece INT_MAX+1 == INT_MIN . Por ejemplo, gcc 4.6.0 optimiza lo siguiente en un bucle infinito:

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

EDITAR : Consulte aquí para obtener más información sobre el desbordamiento firmado y las optimizaciones de GCC.

¿Alguien sabe de alguna plataforma compatible con el estándar C, para la cual todavía hay trabajo de desarrollo activo, pero que son:

no complemento de 2 o
el ancho entero no es de 32 bits o 64 bits o
algunos tipos de enteros tienen bits de relleno o
Si trabajó en una máquina de complemento a 2, el patrón de bits con el bit de signo 1 y todos los bits de valor cero no es un número negativo válido o
la conversión de entero de firmado a no firmado (y viceversa) no se realiza mediante la copia literal de patrones de bits o
El desplazamiento a la derecha del entero no es un cambio aritmético o
el número de bits de valor en un tipo sin signo no es el número de bits de valor en el tipo con signo correspondiente + 1 o
la conversión de un tipo int más ancho a un tipo más pequeño no se realiza mediante el truncamiento de los bits más a la izquierda que no encajan

EDITAR: Alternativamente, si hay plataformas en el período de 1995 a 1998 que influyeron en la decisión de C99 de incluir lo anterior, pero que se descontinuaron, también me interesaría por ellas.

EDITAR: La justificación C tiene esto que decir sobre los bits de relleno:

Los bits de relleno son accesibles para el usuario en un tipo entero sin signo. Por ejemplo, supongamos que una máquina utiliza un par de cortos de 16 bits (cada uno con su propio bit de signo) para formar un int de 32 bits y el bit de signo del cortocircuito inferior se ignora cuando se usa en este int de 32 bits. Luego, como un int con signo de 32 bits, hay un bit de relleno (en medio de los 32 bits) que se ignora al determinar el valor del int con signo de 32 bits. Pero, si este elemento de 32 bits se trata como un int sin signo de 32 bits, entonces ese bit de relleno es visible para el programa del usuario. Se le dijo al comité de C que hay una máquina que funciona de esta manera, y esa es una de las razones por las que los bits de relleno se agregaron a C99.

Las notas de pie de página 44 y 45 mencionan que los bits de paridad pueden ser bits de relleno. El comité no conoce ninguna máquina con bits de paridad accesibles por el usuario dentro de un entero. Por lo tanto, el comité no tiene conocimiento de ninguna máquina que trate los bits de paridad como bits de relleno.

Otra pregunta es, ¿cuál es esa máquina que mencionó C99?

EDITAR: Parece que C99 estaba considerando eliminar el soporte para el complemento de 1 y la magnitud firmada: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n873.htm (búsqueda de 6.2.6.2)

El compilador cc65 para Commodore C64 parece haber tenido alguna actualización hasta el año pasado.

Hace aproximadamente una década tuvimos que trasladar nuestra base de datos integrada C a un procesador DSP que resultó ser el procesador principal de un estéreo para automóvil. Era una máquina de 24 bits, de la peor manera: sizeof(char) == sizeof(int) == sizeof(void*) == 1 , que era de 24 bits. Llamamos a la sucursal que se ocupó de este puerto "infierno de 24 bits".

Desde entonces portamos nuestra biblioteca a muchas plataformas, pero ninguna tan extraña como esa. Es posible que todavía estén disponibles (los chips DSP baratos de 24 bits son incluso más baratos ahora), que se encuentran en dispositivos de bajo costo donde la facilidad de programación es un segundo lejano a una lista de materiales (BOM) baja. Ahora que lo pienso, creo que encontramos una máquina en la que un desplazamiento hacia la derecha de un entero sin signo no necesariamente insertaba cero bits. Aun así, las reglas aritméticas altamente no estándar en una plataforma garantizan la conversión de software, propenso a errores, que aumenta dramáticamente los costos de desarrollo de software. En algún punto prevalece la cordura y se observan las normas.

Sospecho que gran parte de la motivación para la presencia de estas reglas en C99 es su presencia en C89, y anteriores iteraciones del lenguaje. No olvide que cuando se inventó C, las computadoras eran mucho más diversas que en la actualidad. Los diseños de procesadores "bit-slice" estaban disponibles donde se podían agregar tantos bits como quisiera a su procesador simplemente agregando chips. Y antes de C, tenía que codificar en lenguaje ensamblador o preocuparse por dónde exactamente residiría su código en la RAM, etc.

C fue un avance espectacular en términos de portabilidad, pero tuvo que abarcar una amplia gama de sistemas, de ahí las reglas muy generales. 20 años después, cuando apareció Java, tuvo el beneficio de la historia al permitirle declarar de antemano cuán grandes serían los tipos primitivos, lo que hace que todo sea mucho más fácil, siempre y cuando las opciones de Java sean sólidas.

Sé que la mayoría de ustedes preguntan sobre los enteros, pero me he encontrado con algunas rarezas cuando se trata de punteros. Las primeras computadoras Macintosh tenían procesadores de 32 bits (Motorola 68000), pero solo buses de memoria de 24 bits. Por lo tanto, 0x00123456 y 0xFF123456 se referían a la misma celda de memoria, porque el procesador cortó los 8 bits superiores al acceder a la RAM. Los ingenieros de Apple utilizaron estos bits para almacenar metadatos sobre la memoria a la que apuntaba el puntero. Así, al comparar punteros, uno tenía que enmascarar primero los bits superiores. Y no me hagas comenzar con las arquitecturas de memoria segmentada del x86. :)

Ya que estamos en este tema, eche un vistazo a la norma de codificación MISRA , que es favorecida por los fabricantes de automóviles que necesitan máxima portabilidad y seguridad. También vea Hacker''s Delight, de Henry S. Warren, que tiene un montón de trucos útiles de twiddling.

Incluso si estas máquinas son antiguas, todavía hay una comunidad activa de programación para PDP-8, la mayoría pero no todas usando simulaciones: PDP-8 como ejemplo . ¡Y esta máquina, AFAIK, usa enteros de 12 bits!

Mis dos centavos. Por favor, no culpes, esto es por mi experiencia, no soy una teórica:

no complemento de 2

Todas las CPUs existentes son 2 complementarias

el ancho del entero no es de 32 bits o 64 bits

Hay arquitecturas de 8 y 16 bits también. 8 bit AVR MCU es un buen ejemplo.

algunos tipos enteros tienen bits de relleno

No conozco ningún sistema, que rellene enteros. Números flotantes - es una historia diferente.

Si trabajó en una máquina de complemento a 2, el patrón de bits con el bit de signo 1 y todos los bits de valor cero no es un número negativo válido
la conversión de enteros firmados a no firmados (y viceversa) no se realiza mediante la copia literal de patrones de bits
El desplazamiento a la derecha del entero no es un cambio aritmético
el número de bits de valor en un tipo sin signo no es el número de bits de valor en el tipo con signo correspondiente + 1
la conversión de un tipo int más ancho a un tipo más pequeño no se realiza mediante el truncamiento de los bits más a la izquierda que no encajan

Todo lo anterior, sin ser consciente de ninguno, y asumo que no existe tal máquina.

Recientemente trabajé en una compañía que todavía usaba una versión del PDP-10 y un puerto de GCC para esa plataforma. Los 10 que usamos tenían algunos de los atributos que enumeras:

Los enteros no son de 32 o 64 bits, tienen 36 bits de ancho.
Los bits de relleno se utilizan para algunas representaciones. Para enteros de precisión extendida (por ejemplo, de tipo largo y largo), la representación subyacente fue de 72 bits, en la que cada una de las palabras de 36 bits tenía un signo-bit.

Además de los atributos inusuales anteriores, existía el problema de que la máquina tenía varios mecanismos de direccionamiento de bytes diferentes. Los bytes con anchos en el rango de 6 a 12 bits de ancho podrían direccionarse mediante el uso de bits especiales en la propia dirección, lo que indicaba qué ancho y alineación de palabras se estaba usando. Para representar un char * se puede usar una representación que dirija bytes de 8 bits, todos los cuales se alinearon a la izquierda en la palabra, dejando 4 bits en cada palabra de 36 bits que no se abordaron en absoluto. Alternativamente, se podrían usar bytes de 9 bits que encajarían de manera uniforme en la palabra de 36 bits. Ambos enfoques tuvieron dificultades para la portabilidad, pero en el momento en que lo dejé, se consideró más práctico utilizar los bytes de 8 bits debido a la interacción con redes TCP / IP y dispositivos estándar que a menudo piensan en términos de 16, 24 o 32 Campos de bits que también tienen una estructura subyacente de bytes de 8 bits.

Por lo que sé, esta plataforma todavía se está utilizando en productos en el campo, y hay un desarrollador de compiladores en esta compañía que mantiene las versiones relativamente recientes de GCC actualizadas para permitir un mayor desarrollo de C en esta plataforma.

Un viejo adagio (olvidé la atribución) dice que

no hay tal cosa como código portátil

Pero solo que hay algunos códigos que han sido portados.

No debe preocuparse por escribir código portátil, debe preocuparse por escribir código que sea fácil de transferir a otras plataformas.

Además, usar solo el estándar C no te da muchas cosas útiles. Los estándares de Posix te dan mucho más.