Mašinski kod vs. bajtkod: stvarne razlike i kako su povezane

Kada programirate u Javi, Pythonu, C# ili bilo kojem drugom modernom jeziku, kod koji pišete nije ono što procesor zapravo izvršava. Između izvorni kod čitljiv ljudima i jedinice i nule koje CPU razumije Postoji nekoliko slojeva prevođenja, optimizacije, pa čak i sigurnosne provjere koji često ostaju nezapaženi ako ostanete samo u editoru.

Veliki dio te „magije“ oslanja se na dva ključna koncepta: mašinski kod (mašinski kod) i bajtkod (ili međukod)Razumijevanje šta je svaki od njih, kako se odnose na JVM, .NET CLR ili Python interpreter, te koliko slojeva zapravo postoji između vašeg izvornog koda i hardvera, uveliko pomaže u donošenju odluka o performansama, prenosivosti i softverskoj arhitekturi.

Mašinski kod: instrukcije koje CPU razumije

El Mašinski kod je najniža reprezentacija softveraSastoji se isključivo od bitova (0 i 1) organiziranih u instrukcije koje procesor može direktno izvršiti. Svaka porodica procesora (x86, ARM, RISC-V, itd.) definira vlastiti skup instrukcija i binarni format.

Na primjer, instrukcija iz x86 procesora bi mogla izgledati, u binarnom obliku, ovako: 10110000 01100001Ta sekvenca govori procesoru nešto vrlo specifično, poput "premjesti vrijednost 97 u registar X". Nama je to nečitljivo, ali za CPU je to svakodnevni posao.

Kada pišete nešto tako jednostavno kao u programskom jeziku visokog nivoa int x = 5;Kompajler na kraju generiše jednu ili više instrukcija mašinskog koda koje alociraju prostor, premeštaju broj 5 u registar, kopiraju ga u memoriju itd. Rezultat je izvršna datoteka koju operativni sistem može učitati u RAM i čiji Niz binarnih instrukcija se šalje procesoru kakav jeste..

Ključno je da je mašinski kod potpuno zavisan od hardveraIzvršna datoteka generirana za x86 neće raditi za ARM i obrnuto, osim ako nije uključena emulacija. Ova ovisnost je razlog zašto postoje međuarhitekture poput bajtkoda, koje pokušavaju apstrahirati stvarni hardver.

Asemblerski jezik, jedan korak iznad mašinskog koda

Asemblerski jezik je prvi nivo apstrakcije nad mašinskim kodomUmjesto pisanja nizova bitova, programer koristi mnemotehnike kao što su MOV, ADD, JMP i simboličke oznake za adrese ili varijable.

Ispod toga, svaka mnemonika odgovara gotovo jedan-na-jedan instrukciji mašinskog koda. asembler Prevodi taj program iz asemblerskog jezika u čisti binarni kod. Prevođenje je izuzetno jednostavno: u većini slučajeva, to je jednostavno mapiranje između simboličkog imena i specifičnog opkoda, s nekim prilagođavanjima adrese.

Velika prednost je što asembler omogućava kako bi se maksimalno iskoristili specifični resursi CPU-a (registri, posebne instrukcije, načini adresiranja), ali uz značajnu cijenu: složeno ga je napisati, vrlo skupo održavati i ovisi o hardveru kao i sam strojni kod.

Ako se pitate koliko slojeva postoji između asemblera i stvarnih jedinica i nula, odgovor je vrlo kratak: u osnovi jedanVaš asemblerski kod obrađuje asembler, koji generira objektni kod, a nakon povezivanja, dobijate binarnu izvršnu datoteku koja ide direktno na CPU. Nema uključenih interpretera ili virtuelnih mašina.

Bajtkod: most između izvornog koda i mašine

El bajtkod (ili međukod) To je još jedna vrsta niskonivojskog jezika, ali s drugačijom filozofijom: umjesto da bude vezan za određeni tip procesora, dizajniran je da ga izvršava... virtuelna mašina ili interpreter bajtkodaDrugim riječima, "CPU" koji razumije taj jezik nije fizički, već softverski.

En Java, na primjer, kada pišeš:

System.out.println("Zdravo, svijete");

javac kompajler ne generiše direktno x86 ili ARM instrukcije. Prvo prevodi izvorni kod u JVM bajtkodpohranjeni u .class datotekama. Ovaj bajtkod podsjeća na asembler za virtualni CPU baziran na steku, s instrukcijama poput aload_0, getstatic, invokevirtual, Itd

Nešto poput:

0: getstatic #2 // System.out
3: ldc #3 // «Zdravo, svijete»
5: invokevirtual #4 // PrintStream.println

Svaka instrukcija je bajt (opcode) nakon kojeg slijede mogući operandi. Ovaj niz ne izvršava stvarni CPU, već Java virtuelna mašina (JVM), koji djeluje kao interpreter ili JIT kompajler na tom toku bajtkoda.

Ista ideja važi i u drugim okruženjima: piton Generira vlastiti bajtkod koji izvršava njegov interpreter (CPython), a u .NET-u kompajler proizvodi IL (Srednji jezik)vrsta bajtkoda koji troši Runtime Common Language (CLR).

Bajtkod ili asembler? Prave sličnosti i razlike

Veoma je primamljivo reći da je bajtkod "na istom nivou kao i asembler", jer U oba slučaja govorimo o relativno jednostavnim instrukcijama koje su bliske mašini.Ali postoje važne razlike koje bi trebale biti jasne.

S jedne strane, Asembler je dizajniran za određeni fizički CPU. (na primjer, x86-64), dok je bajtkod dizajniran za virtuelni CPU (JVM, CLR, Python virtuelna mašina, itd.). Interpreter bajtkoda je ono što, za vrijeme izvođenja, prevodi ove virtuelne instrukcije u stvarne akcije na fizičkoj mašini.

S druge strane, bajtkod je obično dizajniran da podrži dinamičke optimizacije i JIT rekompilacijaVirtuelna mašina može posmatrati kako se program ponaša (koje se metode najčešće pozivaju, koje se grane izvršavaju, koji se realni tipovi koriste) i, na osnovu toga, generisati prefinjeniji mašinski kod nego što bi to proizvela jednostavna statička kompilacija.

Nasuprot tome, asemblerski program je prilično "statičan"Nakon što se sastavi i poveže, izvršna datoteka se zatvara: CPU izvršava svoje instrukcije tačno onako kako su generirane. Optimizacije na nivou CPU-a (keš memorije, cjevovodi, interno preuređenje instrukcija) mogu doći do izražaja, ali tok instrukcija u memoriji ostaje nepromijenjen.

Da to kažem pomalo kolokvijalno: asembler "govori" maternji jezik procesoraBajtkod govori izvornim jezikom virtuelne mašine, koja ga zauzvrat prevodi na jezik stvarnog CPU-a.

Slojevi između bajtkoda i mašinskog koda (i između asemblera i mašine)

Jedno od tipičnih pitanja je: Koliko slojeva zaista postoji između bajtkoda i jedinica i nula? Isto važi i za asembler. Hajde da ga analiziramo bez previše uljepšavanja, ali precizno.

U klasičnom slučaju C-a ili asemblera preko X86Tok bi bio manje-više:

• Izvorni kod ili asembler → Ti to pišeš.
• Kompajler/Asembler → generira objektni kod (djelomično binarni).
• Linker → kombinuje nekoliko objekata i biblioteka da bi formirao izvršnu datoteku.
• Operativni sistem → učitava izvršnu datoteku u memoriju, priprema stekove itd.
• CPU → direktno izvršava instrukcije mašinskog koda.

Dakle, između assemblera i mašine, možemo smatrati da postoji sloj za prevođenje (asembler) i sloj za pakovanje (linker)Sa stanovišta izvršenja, CPU vidi samo binarne podatke.

con bajt kod (na primjer, u Javi) historija Postaje malo duže:

• Izvorni kod Jave → Ti to pišeš.
• Javac kompajler → prevodi se u Java bajtkod (.class).
• ClassLoader i JVM verifikator → Učitavaju bajtkod, validiraju ga i pripremaju.
• JVM JIT interpreter i/ili kompajler → Pretvaraju bajtkod u stvarni mašinski kod, ponekad u hodu.
• Operativni sistem → upravlja JVM procesom, memorijom, nitima itd.
• CPU → izvršava mašinski kod koji je JVM generisao.

Ovdje možete jasno vidjeti da postoji nekoliko dodatnih slojeva: virtuelna mašina, verifikacija, JIT kompajliranje, upravljanje memorijom pomoću GC-aitd. Svi oni stoje između vašeg bajtkoda i jedinica i nula koje se na kraju izvršavaju.

En CPython Sa CPython-om se dešava nešto veoma slično: izvorni kod se kompajlira u bajtkod, pohranjuje (na primjer u .pyc), a taj bajtkod interpretira interna petlja u C-u koja svaku instrukciju šalje na strukture podataka interpretera, oslanjajući se na izvorni mašinski kod samog interpretera.

Prednosti bajtkoda: prenosivost, verifikacija i optimizacija

Sa toliko dodatnih slojeva, možda se pitate zašto se uopšte truditi koristiti bajtkod kada je direktni mašinski kod brži. Odgovor leži u praktične prednosti koje ovaj srednji nivo pruža.

Prvo i najočiglednije je prenosivostBajtkod je dizajniran da bude hardverski nezavisanJava .klasa generirana u Mac Sa ARM-om može se pokrenuti na PC-u sa Windows i x86-64 CPU-ove, pod uslovom da postoji kompatibilna JVM na obje strane. Isti bajtkod, različite fizičke mašine.

Drugi je verifikacija i sigurnostPrije izvršavanja vašeg koda, virtuelna mašina može pregledati bajtkod, provjeravajući da ne radi ništa ilegalno (pristup izvan dometa, kršenja modela tipa itd.), te odbiti ili prekinuti izvršavanje ako otkrije nešto sumnjivo. Ovaj korak je ključan u okruženjima u kojima pokrećete kod treće strane ili kod preuzet s mreže.

Treća velika prednost je dinamička optimizacijaStatički kompajler mora donositi određene optimizacijske odluke u vrijeme kompajliranja, a da ne zna kako će se program zapravo ponašati u produkciji. S druge strane, JIT kompajler može:

• Otkrivanje aktivnih (često pozivanih) metoda i sastavite ih s agresivnim strategijama.
• Specijalizirajte kod prema stvarnim vrstama i obrascima upotrebe (na primjer, masovno umetanje, eliminacija redundantnih provjera).
• Rekompilirajte dijelove koda ako se uslovi promijene (na primjer, ako se učita nova klasa koja krši prethodnu pretpostavku).

Sve ovo omogućava da, čak i ako je početni bajtkod generičkiji, konačni rezultat bude blokovi mašinskog koda visoko optimizovani za specifičan scenario na kojem se aplikacija izvršava.

Performanse: Da li je bajtkod uvijek sporiji od izvornog mašinskog koda?

Pojednostavljena tvrdnja da "Bajtkod je uvijek sporiji od mašinskog koda" Ovo je tačno samo ako ga uporedite sa vrlo dobro kompajliranim izvornim binarnim fajlom i pretpostavite osrednju virtuelnu mašinu bez JIT-a ili optimizacija.

U praksi, bajtkod prolazi kroz Dvije faze:

• Prvo pogubljenje gdje može biti čista interpretacija ili lagana JIT kompilacijasa većim preopterećenjem.
• Stabilna faza u kojoj je JIT već kompajlirao kritične puteve do aktivnog mašinskog koda i Performanse su vrlo blizu (ili ponekad jednake) onima izvornog koda.

U okruženjima kao što su JVM ili CLR, virtuelna mašina može generisati optimizovaniji mašinski kod od tradicionalnog statičkog kompajlerajer ima informacije o stvarnom ponašanju programa koje kompajler u tom trenutku nije imao.

Međutim, cijena te dodatne inteligencije nije besplatna: ona uključuje povećana potrošnja memorije, pauze JIT kompajliranja i složenost izvršavanjaStoga se u čvrsto integriranim ili ugrađenim sistemima u stvarnom vremenu, statički kompajlirani izvorni binarni fajl i dalje često preferira.

Java i JVM kao kompletan primjer cjevovoda

Java je dobra laboratorija za posmatranje kompletnog puta od izvornog koda do CPU-a. U ovom ekosistemu, Java nije samo jezik: Java = Java API + JVMJezik definira sintaksu i semantiku, API pruža standardne biblioteke, a JVM je odgovoran za izvršavanje bajtkoda.

Prvo imamo Izvorni kod Jave, koje pišete u .java datotekama. Ove klase prolaze kroz kompajler Javanese, koji vrši leksičku, sintaktičku i semantičku analizu, provjerava tipove, generira međustrukture i, konačno, kao izlaz proizvodi specijalni objektni kod: bajtkod sadržaj u .klasi.

Taj bajtkod još nije izvršni na stvarnoj mašini. Da bi se pokrenuo na bilo kojoj kompatibilnoj platformi, potrebna su još dva dijela: jedan java virtualna mašina specifično za svaku kombinaciju OS/CPU i moguće JIT kompajler koji u hodu transformiše dijelove bajtkoda u izvorni kod.

Dakle, ista datoteka .class može se trčati LinuxmacOS ili Windows, na ARM ili x86 arhitekturama, sve dok postoji JVM za obradu adaptacije. Problem "kompajliranja za svaku platformu" zamjenjuje se sa "posjedovanjem virtuelne mašine za svaku platformu", što uveliko pojednostavljuje život programerima aplikacija.

Osnovna JVM arhitektura: stekovi, heap i bajtkod

Da biste bolje razumjeli Java bajtkod, korisno je dobiti opštu predstavu o tome kako JVM je interno organizovanIako su se detalji mijenjali između verzija (na primjer, u Javi 8 je memorija restrukturirana), logička struktura je ostala prilično stabilna.

S jedne strane imamo strukture po nitimaSvaka nit u Javi ima svoj vlastiti izvršni stek (Java stek), koji zauzvrat sadrži:

• Un brojač programa sa trenutnom pozicijom izvršenja unutar bajtkoda.
• Una snop okviragdje svaki okvir odgovara pozivu metode.
• U svakom kadru, a niz lokalnih varijabli (parametri, interne varijable) i a stek operanada gdje bajtkod izvršava svoje operacije (guranje, izbacivanje, sumiranje, poređenje, pozive itd.).

S druge strane, postoji dijeljena memorija između niti, gdje se ističu:

• El Kupe, gdje se nalaze objekti (instance klase) i gdje djeluje Sakupljač smeća, odvajajući zone kao što su mlada generacija, stara generacija itd.
• Prostor koji nije heap (u klasičnim JVM-ovima, PermGen; u modernim JVM-ovima, Metaspace), gdje se skladišti metapodaci klasa, konstanti, stringova i samog kompajliranog koda putem JIT-a u kešu koda.

Kada pokrenete Java aplikaciju, ClassLoader se brine o Učitajte potrebne klase, popunite skup konstanti i provjerite bajtkod. i pripremiti sve tako da izvršni mehanizam može izvršavati instrukcije jednu po jednu na JVM steku. Svaka instrukcija u bajtkodu manipuliše stekom operanada i lokalnim varijablama, te može pristupiti skupu konstanti klase kako bi razriješila polja, metode, literale itd.

Praktični primjeri Java bajtkoda: atributi, metode, if naredbe i petlje

Da bismo ove ideje sveli na realnu osnovu, veoma je korisno pogledati kako prevesti vrlo jednostavan Java kod u bajtkod. Zamislite klasu sa jedinstveni atribut:

javna klasa BCTest { int vrijednost = 42; }

Prilikom dekompiliranja .class datoteke pomoću javap-a, vidjeli biste upute poput aload_0, invokespecial, bip 42, putfield, return unutar konstruktora. Taj niz radi nešto trivijalno kao što je:

• Opterećenje ovo u steku operanada.
• Pozovite konstruktor nadklase Objekt sa invokespecial.
• Ponovo učitajte ovo, potisnite literal 42 sa bipush.
• Povežite taj broj 42 sa poljem hrabrost trenutnog objekta sa Putfield.
• Završi sa povratak.

Svaka instrukcija ima, ispod, svoju reprezentaciju u bajtovima: 2A za aload_0, B7 00 01 za invokespecial #1, 10 2A za bipush 42, B5 00 02 za putfield #2, B1 za returnDrugim riječima, vrlo smo blizu asembleru, ali za virtualni CPU baziran na steku.

Ako dodate jednostavnu metodu, na primjer:

javni int zbir(int a, int b) { vrati a + b; }

Generirani bajtkod će izgledati otprilike ovako: iload_1, iload_2, iadd, ireturnDva parametra iz niza lokalnih varijabli se učitavaju na stek operanada, sabiraju i vraća se rezultat.

Kada uđete if kao kontrolni tok, kao if naredba:

ako (a < b) vrati 1; inače vrati 2;

Instrukcije za poređenje i skok se pojavljuju kao if_icmpgeOve naredbe upoređuju dva najveća cijela broja na steku i prelaze na drugu bajtkod poziciju na osnovu rezultata. Funkcionišu vrlo slično uslovnim skokovima u klasičnom asembleru, ali na virtuelnom steku.

U a for-petlja bitno:

za (int i = 0; i < 5; i++) { vektor[i] = i + 2; }

Vidjet ćete tipičan obrazac: inicijalizacija brojača sa ikone_0, istore_2, provjeravajući stanje sa iload_2, iconst_5, if_icmpge, tijelo petlje sa aload_1, iload_2, iload_2, iconst_2, iadd, iastore i ažurirajte sa IINC 2, 1 slijedi a goto koji se vraća na kontrolnu tačku. To je skoro kao čitanje x86 asemblera, ali sa operacijama orijentisanim na stek i simboličkim referencama na konstantni skup.

Bajtkod izvan Jave: Python, .NET i moderni JavaScript

Iako je Java najslikovitiji primjer, Model međukoda je uobičajen za mnoge moderne platforme.Python, na primjer, interno kompajlira izvorni kod u bajtkod koji možete pregledati pomoću modula dis. Jednostavan x = 5 transformira se u instrukcije poput LOAD_CONST 5, STORE_NAME x, koju interpreter izvršava na svom steku.

U .NET ekosistemu, jezici poput C# se kompajliraju u CIL/MSIL (Zajednički međujezik)Ovaj IL se ne izvršava direktno, već prolazi kroz Common Language Runtime (CLR), koji obavlja funkcije slične JVM-u: provjerava, upravlja memorijom, JIT kompajlira u izvorni mašinski kod i pruža sigurno okruženje za izvršenje.

Čak se i JavaScript, tradicionalno interpretiran, koristi u pretraživačima poput V8 (Chrome, Node.js) ili SpiderMonkey (Firefox). međureprezentacije i bajtkod prije nego što dođe do mašinskog koda. Engine kompajlira JS izvorni kod u vlastiti IR (međureprezentaciju) ili bajtkod i, na osnovu toga, primjenjuje različite optimizacijske i JIT faze.

U svim ovim slučajevima, obrazac se ponavlja: izvorni kod čitljiv ljudima → prenosivi/analizovatelni bajtkod → mašinski kod specifičan za platformu, s prostorom za uključivanje verifikacije, instrumentacije, statičke analize i optimizacija između.

Posmatranje kompletnog ciklusa od izvornog koda do CPU-a - kroz objektni kod, bajtkod i izvršnu datoteku - omogućava razumjeti ove slojeve i bolje shvatiti zašto neki jezici daju prioritet prenosivosti, drugi izvornim performansama, a treći ravnoteži između oboje; razumijevanje ovih slojeva pomaže u pisanju programa koji ne samo da rade, već su i brzi, sigurni i jednostavni za premještanje između platformi.