O tamanho de um int depende do compilador e / ou processador?

O tamanho de um inteiro dependeria do compilador, sistema operacional e processador?

A resposta a esta pergunta depende de quão longe das considerações práticas estamos dispostos a obter.

Em última análise, em teoria, tudo em C e C ++ depende do compilador e apenas do compilador. Hardware / OS não tem importância alguma. O compilador está livre para implementar uma camada de abstração de hardware de qualquer espessura e emular absolutamente qualquer coisa. Não há nada que impeça que uma implementação C ou C ++ implemente o tipo int de qualquer tamanho e com qualquer representação, desde que seja grande o suficiente para atender aos requisitos mínimos especificados no padrão de idioma. Exemplos práticos de tal nível de abstração estão prontamente disponíveis, por exemplo, linguagens de programação baseadas na plataforma de “máquina virtual”, como o Java.

No entanto, C e C ++ devem ser linguagens altamente eficientes . Para atingir a máxima eficiência, uma implementação em C ou C ++ deve levar em consideração certas considerações derivadas do hardware subjacente. Por essa razão, faz muito sentido certificar-se de que cada tipo básico seja baseado em alguma representação direta (ou quase diretamente) suportada pelo hardware. Nesse sentido, o tamanho dos tipos básicos depende do hardware.

Em outras palavras, uma implementação específica de C ou C ++ para uma plataforma de hardware / SO de 64 bits é absolutamente livre para implementar int como um tipo integral assinado de 1-complemento de 1-bit que ocupa 128 bits de memory, usando os outros 57 bits como preenchimento bits que são sempre necessários para armazenar a data de nascimento da namorada do autor do compilador. Esta implementação terá até certo valor prático: pode ser usada para executar testes em tempo de execução da portabilidade de programas C / C ++. Mas é aí que a utilidade prática dessa implementação terminaria. Não espere ver algo assim em um compilador C / C ++ “normal”.

Sim, isso depende dos dois processadores (mais especificamente, ISA, arquitetura de conjunto de instruções, por exemplo, x86 e x86-64) e compiladores, incluindo o modelo de programação. Por exemplo, em máquinas de 16 bits, sizeof (int) era de 2 bytes. Máquinas de 32 bits têm 4 bytes para int . Considerou-se int o tamanho nativo de um processador, ou seja, o tamanho do registro. No entanto, os computadores de 32 bits eram tão populares e um grande número de softwares foi criado para o modelo de programação de 32 bits. Então, seria muito confuso se o computador de 64 bits tivesse 8 bytes para int . O Linux e o Windows permanecem com 4 bytes para o int . Mas, eles diferem no tamanho de long .

Por favor, dê uma olhada no modelo de programação de 64 bits como LP64 para a maioria dos * nix e LLP64 para Windows:

Essas diferenças são realmente muito embaraçosas quando você escreve um código que deve funcionar tanto no Windows quanto no Linux. Então, estou sempre usando int32_t ou int64_t , em vez de long , via stdint.h .

Sim, seria. Eles queriam dizer “de que dependeria: o compilador ou o processador”? Nesse caso, a resposta é basicamente “ambos”. Normalmente, int não será maior que um registrador de processador (a menos que seja menor que 16 bits), mas poderia ser menor (por exemplo, um compilador de 32 bits sendo executado em um processador de 64 bits). Geralmente, no entanto, você precisará de um processador de 64 bits para executar o código com um int de 64 bits.

Com base em algumas pesquisas recentes, fiz estudos para entrevistas de firmware:

O impacto mais significativo da arquitetura de bits dos processadores, ou seja, 8bit, 16bit, 32bit, 64bit é como você precisa armazenar mais eficientemente cada byte de informação para calcular melhor as variables ​​no número mínimo de ciclos.

O tamanho do bit do seu processador informa qual o tamanho natural da palavra que a CPU é capaz de manipular em um ciclo. Uma máquina de 32 bits precisa de 2 ciclos para manipular um dobro de 64 bits se estiver alinhada corretamente na memory. A maioria dos computadores pessoais eram e ainda são 32 bits, portanto, o motivo mais provável para a afinidade típica do compilador C para inteiros de 32 bits com opções para números de ponto flutuante maiores e longos inteiros longos.

É claro que você pode computar tamanhos de variables ​​maiores. Nesse sentido, a arquitetura de bits da CPU determina como ela terá que armazenar variables ​​maiores e menores para obter a melhor eficiência possível de processamento, mas não é um fator limitante nas definições de tamanhos de bytes para ints ou chars, isso é parte de compiladores e o que é ditado por convenção ou padrões.

Eu achei este site muito útil, http://www.geeksforgeeks.org/archives/9705 , para explicar como o tamanho natural da palavra-chave do processador afeta como ele irá escolher armazenar e manipular tipos de variables ​​maiores e menores, especialmente no que diz respeito a embalagem de bits em estruturas. É preciso que você esteja ciente de como escolheu atribuir variables, pois variables ​​maiores precisam estar alinhadas na memory, de modo que elas obtenham o menor número de ciclos quando divididas pelo tamanho da palavra da CPU. Isso adicionará muito buffer / espaço vazio potencialmente desnecessário a coisas como structs se você ordenar mal a atribuição de suas variables.

A resposta simples e correta é que depende do compilador. Isso não significa que a arquitetura é irrelevante, mas o compilador lida com isso, não com seu aplicativo. Você poderia dizer com mais precisão que depende da arquitetura (de destino) do compilador, por exemplo, se seus 32 bits ou 64 bits.

Considere que você tem o aplicativo do Windows que cria um arquivo onde ele escreve um int mais outras coisas e lê de volta. O que acontece se você executar isso em janelas de 32 bits e 64 bits? O que acontece se você copiar o arquivo criado no sistema de 32 bits e abri-lo no sistema de 64 bits?

Você pode pensar que o tamanho de int será diferente em cada arquivo, mas não, eles serão os mesmos e esse é o ponto crucial da questão. Você escolhe as configurações no compilador para direcionar para arquitetura de 32 bits ou 64 bits e isso dita tudo.

Tipos de dados O tamanho depende do processador, porque o compilador quer tornar a CPU mais acessível ao próximo byte. por exemplo: se o processador é de 32 bits, o compilador não pode escolher o tamanho int como 2 bytes [que ele deveria escolher 4 bytes] porque acessar outros 2 bytes desse int (4 bytes) levará ciclo de CPU adicional que é gasto. Se o compilador escolher int como 4 bytes, a CPU pode acessar 4 bytes completos em um único disparo, o que acelera seu aplicativo.

obrigado

O tamanho do int é igual ao tamanho da palavra que depende do ISA subjacente. O processador é apenas a implementação de hardware do ISA e o compilador é apenas a implementação do lado do software do ISA. Tudo gira em torno do ISA subjacente. O ISA mais popular é o IA-32 da Intel atualmente. tem um comprimento de palavra de 32bits ou 4bytes. 4 bytes podem ser o tamanho máximo de compiladores ‘int’ (apenas int simples, não curto ou longo). baseado em IA-32, poderia usar.

o tamanho do tipo de dados depende basicamente do tipo de compilador e os compiladores são projetados com base na arquitetura dos processadores, de modo que o tipo de dados externo pode ser considerado como sendo dependente do compilador.por exemplo, o tamanho do inteiro é 2 byte no compilador 16 bit tc mas 4 bytes no compilador gcc embora eles sejam executados no mesmo processador

http://www.agner.org/optimize/calling_conventions.pdf

“3 Representação de dados” contém uma boa visão geral do que compiladores fazem com tipos integrais.

Sim, eu achei que o tamanho do int no turbo C era 2 bytes, onde como no compilador MSVC era de 4 bytes.

Basicamente, o tamanho de int é o tamanho dos registradores do processador.