bytes e suas interpretações

Houve época em que, ao programar C#, sempre me irritava ver a notação byte -- me parecia estúpido ter um tipo na linguagem de programação chamado byte.

Li hoje em um manual da Intel:

"Although bytes, words, and doublewords are fundamental data types, some instructions support additional interpretations of these data types to allow operations to beperformed on numeric data types (signed and unsigned integers, and floating-point numbers)."

Hoje, programando em C++, me irrita que não exista uma distinção entre char-que-é-sequência-opaca-de-bits, char-que-é-número-inteiro e char-que-é-elemento-alfabético.

O texto do manual é interessante; para a máquina, realmente existe apenas o byte e suas variantes como padrões de bits; o que quer que você faça de interessante com esse byte implica uma interpretação desse byte.

A máquina é untyped; não existe mecanismo formal pelo qual se possa deduzir que uma interpretação para este byte é correta ou incorreta. Dependendo de quem você é, isso pode parecer ótimo ou absurdo.

As razões porque isso é ótimo são boas, mas diminuiriam muito com algumas poucas extensões do C++. Programadores de aritmética com poucos recursos computacionais aprendem rapidamente, por exemplo, que a máquina pode computar muito rapidamente produto e divisão por 2 sem usar as instruções de produto e divisão de inteiros -- usando as instruções de shift de sequências de bytes. Esses programadores podem argumentar que essa é a vantagem da programação untyped.

Felizmente, podemos pensar de trás pra frente; aceitando como axioma que a memória representa sempre bits, então devem haver implementações ótimas para produto_por_2 e quociente_por_2 -- assim como é_par e é_negativo. Isso sugere que uma linguagem de programação com esses operadores nativos para números inteiros satisfaz as necessidades do programador acima -- diminuindo drasticamente a necessidade de permitir shifts em objetos do tipo inteiro.

Essa idéia me vem do "Elements of Programming", de Stepanov e McJones; no livro eles discutem a idéia de "base computacional" de uma estrutura de dados. Quando aritmética inteira é implementada em uma máquina binária, produto_por_2, quociente_por_2, é_par e é_negativo devem fazer parte da base computacional dos tipos inteiros -- simplesmente por serem especialmente rápidas.

(No livro, eles não estudam representações de números reais; alguém se habilita a compor uma base computacional para números reais representados como em IEEE 754?)

[Editado!]

Acho, além disso, interessante a definição de certos tipos de dados inúteis no manual da Intel, como bit field e string. Essas definições parecem mais sugestões de uso que definições, já que nem um bit field nem um string é mais que um ou mais bytes contíguos.

Me parece que essas definições apóiam a definição posterior de operações extendidas ou especializadas sobre bytes, como referências a bits individuais ou cópia otimizada de bytes contíguos. É claro que essas são, ainda, operações simples sobre sequências de bits, e não demandam interpretação especial.