variable tipos tipo tabla sirve rangos que programacion para long datos dato c++ c types

c++ - tipos - ¿El tamaño de un int depende del compilador y/o procesador?



unsigned int c (10)

¿El tamaño de un entero dependería del compilador, sistema operativo y procesador?

Basado en una investigación reciente, he estudiado para entrevistas de firmware:

El impacto más significativo de la arquitectura de bits de los procesadores, es decir, 8 bits, 16 bits, 32 bits y 64 bits, es la forma más eficiente de almacenar cada byte de información para poder calcular mejor las variables en el número mínimo de ciclos.

El tamaño de bit de su procesador le dice cuál es la longitud de palabra natural que la CPU es capaz de manejar en un ciclo. Una máquina de 32 bits necesita 2 ciclos para manejar un doble de 64 bits si está alineado correctamente en la memoria. La mayoría de las computadoras personales eran y siguen siendo de 32 bits, de ahí la razón más probable para la afinidad típica del compilador de C para enteros de 32 bits con opciones para números de coma flotante más grandes y largos de entrada larga.

Claramente puede calcular tamaños variables más grandes, en ese sentido la arquitectura de bits de la CPU determina cómo tendrá que almacenar variables más grandes y más pequeñas para lograr la mejor eficiencia posible de procesamiento, pero de ninguna manera es un factor limitante en las definiciones de tamaños de bytes para ints o chars, eso es parte de los compiladores y lo que dictan las convenciones o estándares.

Encontré este sitio muy útil, http://www.geeksforgeeks.org/archives/9705 , para explicar cómo la longitud de palabra natural de la CPU afecta cómo elegirá almacenar y manejar tipos de variables cada vez más grandes, especialmente en lo que respecta al empaquetado de bits en estructuras. Debe ser muy consciente de cómo elige asignar variables porque las variables más grandes deben estar alineadas en la memoria para que tomen el menor número de ciclos cuando se divide por la longitud de palabra de la CPU. Esto agregará una gran cantidad de espacio vacío / búfer potencialmente innecesario a cosas como estructuras si ordena mal la asignación de sus variables.

El tamaño de int es igual a la longitud de palabra que depende del ISA subyacente. El procesador es solo la implementación de hardware del ISA y el compilador es solo la implementación de software del ISA. Todo gira en torno al ISA subyacente. El ISA más popular es el IA-32 de Intel actualmente. tiene una longitud de palabra de 32 bits o 4 bytes. 4 bytes podría ser el tamaño máximo de compiladores ''int'' (simplemente int, no corto ni largo). basado en IA-32, podría usar.

El tamaño del tipo de datos depende básicamente del tipo de compilador y los compiladores están diseñados en base a la arquitectura de los procesadores, por lo que el tipo de datos externamente puede considerarse dependiente del compilador. Por ejemplo, el tamaño del entero es de 2 bytes en el compilador de 16 bits tc pero de 4 bytes en el compilador gcc aunque se ejecutan en el mismo procesador

La respuesta a esta pregunta depende de qué tan lejos de las consideraciones prácticas estamos dispuestos a obtener.

En última instancia, en teoría, todo en C y C ++ depende del compilador y solo del compilador. Hardware / OS no tiene importancia en absoluto. El compilador es libre de implementar una capa de abstracción de hardware de cualquier grosor y emular absolutamente cualquier cosa. No hay nada que impida que una implementación C o C ++ implemente el tipo int de cualquier tamaño y con cualquier representación, siempre que sea lo suficientemente grande como para cumplir con los requisitos mínimos especificados en el estándar de lenguaje. Los ejemplos prácticos de tal nivel de abstracción están disponibles, por ejemplo, los lenguajes de programación basados ​​en la plataforma de "máquina virtual", como Java.

Sin embargo, C y C ++ están destinados a ser lenguajes altamente eficientes . Para lograr la máxima eficiencia, una implementación C o C ++ debe tener en cuenta ciertas consideraciones derivadas del hardware subyacente. Por esa razón, tiene mucho sentido asegurarse de que cada tipo básico se base en alguna representación directamente (o casi directamente) compatible con el hardware. En ese sentido, el tamaño de los tipos básicos depende del hardware.

En otras palabras, una implementación específica de C o C ++ para una plataforma de hardware / sistema operativo de 64 bits es absolutamente libre de implementar int como un tipo integral de 71 bits con complemento a 1 que ocupa 128 bits de memoria, usando los otros 57 bits como relleno bits que siempre se requieren para almacenar la fecha de nacimiento de la novia del autor del compilador. Esta implementación incluso tendrá cierto valor práctico: se puede usar para realizar pruebas en tiempo de ejecución de la portabilidad de los programas C / C ++. Pero ahí es donde terminaría la utilidad práctica de esa implementación. No espere ver algo así en un compilador C / C ++ "normal".

La respuesta simple y correcta es que depende del compilador. No significa que la arquitectura sea irrelevante, pero el compilador se encarga de eso, no de su aplicación. Se podría decir con más precisión que depende de la arquitectura (objetivo) del compilador, por ejemplo, si es de 32 bits o 64 bits.

Considere que tiene una aplicación de Windows que crea un archivo donde escribe un int además de otras cosas y lo lee de nuevo. ¿Qué sucede si ejecuta esto en ventanas de 32 bits y de 64 bits? ¿Qué sucede si copia el archivo creado en el sistema de 32 bits y lo abre en un sistema de 64 bits?

Puede pensar que el tamaño de int será diferente en cada archivo, pero no serán iguales y este es el quid de la cuestión. Usted elige la configuración en el compilador para apuntar a la arquitectura de 32 bits o 64 bits y eso lo dicta todo.

Sí lo haría. ¿Querían decir "de qué dependería: el compilador o el procesador"? En ese caso, la respuesta es básicamente "ambos". Normalmente, int no será más grande que un registro de procesador (a menos que sea más pequeño que 16 bits), pero podría ser más pequeño (por ejemplo, un compilador de 32 bits ejecutándose en un procesador de 64 bits). En general, sin embargo, necesitará un procesador de 64 bits para ejecutar código con una int de 64 bits.

Sí, depende de ambos procesadores (más específicamente, ISA, arquitectura del conjunto de instrucciones, por ejemplo, x86 y x86-64) y los compiladores, incluido el modelo de programación. Por ejemplo, en máquinas de 16 bits, sizeof (int) tenía 2 bytes. Las máquinas de 32 bits tienen 4 bytes para int . Se ha considerado que int era el tamaño nativo de un procesador, es decir, el tamaño del registro. Sin embargo, las computadoras de 32 bits eran tan populares, y se ha escrito una gran cantidad de software para el modelo de programación de 32 bits. Por lo tanto, sería muy confuso si la computadora de 64 bits tuviera 8 bytes para int . Tanto Linux como Windows permanecen 4 bytes para int . Pero, difieren en el tamaño de long .

Por favor, eche un vistazo al modelo de programación de 64 bits como LP64 para la mayoría * nix y LLP64 para Windows:

Tales diferencias son bastante embarazosas cuando escribes código que debería funcionar tanto en Windows como en Linux. Por lo tanto, siempre uso int32_t o int64_t , en lugar de long , a través de stdint.h .

Sí, encontré que el tamaño de int en turbo C era de 2 bytes donde, como en el compilador de MSVC, era de 4 bytes.

Básicamente, el tamaño de int es el tamaño de los registros del procesador.

Tipos de datos El tamaño depende del procesador, porque el compilador quiere hacer que la CPU sea más accesible al siguiente byte. por ejemplo: si el procesador es de 32 bits, el compilador no puede elegir el tamaño int como 2 bytes [que se supone que debe elegir 4 bytes] porque acceder a otros 2 bytes de ese int (4bytes) llevará un ciclo de CPU adicional que es inútil. Si el compilador elige int como 4 bytes, la CPU puede acceder a 4 bytes completos en una sola toma, lo que acelera su aplicación.

Gracias