¿Qué plataformas tienen algo que no sea char de 8 bits?

11 minutos de lectura

¿Que plataformas tienen algo que no sea char de 8
craig mcqueen

De vez en cuando, alguien en SO señala que char (también conocido como ‘byte’) no es necesariamente de 8 bits.

Parece que 8 bits char es casi universal. Hubiera pensado que para las plataformas principales, es necesario tener una de 8 bits char para asegurar su viabilidad en el mercado.

Tanto ahora como históricamente, ¿qué plataformas utilizan un char eso no es 8 bits, y ¿por qué se diferenciarían de los 8 bits “normales”?

Al escribir código y pensar en el soporte multiplataforma (por ejemplo, para bibliotecas de uso general), ¿qué tipo de consideración vale la pena dar a las plataformas que no son de 8 bits? char?

En el pasado, me encontré con algunos DSP de Analog Devices para los cuales char es de 16 bits Supongo que los DSP son un poco una arquitectura de nicho. (Por otra parte, en ese momento, el ensamblador codificado a mano superó fácilmente lo que podían hacer los compiladores de C disponibles, por lo que realmente no obtuve mucha experiencia con C en esa plataforma).

  • La serie CDC Cyber ​​tenía una codificación de 6/12 bits. Los caracteres más populares eran de 6 bits. Los caracteres restantes utilizaron 12 bits.

    – Thomas Matthews

    20 de enero de 2010 a las 0:07

  • El PDP-11 lo logró. La noción de que un carácter puede codificarse en un char está seriamente obsoleta.

    -Hans Passant

    20 de enero de 2010 a las 1:38

  • “El PDP-11 lo logró”: ¿quiere decir porque C se implementó por primera vez para el PDP-11 con bytes de 8 bits? Pero luego se implementó C para máquinas Honeywell con bytes de 9 bits. Consulte la versión 1 de K&R. Además, la pregunta sobre el carácter (es decir, el byte) no sobre el carácter (uno o más bytes que codifican algo sobre lo que no se preguntó).

    – Programador de Windows

    20 de enero de 2010 a las 3:40

  • DEC-10 y DEC-20 tenían palabras de 36 bits. Cinco caracteres ASCII de 7 bits por palabra eran bastante comunes. También se utilizaron seis caracteres de 6 bits.

    – David R. Tribble

    20 de enero de 2010 a las 17:12

  • @CraigMcQueen: si no recuerdo mal, CodeVision para microcontroladores Atmel permite elegir el tamaño de char

    – vsz

    20 de febrero de 2016 a las 10:10

1647531073 205 ¿Que plataformas tienen algo que no sea char de 8
steve jesop

char también es de 16 bits en los DSP C54x de Texas Instruments, que aparecieron, por ejemplo, en OMAP2. Hay otros DSP de 16 y 32 bits char. Creo que incluso escuché sobre un DSP de 24 bits, pero no recuerdo qué, así que tal vez lo imaginé.

Otra consideración es que los mandatos POSIX CHAR_BIT == 8. Entonces, si está usando POSIX, puede asumirlo. Si más tarde alguien necesita portar su código a una implementación cercana a POSIX, resulta que tiene las funciones que usa pero en un tamaño diferente charesa es su mala suerte.

En general, sin embargo, creo que casi siempre es más fácil solucionar el problema que pensar en él. Sólo tipo CHAR_BIT. Si desea un tipo exacto de 8 bits, utilice int8_t. Su código fallará ruidosamente al compilar en implementaciones que no proporcionen uno, en lugar de usar silenciosamente un tamaño que no esperaba. Como mínimo, si encuentro un caso en el que tengo una buena razón para asumirlo, entonces lo afirmaría.

  • Los DSP TI C62xx y C64xx también tienen caracteres de 16 bits. (uint8_t no está definido en esa plataforma).

    – myron-semack

    20 de enero de 2010 a las 2:35

  • Muchos DSP para procesamiento de audio son máquinas de 24 bits; los belasigna DSP de On Semi (después de que compraron AMI Semi); los DSP56K/audio sinfónico DSP de Freescale (después de que se separaron de Motorola).

    –David Cary

    6 de julio de 2012 a las 13:52

  • @msemack C64xx tiene hardware para 8/16/32/40 y caracteres de 8 bits

    – usuario3528438

    16/04/2015 a las 20:45

  • En vez de assert() (si eso es lo que quisiste decir), usaría #if CHAR_BIT != 8#error "I require CHAR_BIT == 8"#endif

    –Keith Thompson

    02/10/2015 a las 20:52

  • @KeithThompson ¿Hay alguna razón para no usar static_assert()?

    – Qix – MONICA FUE MALTRATADA

    17 de febrero de 2017 a las 4:35

¿Que plataformas tienen algo que no sea char de 8
Juan Feminella

Al escribir código y pensar en el soporte multiplataforma (por ejemplo, para bibliotecas de uso general), ¿qué tipo de consideración vale la pena dar a las plataformas con caracteres que no son de 8 bits?

No se trata tanto de que “valga la pena considerar” algo, sino de seguir las reglas. En C++, por ejemplo, el estándar dice que todos los bytes tendrán “al menos” 8 bits. Si su código asume que los bytes tienen exactamente 8 bits, está violando el estándar.

Esto puede parecer una tontería ahora…por supuesto ¡todos los bytes tienen 8 bits!”, te escucho decir. Pero muchas personas muy inteligentes se han basado en suposiciones que no eran garantías, y luego todo se rompió. La historia está repleta de ejemplos de este tipo.

Por ejemplo, la mayoría de los desarrolladores de principios de la década de 1990 asumieron que un retardo de temporización de CPU sin operación en particular que tomara una cantidad fija de ciclos tomaría una cantidad fija de tiempo de reloj, porque la mayoría de las CPU de consumo tenían aproximadamente el mismo poder. Desafortunadamente, las computadoras se volvieron más rápidas muy rápidamente. Esto generó el surgimiento de cajas con botones “Turbo”, cuyo propósito, irónicamente, era ralentizar la computadora para que los juegos que usaban la técnica de retardo de tiempo pudieran jugarse a una velocidad razonable.


Un comentarista preguntó en qué parte del estándar dice que el carácter debe tener al menos 8 bits. esta en la seccion 5.2.4.2.1. Esta sección define CHAR_BITel número de bits en la entidad direccionable más pequeña y tiene un valor predeterminado de 8. También dice:

Sus valores definidos por la implementación serán iguales o mayores en magnitud (valor absoluto) a los mostrados, con el mismo signo.

Entonces, cualquier número igual a 8 o mayor es adecuado para sustituirlo por una implementación en CHAR_BIT.

  • No he visto un botón Turbo en al menos 20 años. ¿De verdad crees que está relacionado con la pregunta?

    – Mark Ransom

    20 de enero de 2010 a las 3:30

  • @Mark Ransom: Ese es el punto. Los desarrolladores a menudo confían en suposiciones que parecen ser ciertas en este momento, pero que son mucho más inestables de lo que parecen inicialmente. (No puedo contar el número de veces que he hecho que error!) El botón Turbo debería ser un doloroso recordatorio de no hacer suposiciones innecesarias, y ciertamente no hacer suposiciones que no están garantizadas por un estándar de lenguaje como si fueran hechos inmutables.

    – Juan Feminella

    20 de enero de 2010 a las 3:33


  • ¿Podría señalar un lugar en C ++ Standard que dice que el adiós tiene al menos 8 bits? Es una creencia común, sin embargo, personalmente no pude encontrarla en el Estándar. Lo único que encontré en Estándar es qué personajes deben ser representables por char hay más de 64 pero menos de 128, por lo que 7 bits serían suficientes.

    – Adán Badura

    20 de enero de 2010 a las 6:48

  • La Sección 18.2.2 invoca el estándar C para ello. En el estándar C es la sección 7.10 y luego la sección 5.4.2.4.1. Página 22 en el estándar C.

    – Programador de Windows

    21 de enero de 2010 a las 3:48

  • Entonces, otras respuestas y comentarios mencionan máquinas con bytes de 5 bits, 6 bits y 7 bits. ¿Significa eso que no puede ejecutar un programa C en esa máquina que cumple con el estándar?

    – Jerry Jeremías

    7 de febrero de 2018 a las 1:30

Las máquinas con arquitecturas de 36 bits tienen bytes de 9 bits. Según Wikipedia, máquinas con arquitecturas de 36 bits incluir:

  • Corporación de equipos digitales PDP-6/10
  • IBM 701/704/709/7090/7094
  • UNIVAC 1103/1103A/1105/1100/2200,

  • También máquinas Honeywell, como quizás la segunda máquina donde se implementó C. Ver K&R versión 1.

    – Programador de Windows

    20 de enero de 2010 a las 3:44

  • En realidad, el 10 de diciembre también tenía caracteres de 6 bits: podría empaquetar 6 de estos en una palabra de 36 bits (ex-programador de 10 de diciembre hablando)

    luego

    20 de enero de 2010 a las 14:52

  • El DEC-20 usó cinco caracteres ASCII de 7 bits por palabra de 36 bits en el TOPS-20 O/S.

    – David R. Tribble

    20 de enero de 2010 a las 17:19

  • Esa broma en realidad se implementó para admitir Unicode en esta arquitectura.

    – Josué

    14 de diciembre de 2011 a las 7:31

  • Me imagino que la razón por la que se usó el octal fue porque 3 dígitos octales representan claramente un byte de 9 bits, al igual que normalmente usamos el hexadecimal hoy en día porque dos dígitos hexadecimales representan claramente un byte de 8 bits.

    – bames53

    11 de julio de 2012 a las 0:20


Algunos de los cuales soy consciente:

  • DEC PDP-10: variable, pero con mayor frecuencia caracteres de 7 bits empaquetados 5 por palabra de 36 bits, o caracteres de 9 bits, 4 por palabra
  • Mainframes de datos de control (CDC-6400, 6500, 6600, 7600, Cyber ​​170, Cyber ​​176, etc.) caracteres de 6 bits, empaquetados 10 por palabra de 60 bits.
  • Unidades centrales Unisys: 9 bits/byte
  • Windows CE: simplemente no es compatible con el tipo `char`; en su lugar, requiere wchar_t de 16 bits

No existe tal cosa como un código completamente portátil. 🙂

Sí, puede haber varios tamaños de bytes/caracteres. Sí, puede haber implementaciones de C/C++ para plataformas con valores muy inusuales de CHAR_BIT y UCHAR_MAX. Sí, a veces es posible escribir código que no dependa del tamaño de los caracteres.

Sin embargo, casi ningún código real es independiente. Por ejemplo, puede estar escribiendo un código que envía mensajes binarios a la red (el protocolo no es importante). Puede definir estructuras que contengan campos necesarios. Entonces tienes que serializarlo. La simple copia binaria de una estructura en un búfer de salida no es portátil: por lo general, no conoce el orden de bytes de la plataforma ni la alineación de los miembros de la estructura, por lo que la estructura solo contiene los datos, pero no describe la forma en que se deben serializar. .

Está bien. Puede realizar transformaciones de orden de bytes y mover los miembros de la estructura (p. ej. uint32_t o similar) usando memcpy en el búfer. Por qué memcpy? Porque hay muchas plataformas en las que no es posible escribir 32 bits (16 bits, 64 bits, no hay diferencia) cuando la dirección de destino no está alineada correctamente.

Entonces, ya ha hecho mucho para lograr la portabilidad.

Y ahora la pregunta final. Tenemos un amortiguador. Los datos que contiene se envían a la red TCP/IP. Dicha red asume bytes de 8 bits. La pregunta es: ¿de qué tipo debe ser el búfer? Si sus caracteres son de 9 bits? Si son de 16 bits? 24? ¿Quizás cada carácter corresponde a un byte de 8 bits enviado a la red, y solo se usan 8 bits? ¿O tal vez varios bytes de red están empaquetados en caracteres de 24/16/9 bits? Esa es una pregunta, y es difícil creer que haya una sola respuesta que se ajuste a todos los casos. Muchas cosas dependen de la implementación del socket para la plataforma de destino.

Entonces, de lo que estoy hablando. Por lo general, el código se puede hacer con relativa facilidad portátil hasta cierto punto. Es muy importante hacerlo si espera usar el código en diferentes plataformas. Sin embargo, mejorar la portabilidad más allá de esa medida es algo que requiere mucho esfuerzo y, a menudo, da poco, ya que el código real casi siempre depende de otro código (implementación de socket en el ejemplo anterior). Estoy seguro de que para aproximadamente el 90% del código, la capacidad de trabajar en plataformas con bytes que no sean de 8 bits es casi inútil, ya que utiliza un entorno vinculado a 8 bits. Simplemente verifique el tamaño del byte y realice la afirmación del tiempo de compilación. Es casi seguro que tendrá que reescribir mucho para una plataforma muy inusual.

Pero si su código es muy “independiente”, ¿por qué no? Puede escribirlo de una manera que permita diferentes tamaños de bytes.

  • Si se almacena un octeto por unsigned char valor no debería haber problemas de portabilidad a menos que el código use trucos de alias en lugar de cambios para convertir secuencias de octetos a/desde tipos enteros más grandes. Personalmente, creo que el estándar C debería definir intrínsecos para empaquetar/desempaquetar enteros de secuencias de tipos más cortos (más típicamente char) almacenar un número fijo de bits disponibles garantizados por elemento (8 por unsigned char16 por unsigned shorto 32 por unsigned long).

    – Super gato

    25 de julio de 2015 a las 19:42

1647531074 371 ¿Que plataformas tienen algo que no sea char de 8
dmckee — gatito ex-moderador

Parece que todavía puedes comprar un IM6100 (es decir, un PDP-8 en un chip) fuera de un almacén. Esa es una arquitectura de 12 bits.

  • Si se almacena un octeto por unsigned char valor no debería haber problemas de portabilidad a menos que el código use trucos de alias en lugar de cambios para convertir secuencias de octetos a/desde tipos enteros más grandes. Personalmente, creo que el estándar C debería definir intrínsecos para empaquetar/desempaquetar enteros de secuencias de tipos más cortos (más típicamente char) almacenar un número fijo de bits disponibles garantizados por elemento (8 por unsigned char16 por unsigned shorto 32 por unsigned long).

    – Super gato

    25 de julio de 2015 a las 19:42

1647531074 917 ¿Que plataformas tienen algo que no sea char de 8
Alok Singhal

Muchos chips DSP tienen 16 o 32 bits char. TI rutinariamente fabrica tales chips por ejemplo.

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad