Vamos lá: Um "bit" é a menor porção de informação processável. Até aí morreu Nero.

Um "byte", por sua vez, é um conjunto de 8 bits. Apenas oito.

Alguma confusão a esse respeito parece que começou a crescer quando a IBM lançou os primeiros PCs, que tinham a capacidade de ler dois blocos de 8 bits de cada vez.

É fácil deduzir: 8 + 8 = 16!

Assim também é fácil chegar-se à errônea conclusão de que os PCs trabalhavam com um "byte de 16 bits". E modernamente, quando são acessados 64 bits por vez, há quem ainda pense que o tamanho do byte tenha crescido.

Não. Apenas podem ser acessados mais e mais bits em um só "pacote", em um só "conjunto". 16, 32, 64, 128, e assim por diante.

Isso resulta em economia de espaço físico e maior velocidade de processamento.

Mas o bom e velho byte continua com seus 8 bits, até que um dia (quem sabe?) seja mudada radicalmente a arquitetura do PC, bem como a arquitetura da memória.

Um byte pode conter comandos, dados ou um conjunto de flags (sinaleiras).

Para entendermos melhor o funcionamento de um byte (no tocante às flags), consideremos as seguintes posições, da direita para a esquerda:

• Bit 0 (flag C) : "vai um" ou "vem um" nas operações aritméticas;
• Bit 1 (flag N) : utilizada em operações binárias;
• Bit 2 (flag P/V) : Paridade e overflow;
• Bit 3 (utilização não definida);
• Bit 4 (flag H) : também utilizada em operações binárias;
• Bit 5 (utilização não definida);
• Bit 6 (flag Z) : Flag correspondente ao valor zero;
• Bit 7 (flag S) : Sinal lógico "1" ou "0" (é uma cópia do bit anterior).

A explicação acima é apenas superficial, só para "dar um gostinho". Não vamos entrar em detalhes, pois isso daria um livro. Isso aí é coisa para os assembleiros de coração...

O importante é que o sistema vai lendo e interpretando byte a byte.

Se na primeira posição de um byte (bit 0) houver algo diferente de uma flag, então trata-se de comandos ou dados, e a leitura prosseguirá.

Os comandos são facilmente reconhecidos como tal, pois apenas em poucas ocasiões poderiam ser confundidos visualmente com dados.

E apenas NÓS humanos fazemos esse tipo de confusão, já que o PC não se confunde jamais.

Sendo necessário, cada byte é completado até a oitava posição seja com espaços (ascii "20", em caso de dados) ou com o sinal NOP ("no operation", código ascii = "00" em caso de comandos).

Assim, o "foco da atenção" do PC estará sempre na primeira posição da cada byte. É esse bit 0 que irá determinar as ações do sistema operacional.

Para o PC é ESSE o pulo do gato.

Como o conjunto de bits não aumentou, e vai somente até o bit 7, os sistemas operacionais para o IBM-PC continuam lendo de oito em oito bits, mesmo que em grandes conjuntos. E vão vivendo felizes para sempre.

Mas pelamordedeus: O Bill Gates não inventou o tal de "byte de 32 bits" !!!...

Não paguem mico!

[1] Comentário enviado por albfneto em 25/11/2008 - 11:43h:

Taí, Gostei Teixeira, Dica básica e teórica. Muito Legal!

[2] Comentário enviado por edupersoft em 25/11/2008 - 12:00h:

Teixeira, você diz:

"....Mas o bom e velho byte continua com seus 8 bits, até que um dia (quem sabe?) seja mudada radicalmente a arquitetura do PC, bem como a arquitetura da memória.... "

Quando comecei a estudar computação, não existia PC e na primeira aula no primeiro dia, aprendi o que era bit e o que era byte, muito antes disso os cartões perfurados representavam uma linha, com 80 colunas e a perfuração acontecia em posições específicas, cada um posição era um bit, haviam oito posições, 1 bytes, não é não? (não vem falar que isso não é do seu tempo, rs).

Como a arquitetura do PC poderia influenciar no conceito do que é um byte?

[3] Comentário enviado por killerbean em 25/11/2008 - 23:08h:

Boa dica :)
Outra coisa interessante de se comentar entre bits e bytes é como se faz contagem de MB GB , etc., e como as empresas de HD, CD, fazem erroneamente essa contagem.
por exemplo, um MB(megabyte) são 2^10 (2 elevado a 10) byte = 1024bytes. um GB são 1024 MB e por ai vai.
agora as hd vem contando um MB como 1000bytes (24bytes a menos), um GB como 1000MB e por ai vai tb. é por isso que uma hd de 500GB tem uns 476GB na verdade. Acompanhe as contas:
(pela contgem deles): 500GB=500000MB=500000000bytes
certo, a hd tem na verdade 500000000bytes (dificil ler né? agora transformando para a contagem do computador ): 500000000bytes/1024 = 488281.25MB = 476.8 GB . pronto, ai está o tamanho real da hd. isso tb acontece com cd's e dvd's. o K3B até explica isso na hora de gravar..
triste é que isso acontece na maioria dos dispositivos de armazenamento, e é somente para parecer que tem mais.

[4] Comentário enviado por Teixeira em 26/11/2008 - 20:59h:

Em primeiro lugar gostaria de agradecer pelos comentários de todos, e pedir desculpas por não haver respondido de imediato.

É que o "fly back" (bumbum-de-mosca) do meu monitor resolveu pifar antes das 6 da manhã e eu fiquei sem poder dar uma olhadela durante o dia inteiro.

(Agora estou com um valente monitor Goldstar p&b de 12").
Mas vamos lá:

albfneto, muito obrigado pela sua avaliação.
A gente faz o que pode, e de vez em quando acerta...

killerbean, realmente ocorre esse tipo de coisas.
Antigamente quando as firmas vendiam seus computadores, era comum dizerem que eles processavam "tantos milhões de informações", isso de acordo com a quantidade de memória RAM.
Dessa forma, parecia que cada byte era "uma informação".
Uma afirmação vaga, porém muito tendenciosa e bastante conveniente... para eles!

edupersoft, foi exatamente pelos motivos alegados por você, que me dispus a escrever essa dica.
E acho terrível que em um primeiro dia de aula, quando estamos mais entusiasmados, sejam-nos oferecidos conceitos errôneos.

O cartão perfurável não tem uma analogia direta ao tamanho de UM byte.

Se você prestar atenção, digamos, num programa em Cobol, os primeiros bits de cada cartão são para identificação do programa, os seguintes para uma numeração sequencial de cada cartão, e somente a partir daí começam as informações que realmente fazem parte do programa em si.

Depois do cartão perfurável de 80 colunas, veio um outro de 96 colunas, muito mais econômico, pois com menos de 1/3 do tamanho original, ainda cabia um pouco mais de informação.

A Burroughs (atual Unisys) usava também "edge cards" que eram cartões sanfonáveis com capacidade para 96 perfurações cada.
Eu trabalhei com esses "edge cards" e com os cartões de 96 colunas.

Mas pelo que foi dito até agora, creio que não ficou devidamente esclarecido o tamanho do byte.

Pois bem. O byte era também chamado de "palavra de memória".

O minicomputador que eu programava tinha 16kb de memória (de ferrita!!!), dois quais apenas 2kb ficavam livres para os sistemas do usuários, e dos quais apenas 512 "palavras de memória" (leia-se "bytes") ficavam então disponíveis para o coitado do programador.

Meu primeiro sistema de folha de pagamento utilizava cada um desses parcos 512 bytes para que pudesse funcionar.

E o sistema de estoque usava o conceito de "memória compartilhada", onde metade do byte era para controlar um ítem de produto e a outra metade para outro ítem.
Fazer um programa desse tipo somente é possível através do Assembly (ou LM), porque temos de contornar habilmente o bit n. 7 (que é o Shift Out), ou seja, em operações numéricas é ele quem "controla" aquele byte específico.
Isso implica em conhecermos cada bit do byte para podermos fazer um endereçamento correto. Tudo isso era feito por indexação (através de apenas 4 "index registers" que eram usados individual e especificamente).
Dessa forma, se o programador errasse o "step" os resultados seriam catastróficos...

Voltando ao cartão perfurável (ou "cartão perfurado", se preferir), ele tem a capacidade de registrar a informação correspondente a 10 bytes (sendo de 80 colunas) ou de 12 bytes (sendo de 96 colunas) ou ainda, sendo um "edge card", sua capacidade seria teoricamente infinita - porém limitada pelo tamanho da memória.

Caso não esteja ainda convencido, consulte qualquer livro sobre linguagem Assembly ou linguagem de máquina.
Qualquer Assembly, para qualquer processador.

Um grande abraço a todos.