Nos tempos antigos, informações de 8 bits e computadores de 8 bits se davam bem
Houve um ASCII de 8 bits, portanto, um único byte é um único caractere e uma posição única e inteira na memória / disco
vieram então computadores de 16 bits, 32 bits e 64 bits, mas perdi o caminho
como os chars são armazenados? É um ASCII de 16/32/64 bits usado ??
e se eu tiver dados de largura de 8 bits? posso armazenar muitos caracteres em uma única posição?
por exemplo, para 32 bits, se apenas 8 bits forem usados, há 24 bits não usados?
memória / posição do disco- > 0000000 00000000 0000000 xxxxxxx
ou são 16/32/64 de memória / direção do disco ainda manter apontando para 8 bits em vez de 16/32/64-bit-words?
então 8 bits ainda estão vivos e funcionando? parecem SIM
EDITAR
Esquecendo-se do ASCII, gostaria de saber se um único endereço (dentro da memória / disco) está apontando para um único byte de 8 bits em uma plataforma de 8/16/32/64 bits
Se for mais de 8 bits, um caractere não é ASCII por definição. Os números ainda são números.
Bytes ainda são bytes. Computadores com caminhos de dados mais amplos captam mais deles ao mesmo tempo. Um sistema de 32 bits irá manipular 4 bytes de uma vez nativamente, e um computador de 64 bits usará 8 bytes.
O modo como o disco gerencia os dados é um problema separado - ele fará sua própria tarefa internamente e responderá à interface (SATA, etc.) com blocos de dados de tamanho adequado.
O tamanho do espaço de endereço é em bytes. Por exemplo, você compra um computador com 4 GB de RAM ou 3 TB de disco. Então os endereços também apontam para um único byte.
Ao endereçar mais de 8 bits, você também faz referência aos bytes seguintes. Suponha que você tenha um ponteiro para o endereço 104. Se você carregar um registrador de 64 bits, obterá os bytes 104 a 111. Se você armazenar, sobrescreve esses endereços.
Sua pergunta básica sobre como os dados de caracteres são armazenados na memória, tanto na RAM quanto no disco? Geralmente, os dados na memória de trabalho ocupam mais espaço, mas são mais fáceis de trabalhar; enquanto no disco é mais compacto, com algum tipo de codificação de caracteres . Mas há muita variação e prós e contras para eles.
Por exemplo, não é incomum que os caracteres tenham sempre dois bytes cada na memória, mas, quando armazenados em disco, levam de um a quatro bytes. Por exemplo, "ABC" na memória: 65 00 66 00 67 00; no disco: 65 66 67. Para um caractere especial conhecido como o Byte Order Mark, na memória: 255 254; no disco: 239 187 191. São caracteres Unicode, armazenados com codificação UTF-8 no disco.
(E tecnicamente falando, o ASCII é de 7 bits; ele define apenas 128 caracteres. O Unicode é um superconjunto de 16 bits do ASCII.)
É tudo um pouco mais complicado do que as respostas simples dadas até agora.
Existem 2 aspectos: a máquina e o armazenamento em massa.
Na máquina:
Depende da arquitetura de hardware.
Em um PC, o endereçamento é por byte e você pode acessar um byte (8 bits), uma palavra (16 bits), uma palavra dupla (32 bits) e uma palavra-chave (64 bits).
Em outras arquiteturas, você pode ter acesso apenas a algum outro "blob" de tamanho para o tipo de dados da máquina. Por exemplo, no TMS320C40 você pode acessar palavras de 32 bits e bytes de 8 bits são compactados nessas palavras. Você pode empacotar os bytes para dentro e para fora, mas é um processo bastante lento que requer várias instruções de máquina.
Então, nesse TMS320C40, o compilador C tem um tipo de caractere nativo que é de 32 bits!
(quando estiver programando em C, nunca ASSUME que um caractere é de 8 bits. Leia o manual do seu compilador, especialmente se estiver fazendo programação embutida).
As coisas ficam ainda mais complicadas quando o endian-ness entra em jogo, existem dois arranjos comuns: little e big endian, isso descreve como o byte é organizado para se encaixar em uma quantidade maior (normalmente o tamanho da palavra nativa). Então, por exemplo, em uma máquina de 32 bits, você pode encontrar os bytes organizados assim:
Endereço X: Byte 0, Byte 1, Byte 2, Byte 3
Endereço X + 4: Byte 4, Byte 5, Byte 6, Byte 7
OR
Endereço X: Byte 3, Byte 2, Byte 1, Byte 0
Endereço X + 4: Byte 7, Byte 6, Byte 5, Byte 4
(E fica ainda mais complexo porque os bits em um byte também têm endian).
Principalmente, esse tipo de coisa só surge como uma preocupação para os projetistas de hardware. Mas se você tem que escrever drivers de dispositivos e coisas que falam com hardware que é através de registros mapeados na memória, isso se torna um grande problema.
Um exemplo simples pode ser suficiente:
Despejar um bloco de memória no endereço X pode apresentar um fluxo de bytes:
01 02 03 04 05 06 07 08
MAS despejar esse mesmo bloco do mesmo endereço e apresentar números inteiros de 16 bits (hexadecimais) pode ser apresentado como:
0201 0403 0605 0807
E despejar novamente do mesmo endereço que os inteiros de 32 bits em hexadecimal podem ser apresentados como:
04030201 08070605
Isso causa uma grande confusão para os não iniciados, porque tudo depende do endian-ness, e o método (ordem dos bytes) usado para fazer quantidades maiores de menores.
Geralmente, linguagens de alto nível escondem esse nível de horror, mas podem ser importantes para coisas como estruturas de dados de sobreposição e, novamente, registros de controle de dispositivos mapeados pela memória.
Armazenamento em massa.
Felizmente, a vida fica mais fácil.
Pense no seu armazenamento em massa como um monte de bytes, que podem ser acessados, e a máquina cuidará magicamente de tudo. O termo comum usado é coisa de arquivos como um "fluxo", onde você começa no início e o fluxo entra. (Isso convenientemente ignora o acesso aleatório). A menor parte na qual você pode dividir o fluxo do arquivo é um byte.
Se uma máquina deseja armazenar quantidades maiores (palavras de 16 bits, etc), pode ou não fazer algum nível de transformação para obter isso nos bytes que vão para o armazenamento.
Advertências
Todos os itens acima estão relacionados a coisas subjacentes de baixo nível - bytes, palavras e assim por diante.
Os programas fazem uso disso de todas as maneiras. Então, por exemplo, você terá CHARACTERS representados por bytes se eles se encaixarem perfeitamente em ASCII simples (ou até EBCDIC para aqueles com memórias longas). Os modernos sistemas de caracteres Unicode podem usar caracteres largos (geralmente são 16 bits), mas existem muitos sistemas de codificação para unicode. A página da Wikipedia sobre Unicode é bastante instrutiva.
A convenção em C de assumir CHARACTER = BYTE é hoje em dia, equivocada e equivocada. Seu melhor para coisa de "char" é um sinônimo de "byte" - a menos que sua máquina / compilador diga o contrário (veja acima). Bons programas C geralmente definem um conjunto de tipos preferidos como "UINT8" - inteiro de 8 bits sem sinal, "SINT8" - inteiro de 8 bits assinado, e assim por diante, para que o programa escrito se torne tão independente quanto possível das peculiaridades de o compilador específico e o hardware subjacente.
Para a pergunta específica: Como os caracteres são armazenados? A resposta é: depende. Freqüentemente, caracteres ASCII que cabem em um byte são armazenados como um byte. Caracteres largos são freqüentemente armazenados como palavras de 16 bits. Mas o unicode pode implementar caracteres amplos ou um de qualquer número de sistemas de codificação, nesse caso os caracteres podem ocupar de 1 a 4 bytes, dependendo do caractere.
A RAM de hoje, muito parecida com a RAM nos anos 70, ainda é endereçável por 8 bits por vez. Então, cada endereço de memória aponta para um byte de 8 bits.
Quando as CPUs de 16 bits foram desenvolvidas, elas mantiveram a capacidade de endereçar 8 bits de uma vez para fins de velocidade e compatibilidade. Existem vários componentes de uma CPU que podem ter "bitness", a largura do registro é um deles. Mas quase todas as CPUs de 16 bits ou mais têm instrutores para acessar os 8 bits superiores ou inferiores de um registrador. Então, só porque a CPU tem tantos bits, não significa que tenha que acessar a memória ou se registrar nesse tamanho de blocos.
Então, responda suas perguntas:
são 16/32/64 direção de memória / disco ainda continua apontando para 8 bits ao invés de 16/32/64-bit-words? Sim. Uma CPU de 32 bits carregando 32 bits em um registrador de uma determinada localização memoy vai pegar 4 bytes da DRAM e colocá-la no registro.
8 bits ainda estão vivos e funcionando? Sim. O CPU 68000 da Motorola, apesar de ser um chip de 16 bits (alguns argumentariam 32 bits), tinha uma instrução chamada ADDQ (para ADD QUICK) que pegaria um operando de um registrador ou memória e o adicionaria a um 8-bit. valor realmente codificado na própria instrução. Eu não sei muito sobre o assembly x86, mas tenho certeza que existem instruções similares que restringem a 8 bits para velocidade.
CPUs de 64 bits são capazes de endereçar dados de 8 bits.
Um único char é armazenado em um único byte.
Tags hard-drive storage memory