Conhecido por todos é aquele A linguagem Assembler é a mais rápida por alguns problemas e por este motivo é o mais utilizado no kernel dos diferentes sistemas operacionais e o mesmo acontece para projetos em tempo real onde se utiliza eletrônica avançada. O problema vem depois, quando esse código precisa ser mantido e não é, e portanto No caso do kernel Linux, os desenvolvedores optaram por traduzir esse código Assembler para C.
C é a linguagem de programação Linux mais representativa (na verdade, de todas as plataformas * nix), foi desenvolvido por Dennis Ritchie e Ken Thompson em 1972, era feito em um sistema Unix PDP-11 e fazia parte do Unix versão 2. Devido ao seu alto desempenho e portabilidade, passou a ser cada vez mais utilizado na implementação de sistemas operacionais e por isso Linus Torvalds Ele o usou em seu projeto quando, em 1990, estava procurando uma alternativa livre e aberta ao Minix.
Claro, apesar de tantos pontos fortes, Assembler tem algumas vantagens sobre C como mencionamos no início, então esta decisão surpreendeu, mas de acordo com o que comentários Andy Lutomirsky nas listas de discussão do kernel, seu trabalho está bem encaminhado e Kernel do Linux 4.1 será o primeiro a incorporar esta reescrita do código-fonte do Assembler para C. Especificamente, tudo relacionado a saídas para o modo usuário, que atualmente consiste em uma mistura de código dessas duas linguagens de programação, mas que, dada a sua baixa manutenção, é cada vez mais complicado na hora de atualizar.
É esse o código em Assembler Faz muito tempo que não é atualizado e isso significa que os novos desenvolvedores não estão totalmente esclarecidos sobre o seu funcionamento e, o que é pior, não seria fácil atualizá-lo. Assim, em vez de tentar alguma mudança parcial, eles optaram por começar a mudar todas as rotinas Assembler para C e, pessoalmente, acho que, embora alguma velocidade de execução possa ser perdida (que pode ser mínima se o código C new for eficiente) código novo e claro é sempre preferível a tê-lo desatualizado e com quase zero possibilidades de atualização porque não se compreende bem como foi implementado.
Em primeiro lugar é ENSAMBLADOR, em espanhol.
Em segundo lugar, toda linguagem deve ser COMPILADA (ou interpretada), então a qualidade do resultado depende do COMPILADOR (ou do intérprete)
Como o compilador C melhorou muito e o montador muito pouco (porque já era muito bom), hoje em dia a diferença de um programa compilado escrito em C em relação ao mesmo escrito em assembler é desprezível ou inexistente (antes não foi).
Mesmo a diferença entre programas compilados (C e outros) e interpretados (Java e outros) também foi bastante minimizada.
Sendo muito mais fácil manter C do que montador, é uma decisão muito sensata fazer essas mudanças no kernel, ao fazer uma análise de custo-benefício, fraquezas, ameaças, pontos fortes e oportunidades ou qualquer outra que funcione.
para a tomada de decisão.
A Miguel Mayol Tur: Em primeiro lugar, todo programador que se diz ASSEMBLER, entende inglês. Os outros usam Visual Basic e se autodenominam programadores. Que vergonha. E em segundo lugar o Assembler NÃO COMPILA. O que os programas que controlam isso fazem é converter mnemônicos em bytes diretamente. Programar em Assembler é falar com a máquina na mesma linguagem, mas para tornar um pouco mais fácil, são usados mnemônicos em vez de escrever diretamente os bytes correspondentes. Existe uma correspondência um a um entre um conjunto de bytes e uma instrução em Assembler. Mas isso, é claro, só um verdadeiro programador sabe, um daqueles que dizem ASSEMBLER. Conseqüentemente, não há melhorias no "conversor" de assembler para opcodes porque o programador é o encarregado de fazer essa melhoria. Compiladores C (e outras linguagens) traduzem instruções em representações macro pré-estabelecidas de assembler (ou código de máquina) e as melhorias são dadas pela forma como essas conversões são.
Por que usar C? Porque é mais fácil revisar e manter algo que seja mais legível. A maioria das pessoas não entende diretamente os opcodes ou mnemônicos do montador. Simples assim.
Nem vou me preocupar em falar sobre Java, que embora tenha sido imposto como padrão há muito tempo, agora é detestado por quem entende de código.
Mas não acredite em mim, pergunte ao Google se o que eu disse aqui é falso.
lembranças
Olá Chigüire, meus olhos caem do rosto pensando que você não consegue escrever em espanhol sem usar termos de origem anglo-saxônica: diz-se «montador».
Claro, em uma coisa eu concordo com você, é melhor não falar sobre java porque para dizer bobagem é melhor deixar. Eu tinha um amigo que era igual a você, mas carpinteiro (não programador experiente) e ele dizia que o melhor era o serrote e as outras ferramentas, sem falar que até apertava os parafusos com ele. Que exemplo a seguir!
O idioma inglês está sempre na raiz de todos os termos computacionais. É assim que as coisas são, mesmo que nós, falantes de espanhol, não queiramos. Adicione a isso que existem termos que não podem ser traduzidos como "bit", "byte", "unix", "linux", "DOS" e muitos outros. E existem alguns que PODERIAM ser traduzidos, mas não existe tal coisa como "CMOS", "CSS", "RAM" porque existem algumas iniciais que não têm nada a ver com tecnologia e ainda por cima nem existem em Google. Não vale a pena traduzir quando a mensagem produzida é ilegível. Conclusão: É preferível para questões técnicas ou computacionais usar termos técnicos em inglês. Pelo mesmo motivo: prefiro escrever que utilizo "windows" para dizer que utilizo o sistema operacional "windows". E prefiro falar sobre CSS e que uso type = »text / css do que tentar dizer que utilizo« folhas de estilo com tipo igual a folhas de estilo de texto diagonal ». Saúde.
Os programas escritos em uma linguagem assembly são sempre compilados, nunca interpretados. No entanto, não há nada de errado em usar o espanhol em vez do espanglês. Nomes próprios nunca são traduzidos, mas os termos técnicos são traduzidos quando não são siglas populares. De qualquer forma, todos podem falar o que quiserem enquanto ainda podemos entender.