JavaRush /Java Blog /Random-IT /Codice macchina e codice byte: che lingua parla il tuo pr...

Codice macchina e codice byte: che lingua parla il tuo programma?

Pubblicato nel gruppo Random-IT
Coloro che hanno appena iniziato a familiarizzare con Java spesso si confondono sui concetti di codice macchina e codice byte . Quali sono? Quali sono le differenze? In una breve nota cercheremo di descriverne le caratteristiche nel modo più semplice e chiaro possibile in modo da chiudere una volta per tutte la questione.
Codice macchina e codice byte: che lingua parla il tuo programma?  -1

Codice macchina

Il processore è, in sostanza, un calcolatore molto complesso e avanzato. Ha molte posizioni di memoria (chiamate registri) su e tra le quali vengono eseguite varie operazioni matematiche e sui byte. Il codice macchina è precisamente una descrizione della sequenza di operazioni e dell'insieme di dati coinvolti. In effetti, è l'unica lingua che il processore del tuo computer capisce.

Incompatibilità congenita

Allo stesso tempo, non tutti i processori “parlano” la stessa lingua. Esistono differenze non solo tra le architetture CISC e RISC , ma anche all'interno di questi “campi”.

CISC (Complex Instruction Set Computing) è un concetto di progettazione del processore caratterizzato dal seguente insieme di proprietà:

  • molti comandi, di diversa lunghezza;
  • molte modalità di indirizzamento;
  • codifica di istruzioni complesse.
RISC (Reduced Instruction Set Computing) - un processore con un set di istruzioni ridotto. I comandi hanno lo stesso formato, brevi, con codifica semplice.
Le nuove generazioni di processori introducono set aggiuntivi di istruzioni semplicemente sconosciute ai modelli della generazione precedente. Per questo motivo, i programmi compilati per un'architettura (o una generazione di processori) non possono essere eseguiti su altro hardware. Tutto ciò ci costringe a ricompilare i programmi per garantire che funzionino su altri computer. Tuttavia, è necessario ricompilare non solo a causa dei processori, ma anche a causa delle differenze nell'interazione tra programmi e sistema operativo. È a causa loro che è impossibile eseguire un programma “Windows” sotto Linux e un programma “Linux” sotto Windows.

Codice byte

Il bytecode è per molti versi simile al codice macchina, solo che utilizza una serie di istruzioni non da un processore reale, ma da uno virtuale. Inoltre, può includere sezioni incentrate sull'uso di un compilatore JIT , che ottimizza l'esecuzione dei comandi per il processore reale su cui è in esecuzione il programma.
La compilazione JIT (compilazione just-in-time, compilazione al volo) o compilazione dinamica (traduzione dinamica) è una tecnologia per aumentare le prestazioni dei sistemi software che utilizzano il bytecode compilando direttamente il bytecode in codice macchina o in un altro formato mentre il programma è in esecuzione. “Ufficialmente” in Java fino alla versione 9 esisteva solo un compilatore JIT. In Java 9 è apparso un altro compilatore che compila in anticipo (AoT). Questa funzionalità consente di compilare le classi Java in codice nativo prima di eseguirle su una macchina virtuale. Questa funzionalità è progettata per migliorare i tempi di avvio sia per le applicazioni piccole che per quelle grandi, con un impatto limitato sulle prestazioni di picco.
Per i processori CISC alcune istruzioni possono essere combinate in strutture più complesse supportate dal processore, mentre per RISC , al contrario, possono essere scomposte in sequenze di istruzioni più semplici.

Anche un sistema operativo virtuale

Tuttavia, il codice byte non contiene solo le istruzioni del processore. Contiene inoltre la logica per interagire con un sistema operativo virtuale, che rende il comportamento dell'applicazione indipendente dal sistema operativo utilizzato sul computer. Ciò è chiaramente visibile nella JVM , dove il lavoro con le chiamate di sistema e la GUI sono spesso indipendenti dal sistema operativo su cui è in esecuzione il programma. In generale, la JVM emula l'avvio di un processo di programma, a differenza di soluzioni come Virtual Box , che creano solo un sistema/hardware virtuale.

JVM è l'unico così?

Sicuramente no. La stessa CLI DotNet è anche una macchina virtuale, che viene spesso utilizzata su computer che eseguono Windows con processori compatibili x86. Tuttavia, esiste un'implementazione per altri sistemi: le relative applicazioni devono essere eseguite su Windows RT con processori compatibili ARM (RISC) , oppure è possibile eseguirle su Linux/OSX nell'ambiente Mono , che è di terze parti (e quindi non completamente compatibile) implementazione di DotNet per queste piattaforme. Quindi questa piattaforma, come la JVM , funziona su diversi processori e diversi sistemi operativi. Esistono molte altre soluzioni simili (sia vecchie che nuove): LLVM , Flash SWF e altre. Alcuni linguaggi di programmazione hanno le proprie macchine virtuali. Ad esempio, CPython compila i sorgenti PY in file PYC : codice byte compilato pronto per essere eseguito in PVM . Oppure c'è un esempio molto più vecchio: Lisp può essere compilato in file FASL (Fast Load). Contengono infatti un albero AST costruito dal generatore a partire dal codice sorgente. Questi file possono essere letti ed eseguiti dall'interprete Lisp su varie piattaforme o utilizzati per generare codice macchina per l'architettura hardware attualmente utilizzata.
Commenti
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION