JavaRush /Blogue Java /Random-PT /Código de máquina e código de bytes: que linguagem seu pr...

Código de máquina e código de bytes: que linguagem seu programa fala?

Publicado no grupo Random-PT
Aqueles que estão apenas começando a se familiarizar com Java muitas vezes ficam confusos sobre os conceitos de código de máquina e código de bytes . O que eles são? Quais são as diferenças? Em uma breve nota, tentaremos descrever suas características da forma mais simples e clara possível, a fim de encerrar este problema de uma vez por todas.
Código de máquina e código de bytes: que linguagem seu programa fala?  - 1

Código da máquina

O processador é, em essência, uma calculadora muito complexa e avançada. Possui muitos locais de memória (chamados registradores) nos quais e entre os quais várias operações matemáticas e de bytes são executadas. O código de máquina é justamente uma descrição da sequência de operações e do conjunto de dados envolvidos. Na verdade, é a única linguagem que o processador do seu computador entende.

Incompatibilidade congênita

Ao mesmo tempo, nem todos os processadores “falam” a mesma língua. Existem diferenças não apenas entre as arquiteturas CISC e RISC , mas também dentro destes "campos".

CISC (Complex Instruction Set Computing) é um conceito de design de processador caracterizado pelo seguinte conjunto de propriedades:

  • muitos comandos, com comprimentos diferentes;
  • muitos modos de endereçamento;
  • codificação de instruções complexas.
RISC (Reduced Instruction Set Computing) - um processador com um conjunto de instruções reduzido. Os comandos são do mesmo formato, curtos, com codificação simples.
As novas gerações de processadores introduzem conjuntos adicionais de instruções que são simplesmente desconhecidos dos modelos da geração anterior. Por causa disso, programas compilados para uma arquitetura (ou uma geração de processadores) não podem ser executados em outro hardware. Tudo isso nos obriga a recompilar programas para garantir que funcionem em outros computadores. No entanto, é necessário recompilar não apenas por causa dos processadores, mas também por causa das diferenças na interação dos programas e do sistema operacional. É por causa deles que é impossível executar um programa “Windows” no Linux e um programa “Linux” no Windows.

Bytecódigo

O bytecode é em muitos aspectos semelhante ao código de máquina, mas usa um conjunto de instruções não de um processador real, mas de um virtual. Além disso, pode incluir seções focadas no uso de um compilador JIT , que otimiza a execução de comandos para o processador real no qual o programa está sendo executado.
Compilação JIT (compilação Just-in-time, compilação on-the-fly) ou compilação dinâmica (tradução dinâmica) é uma tecnologia para aumentar o desempenho de sistemas de software que usam bytecode compilando o bytecode em código de máquina ou para outro formato diretamente enquanto o programa está em execução. “Oficialmente” em Java até a versão 9 existia apenas um compilador JIT. No Java 9, outro compilador apareceu e ele compila antecipadamente (AoT). Este recurso permite que classes Java sejam compiladas em código nativo antes de serem executadas em uma máquina virtual. Esse recurso foi projetado para melhorar os tempos de inicialização de aplicativos pequenos e grandes, com impacto limitado no desempenho máximo.
Para processadores CISC , algumas instruções podem ser combinadas em estruturas mais complexas suportadas pelo processador, e para RISC , ao contrário, podem ser decompostas em sequências de instruções mais simples.

Também um sistema operacional virtual

No entanto, o código de bytes não contém apenas instruções do processador. Também contém lógica de interação com um sistema operacional virtual, o que torna o comportamento da aplicação independente do sistema operacional utilizado no computador. Isso é claramente visível na JVM , onde o trabalho com chamadas de sistema e a GUI geralmente são independentes do sistema operacional no qual o programa está sendo executado. Em geral, a JVM emula o lançamento de um processo de programa, ao contrário de soluções como o Virtual Box , que criam apenas um sistema/hardware virtual.

A JVM é a única assim?

Definitivamente não. O mesmo DotNet CLI também é uma máquina virtual, usada com mais frequência em computadores que executam Windows com processadores compatíveis com x86 . Porém, existe uma implementação para outros sistemas: os aplicativos para ele devem rodar em Windows RT rodando em processadores compatíveis com ARM (RISC) , ou você pode rodá-los em Linux/OSX no ambiente Mono , que é de terceiros (e portanto (não totalmente compatível) implementação de DotNet para essas plataformas. Portanto, esta plataforma, assim como a JVM , roda em diferentes processadores e diferentes sistemas operacionais. Existem muitas outras soluções semelhantes (antigas e novas): LLVM , Flash SWF e outras. Algumas linguagens de programação possuem suas próprias máquinas virtuais. Por exemplo, o CPython compila fontes PY em arquivos PYC - código de bytes compilado que está preparado para ser executado em PVM . Ou há um exemplo muito mais antigo - Lisp pode ser compilado em arquivos FASL (Fast Load). Na verdade, eles contêm uma árvore AST construída pelo gerador a partir do código-fonte. Esses arquivos podem ser lidos e executados pelo interpretador Lisp em diversas plataformas, ou usados ​​para gerar código de máquina para a arquitetura de hardware utilizada atualmente.
Comentários
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION