Little Endian ganhou?

34

Ao ensinar recentemente sobre a batalha de Big vs. Little Endian, um aluno perguntou se havia sido resolvido, e eu percebi que não sabia. Observando o artigo da Wikipedia , parece que os pares atuais de OS / arquitetura mais populares usam Little Endian, mas o Protocolo da Internet especifica Big Endian para transferir valores numéricos em cabeçalhos de pacotes. Esse seria um bom resumo do status atual? As placas de rede ou CPUs atuais oferecem suporte de hardware para alternar a ordem dos bytes?

— Ellen Spertus
fonte

25

Eu diria que não é tanto ganho como deixou de importar. O BRAÇO que compõe basicamente todo o mercado móvel é bi-endiano (ah, a heresia!). No sentido em que o x86 basicamente "venceu" o mercado de desktop, suponho que você poderia dizer que o little endian venceu, mas acho que, dada a profundidade geral do código (superficial) e a abstração (lotes) de muitos dos aplicativos atuais, é muito menos um problema do que costumava ser. Não me lembro de endianness realmente surgindo na minha aula de Arquitetura de Computadores.

Suspeito que muitos desenvolvedores nem estejam cientes da existência ou por que é importante. Porque para a vasta (e eu digo vasta ) maioria é totalmente irrelevante para o ambiente de trabalho diário. Isso foi diferente 30 anos atrás, quando todo mundo estava codificando muito mais perto do metal, em vez de manipular arquivos de texto em uma tela de maneiras extravagantes e dramáticas.

Minha suspeita geral é que a Programação Orientada a Objetos foi o começo do fim de se preocupar com endianness, uma vez que as camadas de acesso e abstração em um bom sistema OO ocultam os detalhes da implementação do usuário. Como a implementação inclui endianness, as pessoas se acostumaram a não ser um fator explícito.

Adendo: o zxcdw mencionou a portabilidade como preocupação. No entanto, o que surgiu com uma vingança nos últimos 20 anos? Linguagens de programação criadas em máquinas virtuais. Certifique-se de que o endianness da máquina virtual possa ser importante, mas pode ser muito consistente para esse idioma até o ponto em que é basicamente um problema. Somente os implementadores de VM precisariam se preocupar com endianness do ponto de vista da portabilidade.

— Engenheiro Mundial
fonte

2

Ainda existem muitos domínios muito relevantes nos quais isso é importante, por exemplo, ao escrever qualquer forma de código portátil. De fato, o que provavelmente não importa é quando se escreve código não portátil que está vinculado a uma plataforma.

— Zxcdw 23/09/12

@zxcdw que nos leva diretamente ao exército de linguagens de máquinas virtuais por aí ... eu não tinha pensado nisso.

— World Engineer

Seu adendo não é inteiramente verdadeiro (e eu também não concordo com @zxcdw): o endianness é importante apenas na tradução entre números inteiros de vários bytes e fluxos de bytes, e se torna um problema quando é feito implicitamente e varia entre plataformas. A maioria das linguagens modernas (com base em VM ou não) alcança portabilidade fazendo com que você faça isso raramente (com números inteiros como um tipo de dados opaco) e, em seguida, possui endianness especificada independentemente da plataforma ou escolhida explicitamente pelo programador.

— Michael Borgwardt

2

@MichaelBorgwardt O ARM faz arium.com/pdf/Endianness.pdf

— World Engineer

2

@zxcdw - mesmo em assembler, você nem sempre precisa saber a ordem endian. As constantes, por exemplo, não precisam ser especificadas em um byte de cada vez. A situação é um pouco semelhante a um certo estilo de serialização em C - x & 0xFFsempre fornece o byte menos significativo, independentemente da ordem endian (supondo que seus bytes tenham 8 bits cada), porque você especificou os bits nos quais está interessado por seu valor, não sua posição relativa na memória.

— precisa saber é o seguinte

4

Endians realmente importa apenas quando você está transferindo sistemas de dados binários.

Com o avanço da velocidade do processador (e um custo muito mais baixo de armazenamento), as interfaces de dados binários estão se tornando mais raras, para que você não as observe na camada de aplicação. Você está usando um formato de transferência de texto (XML / JSON) ou uma abstração da camada de dados que cuida da tradução para você (para que você nem perceba que há uma tradução).

Mas quando você está codificando na camada de dados binários, percebe e isso é muito importante. Por exemplo, quando eu trabalhei na VERITAS (agora na Symantec), eu estava criando um software que estava sendo construído em 25 plataformas de hardware diferentes (não apenas endian grande / pequeno, existem outros tipos).

— Martin York
fonte

Meus alunos também se desenvolveram para telefones celulares e usaram computação em nuvem, para que saibam que o mundo não é PC e Mac.

— Ellen Spertus 24/09/12

@Loki - é possível serializar e desserializar sem conhecer o endian da máquina. Você realmente só precisa saber a ordem de bytes dos dados nos arquivos / fluxos / o que for. Por exemplo, (char) (x & 0xFF)em C fornece o byte menos significativo, independentemente de problemas endian, assumindo apenas que um byte tenha 8 bits. Projetei formatos de arquivos binários sem conhecer as máquinas nas quais o software seria executado - basicamente escolhi uma encomenda endian para o formato de arquivo sem se preocupar com o hardware.

— Steve314

@espertus: Com certeza é possível.

— Martin York

1

@ Steve314: Sim, claro que você pode. Quando você está trabalhando na "Camada de dados binários", pode criar qualquer esquema que queira serializar seus dados e não é difícil criar esquemas que sejam portáteis. Embora pessoalmente eu não me incomodasse em reinventar uma roda que foi construída e bem testada desde os anos 60. Procure ` h2nl e família. essa família de funções fornece uma maneira portátil (padrão) de fazer as coisas ideais para sua plataforma.

— Martin York

4

Não, ninguém ganhou. Como espécie, falhamos em padronizar a ordem em que armazenamos nossos bytes, juntamente com a direção em que escrevemos e o lado da rua em que seguimos.

Como conseqüência, qualquer pessoa que queira transferir dados entre dois sistemas diferentes em uma rede ou em um arquivo, tem apenas cerca de 50% de chance da versão inicial razoável de seu código de descarte de dados estar correta em seu ambiente e, mesmo que funcione , tem 50% de chance de trabalhar no cliente.

Para lidar com isso, você precisa procurar funções específicas da plataforma com nomes como "htonl" em cabeçalhos com nomes que obviamente remontam aos anos 70 como "arpa / inet.h", porque a situação não melhorou desde então e provavelmente nunca será .

— Andrew Wagner
fonte

10

Acontece que nós padronizamos - em vez de enviar 4 bytes para representar um número inteiro, enviamos um bloco de texto formatado com texto de cabeçalho especial, colchetes angulares, palavras-chave e uma representação ASCII desses 4 bytes. O final de recebimento analisa a formatação para obter o texto inteiro e o converte novamente em 4 bytes. Isso é chamado de progresso, me disseram :-)

— gbjbaanb

$ aptitude search xml | wc -l 677

— Andrew Wagner

1

Ainda não há consenso:

Atualmente, a maioria dos sistemas de computadores maiores (servidor / desktop / laptop) usa arquiteturas little-endian
A maioria dos computadores menores (tablets / telefones) usa uma arquitetura de processador independente de endianness, mas executa sistemas operacionais que usam ordens little-endian

Portanto, no nível do hardware, LE é muito mais comum. Mas:

A maioria das comunicações entre computadores é realizada usando protocolos que especificam ordens big-endian
Uma proporção muito grande do software mundial é executada em uma plataforma virtual que padroniza o pedido de big endian sempre que os dados são gravados no armazenamento externo.

Ambos os pedidos estarão conosco no futuro próximo.

— Jules
fonte

A maioria dos maiores sistemas (ou seja, "big iron") é tipicamente big endian. Ou seja, os chamados mini ou sistemas de mainframe (que compõem uma enorme quantidade de back-end de processamento a maioria de nós não se preocupam com.)

@jdv Mas a maioria dos maiores sistemas de computação são pequenas máquinas endian x86-64 e, aí, o desempenho é importante.

— user877329

Eu não acho que alguém possa fazer fortes afirmações de que endianness é algo mais do que conveniência por parte dos designers de arquitetura (para o que eles querem alcançar). Na época em que fiz esse comentário antigo, o ferro grande era BE. Mas isso não é porque é BE, mas porque a arquitetura é assim.