A Assembléia ainda é relevante? [fechadas]

Existem grandes diferenças entre a linguagem assembly e as linguagens de nível superior quando se trata de codificar e / ou gerenciar projetos? Obviamente, são necessárias mais instruções na linguagem assembly para executar uma operação específica do que na maioria dos outros idiomas, mas existem diferenças que afetam a maneira como um projeto precisa (ou deveria) ser executado com base na linguagem assembly direcionada (especificamente na linguagem assembly x86 / x64) ?

Na medida em que existem diferenças entre a linguagem assembly e outras línguas, parece razoável supor que pelo menos algumas delas sejam vantagens para as outras línguas. Alguém pode apontar desvantagens específicas da linguagem assembly e maneiras de mitigar essas desvantagens?

Um exemplo específico seria a disponibilidade da equipe. Alguém já teve problemas para encontrar programadores experientes em linguagem assembly e, em caso afirmativo, que medidas podem ser tomadas para atenuar esse problema?

Sim - mas não com frequência.

Em certo sentido, o assembly é realmente apenas um proxy para a linguagem de máquina; portanto, é claro que você pode fazer qualquer coisa no assembly que poderia com uma linguagem de nível superior.

O oposto nem sempre é o caso. Por exemplo, há alguns anos atrás, trabalhei em uma CPU ARM que possuía alguns opcodes descolados para alterar os estados gráficos que só podiam ser usados ​​no modo kernel. Eles não teriam equivalente direto em uma linguagem de nível superior, e tenho certeza de que a função no driver do kernel Linux para alterar esses estados incluía algum assembly.

Em microprocessadores nos anos 80 e meados dos anos 90, se você tivesse algum código necessário para executar muito rápido, muitas vezes o escrevia em assembly, porque um humano qualificado poderia escrever facilmente um assembly mais otimizado do que a maioria dos C compiladores poderiam gerar. Alguns dos primeiros programas para Mac foram escritos inteiramente em montagem e foram surpreendentemente rápidos para a época. Mesmo sem escrever todo o programa em montagem, eu certamente fiz minha parte na otimização de loops internos em C via montagem embutida.

Mas as coisas começaram a mudar em meados dos anos 90. As CPUs começaram a incluir recursos como pipelining e previsão de ramificação, portanto, a ordem de instruções mais eficiente nem sempre era óbvia para o ser humano. Pior que isso, a ordem mais eficiente variava entre as CPUs da mesma família; por exemplo, os compiladores PowerPC geralmente ofereciam switches alvo para as séries G3, G4 e G5. O mesmo código de objeto seria executado em todos eles, mas seria executado em uma dessas séries com mais eficiência.

Desde então, a ordem das instruções se tornou progressivamente mais complicada, especialmente nas CPUs com arquitetura mais complexa, como x86, PowerPC e SPARC. (Eu acredito que o ARM ainda é bastante simples dessa maneira.) Um grande fator adicionado é o tamanho do código - o código que usa mais ciclos da CPU, mas pode permanecer no cache da CPU, geralmente é executado muito mais rápido que o código que usa menos ciclos da CPU, mas dispara a busca lenta da memória . Os principais compiladores modernos podem otimizar muito mais o código nessas CPUs do que os humanos razoavelmente.

Não encontrei um bom motivo para escrever uma montagem em pelo menos 15 anos. Eu acho que em 2011, os principais usos para montagem seriam:

• Para ler despejos de desmontagem durante a depuração, o que ocasionalmente faço até hoje.
• Lidando com recursos de CPU não padrão, como o modo gráfico descolado.
• Escrita do compilador - fornece um formato intermediário, legível por humanos, para traduzir idiomas de nível superior.

Tente programar um microcontrolador para um "pequeno dispositivo incorporado" - um controle remoto de alarme de carro, um monitor de bateria de telefone, um controlador de teclado, um regulador de velocidade do ventilador, sem usar a montagem.

Enquanto a borda se move, sempre há espaço para montagem.

Há 15 anos, seu odômetro de bicicleta era mecânico, um forno de microondas estava em circuitos analógicos, o controle remoto da TV estava em circuitos digitais, o sintonizador de TV via satélite estava escrito em montagem, o firmware do telefone estava em C e o miniaplicativo de computador em Java.

Há 7 anos, um forno de microondas estava em circuitos digitais, um controle remoto de TV era escrito em montagem, o decodificador de TV era escrito em C, o telefone executava a interface do usuário baseada em Java.

Atualmente, um odômetro de bicicleta está em um circuito digital, um forno de microondas recebe firmware na montagem, um controle remoto de TV possui firmware em C, o decodificador de TV executa Java, seu telefone tem Linux.

Quer apostar nos próximos 7 anos? À medida que mais tecnologia obtém linguagens de controle mais avançadas, o assembly ganha novas bases, e continuará obtendo-as. Veja o que é feito hoje com circuitos mecânicos ou analógicos. Você pode apostar na montagem daqui a alguns anos. O seu interruptor de luz? Sua torneira de água? Sua chaleira? Sua escova de dentes?

Sempre haverá um novo dispositivo, aparelho, brinquedo, item de vida comum a ser programado na montagem.

Estou baseando isso principalmente nos montadores que usei - principalmente MASM, NASM e (em menor grau) TASM. Algumas das versões posteriores do TASM tinham (possuem?) Alguns recursos para oferecer suporte ao OO, mas eu não as usei muito e não estou tentando comentá-las.

Primeiro: a maioria das línguas mudou para uma estrutura que é pelo menos um pouco parecida com uma árvore. Seja orientado a objeto, baseado em objeto ou exatamente o que, há um pouco definido sobre os relacionamentos entre diferentes partes de um sistema. Há também bastante para "proteger" uma parte de um sistema de "intromissão" acidental, mas outras (mesmo que a proteção possa geralmente ser ignorada, se você quiser). Por outro lado, a linguagem assembly é relativamente "plana" - a maioria dos relacionamentos entre o código (e os dados) em diferentes partes do sistema é estabelecida principalmente pela documentação e, em menor grau, pelas convenções de nomenclatura.

O resultado disso é que muitas vezes é muito mais fácil associar códigos com muito mais rigor do que seria ideal. Os requisitos que levaram à escolha da linguagem assembly (desempenho superior, tamanho menor etc.) geralmente recompensam isso também - ignorando as interfaces aprovadas e você pode obter código menor e mais rápido (embora geralmente não seja muito) melhor em qualquer dimensão). A linguagem e as próprias ferramentas fazem muito menos para restringir o que você faz (bom ou ruim), o que impõe uma carga muito maior aos gerentes para evitar problemas. Eu não diria que é qualitativamente diferente, mas quantitativamente é - ou seja, o gerenciamento precisa trabalhar para evitar problemas de qualquer maneira, mas no caso da linguagem assembly geralmente é necessário mais (e muitas vezes mais rigoroso) diretrizes sobre o que é ou não é ' t aceitável.

Atenuar isso é em grande parte uma questão de diretrizes mais cuidadosas, mais orientações de pessoal mais experiente e convenções de nomes mais específicas e cuidadosamente aplicadas.

O pessoal é um problema. Os problemas que encontrei, no entanto, não eram principalmente os que eu esperava. Encontrar caras com um pouco de personalidade de "lutador de atleta" que estavam felizes em entrar no código da linguagem assembly era bastante fácil. A maioria fez um trabalho bastante razoável, apesar da quase total falta de experiência anterior no uso da linguagem assembly.

A dificuldade que encontrei foi em encontrar mais funcionários seniores - pessoas que pudessem manter o projeto sob pelo menos alguma aparência de controle e não estavam completamente acostumadas a idiomas que forneceriam (e aplicariam amplamente) as diretrizes necessárias para manter o código razoavelmente sustentável e compreensível.

Olhando para trás, eu posso ter causado / causado alguns dos maiores problemas a esse respeito. Eu posso ver duas fontes de problemas da minha parte. Primeiro, no momento em que estou pensando no projeto, eu já estava codificando principalmente em linguagens de nível superior por um bom tempo e usando apenas a linguagem assemblycomo último recurso. Como tal, quando o usei, quase todos os truques possíveis para obter desempenho não eram apenas jogos justos, mas esperados. Segundo, quando eu havia trabalhado em alguns sistemas escritos inteiramente (ou principalmente) em linguagem assembly, ele estava sob alguns gerentes de projetos com punho de ferro. Na época, eu era relativamente jovem e, francamente, se ressentia da maneira como eles administravam as coisas, então tendiam a fazer o oposto. Em retrospecto, o que eles estavam fazendo era realmente importante, e não feito apenas porque eram velhos e inflexíveis (o que, tenho certeza, foi como vi as coisas na época).

na minha opinião, a montagem como plataforma de desenvolvimento pode não ser relevante para o uso diário. o principal motivo dessa opinião pode ser porque a quantidade de energia computacional removida de um determinado processo versus a quantidade de tempo de desenvolvimento necessário para otimizar o mesmo processo geralmente não vale o tempo e a energia (existe um termo específico para isso .. soa como homem / hora ou algo assim .. por favor edite se você sabe do que falo ..) existem as óbvias exceções mencionadas acima, mas no que diz respeito à programação principal, o assembly não é usado com freqüência.

isto dito ... o conjunto ainda é relevante hoje em dia, quando se aprende programação no contexto dos estudos de engenharia de software, ensina como é e se comporta uma linguagem de programação de baixo nível. Eu continuarei e darei o exemplo do que usamos nas aulas hoje em dia. usamos o assembly pep / 8 desenvolvido pela Stanley Warford (Pepperdine University EUA) e seu software de código aberto fornecido aqui . usado principalmente porque virtualiza a CPU e mostra o conteúdo da memória enquanto percorre o código enquanto está em execução (bastante útil para aprender, depurar).

Portanto, dependendo do seu uso, o conjunto pode ou não ser relevante na minha opinião.

Acho que você está perguntando "os caminhões ainda são relevantes se tivermos carros?". Quero dizer, a montagem tem uma gama muito ampla de aplicações, mas não tão ampla quanto a programação de alto nível, da mesma maneira que há muito menos caminhões do que carros.

Em campos como otimização de algoritmos, você pode usar diretamente os registros do processador para melhorar os algoritmos de processamento de imagens / vídeo.

Em campos como criptografia, você pode usá-lo da mesma maneira.

Em novos processadores com novas arquiteturas (lembre-se de quando o microprocessador Cell foi lançado), eles precisavam escrever carregadores de inicialização e assim por diante na montagem (e também com processadores antigos, mas os processadores usados ​​há muito tempo têm um terreno muito estável e são difíceis de melhorar isto).

E muitos outros exemplos podem ser dados, portanto, depende do campo em que sua empresa está focada; se sua empresa é dedicada ao desenvolvimento web / móvel, é muito provável que você não precise, mas se sua empresa estiver focada em microcontroladores, sistemas embarcados etc. é bastante provável que você precise.

E a disponibilidade da equipe depende, acho que, se você perguntar na Intel, Qualcomm, ... eles devem ter uma grande lista de programadores de montagem (é como se você perguntasse em seu local de trabalho "quantos motoristas de caminhão estão por aqui?" pense muito, mas isso não significa que não haja outros lugares. O que acontece se você perguntar "quantos motoristas há por aqui?").

Se você realmente quer saber por que aprender montagem é a melhor aposta. Aqui estão as razões.

1. Não há necessidade de aprender montagem, se você vai fazer programação em Visual Basic e coisas do MS.
2. Não há necessidade de aprender montagem, se você não precisar criar dispositivos sérios de microcontrolador.
3. Não há necessidade de aprender montagem, se você tiver um espaço de memória à sua disposição enquanto trabalha no microcontrolador (deus ajuda você a fazer a interface da memória com o microcontrolador)
4. Não há necessidade de aprender montagem, se você não quer poder divino sobre o seu microcontrolador / microprocessador.
5. Não conhecer a montagem é como conhecer o iceberg. Você pode ver 25% da capacidade da sua e do seu micros e 75% nunca saberá ou entenderá
6. Tente executar o Kolibris OS completamente escrito em Assembly !!! Você já viu um sistema operacional inicializado em menos de 5 segundos e o aplicativo começar a funcionar com 1 segundo de clique do mouse.
7. Os compiladores modernos têm funções de propósito geral no back-end e, portanto, o código final gerado seria heafty comparado ao Assembly.

Assembléia é como a Natasha Romanoff dos Vingadores. É um charme e magia. Primeiro, ele vai te morder, mas confie em mim, você nunca esquecerá o sabor.