Machine code vs bytecode: totoong pagkakaiba at kung paano nauugnay ang mga ito

Kapag nagprograma ka gamit ang Java, Python, C#, o anumang iba pang modernong wika, ang code na isinusulat mo ay hindi ang aktwal na pinapatakbo ng processor. Sa pagitan ng source code na nababasa ng tao at ng mga isa at sero na naiintindihan ng CPU, mayroong ilang mga patong ng pagsasalin, pag-optimize, at maging ang pag-verify ng seguridad na kadalasang hindi napapansin kung editor lang ang gagamitin mo.

Malaking bahagi ng "mahika" na iyan ay nakasalalay sa dalawang pangunahing konsepto: machine code at bytecode (o intermediate code) . Ang pag-unawa sa kung ano ang bawat isa, kung paano ito nauugnay sa JVM, sa .NET CLR, o sa Python interpreter, at kung gaano karaming layer talaga ang nasa pagitan ng iyong source code at ng hardware, ay lubos na nakakatulong sa paggawa ng mga desisyon tungkol sa performance, portability, at software architecture.

Machine code: ang mga tagubilin na nauunawaan ng CPU

Ang machine code ay ang pinakamababang antas ng representasyon ng software , na binubuo lamang ng mga bit (0 at 1) na nakaayos sa mga instruksyon na maaaring direktang isagawa ng processor. Ang bawat pamilya ng processor (x86, ARM, RISC-V, atbp.) ay tumutukoy sa sarili nitong instruction set at binary format.

Halimbawa, ang isang instruksyon sa isang x86 processor ay maaaring magmukhang, sa binary, tulad ng 10110000 01100001. Ang pagkakasunod-sunod na iyon ay nagsasabi sa processor ng isang bagay na napaka-espesipiko, tulad ng "ilipat ang halagang 97 sa rehistrong X." Hindi ito mababasa sa atin, ngunit para sa CPU, ito ay pang-araw-araw na impormasyon.

Kapag sumulat ka ng isang bagay na kasing simple ng `int x = 5; ` sa isang high-level na wika , ang compiler ay bubuo ng isa o higit pang mga tagubilin sa machine code na naglalaan ng espasyo, naglilipat ng 5 sa isang rehistro, kinokopya ito sa memorya, at iba pa. Ang resulta ay isang executable file na maaaring i-load ng operating system sa RAM, at ang pagkakasunod-sunod ng mga binary na tagubilin ay ipinapadala nang walang pagbabago sa processor.

Ang susi ay ang machine code ay ganap na nakadepende sa hardware . Ang isang executable na nabuo para sa x86 ay hindi gagana sa ARM, at kabaliktaran, maliban kung may kasangkot na emulation. Ang dependency na ito ang dahilan kung bakit umiiral ang mga intermediate architecture tulad ng bytecode, na nagtatangkang alisin ang tunay na hardware.

Wikang asembliya, isang hakbang na mas mataas kaysa sa code ng makina

Ang assembly language ay isang unang antas ng abstraksyon kaysa sa machine code . Sa halip na magsulat ng mga sequence ng bits, gumagamit ang programmer ng mga mnemonics tulad ng MOV, ADD, JMP at mga symbolic label para sa mga address o variable.

Sa ilalim, ang bawat mnemonic ay halos tumutugma sa isang instruksyon ng machine code. Isinasalin ng isang assembler ang programang assembler na iyon sa purong binary. Ang pagsasalin ay lubos na diretso: sa karamihan ng mga kaso, ito ay isang simpleng pagmamapa sa pagitan ng isang simbolikong pangalan at isang partikular na opcode, na may ilang pagsasaayos ng address.

Ang malaking bentahe ay pinapayagan ka ng assembler na lubos na mapakinabangan ang mga partikular na mapagkukunan ng CPU (mga rehistro, mga espesyal na tagubilin, mga mode ng pagtugon), ngunit sa isang malaking gastos: ito ay kumplikado isulat, napakamahal panatilihin, at kasing-depende sa hardware tulad ng mismong machine code.

Kung nagtataka ka kung ilang layer ang nasa pagitan ng assembly language at ng mga aktwal na ones at zeros, napakaikli ng sagot: isa lang talaga . Ang iyong assembly code ay dumadaan sa assembler, na siyang bubuo ng object code, at pagkatapos i-link, makakakuha ka ng binary executable na direktang pupunta sa CPU. Walang mga interpreter o virtual machine na kasangkot.

Bytecode: ang tulay sa pagitan ng source code at ng makina

Ang Bytecode (o intermediate code) ay isa pang uri ng low-level na wika, ngunit may ibang pilosopiya: sa halip na ikabit sa isang partikular na uri ng processor, ito ay idinisenyo upang isagawa ng isang virtual machine o bytecode interpreter . Sa madaling salita, ang "CPU" na nakakaintindi sa wikang ito ay hindi pisikal, kundi software.

Sa Java , halimbawa, kapag nagta-type ka:

System.out.println("Kumusta, mundo");

Ang javac compiler ay hindi direktang bumubuo ng mga tagubilin sa x86 o ARM. Isinasalin muna nito ang source code sa JVM bytecode , na nakaimbak sa mga .class file. Ang bytecode na ito ay kahawig ng isang assembler para sa isang stack-based virtual CPU, na may mga tagubilin tulad ng aload_0, getstatic, invokevirtual , atbp.

Isang bagay tulad ng:

0: getstatic #2 // System.out
3: ldc #3 // «Kumusta, mundo»
5: tawagin ang virtual #4 // PrintStream.println

Ang bawat instruksyon ay isang byte (opcode) na sinusundan ng mga posibleng operand. Ang pagkakasunod-sunod na ito ay hindi isinasagawa ng aktwal na CPU, kundi ng Java Virtual Machine (JVM) , na gumaganap bilang isang interpreter o JIT compiler sa bytecode stream na iyon.

Ang parehong ideya ay naaangkop sa ibang mga kapaligiran: Ang Python ay bumubuo ng sarili nitong bytecode na isinasagawa ng interpreter nito (CPython), at sa .NET ang compiler ay gumagawa ng IL (Intermediate Language) , isang uri ng bytecode na ginagamit ng Common Language Runtime (CLR).

Bytecode o assembler? Mga totoong pagkakatulad at pagkakaiba

Nakakaakit sabihin na ang bytecode "ay nasa parehong antas ng assembly language," dahil sa parehong kaso ay pinag-uusapan natin ang medyo simpleng mga tagubilin na halos kapareho ng machine code . Ngunit may mga mahahalagang pagkakaiba na dapat maging malinaw.

Sa isang banda, ang assembler ay dinisenyo para sa isang partikular na pisikal na CPU (halimbawa, x86-64), habang ang bytecode ay dinisenyo para sa isang virtual na CPU (ang JVM, ang CLR, ang Python virtual machine, atbp.). Ang interpreter ng bytecode ang siyang nagsasalin ng mga virtual na instruksyon na ito sa mga totoong aksyon sa pisikal na makina habang tumatakbo.

Sa kabilang banda, ang bytecode ay karaniwang idinisenyo upang suportahan ang mga dynamic na pag-optimize at just-in-time (JIT) compilation . Maaaring obserbahan ng virtual machine kung paano kumikilos ang programa (aling mga pamamaraan ang pinakamadalas na tinatawag, aling mga sangay ang isinasagawa, aling mga totoong uri ang ginagamit) at, mula roon, ay makakabuo ng mas pinong machine code kaysa sa magagawa ng isang simpleng static compilation.

Sa kabaligtaran, ang isang assembly program ay medyo "static ." Kapag na-assemble na at na-link na, ang executable ay isasara: isinasagawa ng CPU ang mga instruksyon nito nang eksakto kung paano ito nabuo. Maaaring may kinalaman ang mga CPU-level optimization (mga cache, pipeline, internal instruction reordering), ngunit ang daloy ng instruksyon sa memorya ay nananatiling hindi nagbabago.

Sa madaling salita: ang assembler ay "nagsasalita" ng katutubong wika ng processor , ang bytecode naman ay nagsasalita ng katutubong wika ng isang virtual machine, na siya namang isinasalin ito sa wika ng totoong CPU.

Mga patong sa pagitan ng bytecode at machine code (at sa pagitan ng assembler at makina)

Isa sa mga karaniwang tanong ay: ilang layer ba talaga ang nasa pagitan ng bytecode at ng mga isa at sero? At ganoon din sa assembly language. Suriin natin ito nang walang masyadong pagpapaganda, ngunit nang may katumpakan.

Sa isang klasikong kaso ng C o assembler sa x86 , ang daloy ay magiging higit pa o mas kaunti:

• Source code o assembler → Ikaw ang sumulat nito.
• Tagapagtipon/Tagapag-ipon → bumubuo ng object code (bahagyang binary).
• Tagapag-ugnay → pinagsasama ang ilang mga object at library upang mabuo ang executable.
• Sistema operativo → nilo-load ang executable sa memorya, naghahanda ng mga stack, atbp.
• CPU → direktang nagpapatupad ng mga tagubilin sa machine code.

Kaya, sa pagitan ng assembler at ng makina, maaari nating isaalang-alang na mayroong isang translation layer (ang assembler) at isang packaging layer (ang linker) . Mula sa punto de bista ng pagpapatupad, binary lamang ang nakikita ng CPU.

Sa bytecode (halimbawa, sa Java) medyo humahaba ang kwento :

• Kodigo ng pinagmulan ng Java → Ikaw ang sumulat nito.
• taga-compile ng javac → isinasalin sa Java bytecode (.class).
• Tagapagpatunay ng ClassLoader at JVM → Nilo-load nila ang bytecode, pinapatunayan ito, at inihahanda ito.
• Tagapagsalin at/o tagatala ng JVM JIT → Kino-convert nila ang bytecode sa aktwal na machine code, minsan ay on the fly.
• Sistema operativo → namamahala sa proseso, memorya, mga thread, atbp. ng JVM.
• CPU → isinasagawa ang machine code na nabuo ng JVM.

Dito mo malinaw na makikita na mayroong ilang karagdagang mga layer: virtual machine, beripikasyon, JIT compilation, pamamahala ng memorya gamit ang GC , atbp. Ang lahat ng ito ay nasa pagitan ng iyong bytecode at ng mga isa at sero na sa huli ay isinasagawa.

Sa CPython at CPython, may halos katulad na nangyayari: ang source code ay kino-compile sa bytecode, iniimbak (halimbawa sa .pyc), at ang bytecode na iyon ay binibigyang-kahulugan ng isang internal loop sa C na nagpapadala ng bawat instruksyon sa mga istruktura ng datos ng interpreter, na umaasa sa native machine code ng interpreter mismo.

Mga Bentahe ng bytecode: kadalian sa pagdadala, pag-verify, at pag-optimize

Dahil sa napakaraming karagdagang layer, maaaring magtaka ka kung bakit pa kailangan pang gumamit ng bytecode kung mas mabilis naman ang direct machine code. Ang sagot ay nasa praktikal na bentahe na ibinibigay ng intermediate level na ito.

Ang una at pinakahalatang bentahe ay ang kadalian sa pagdadala . Ang Bytecode ay idinisenyo upang maging hardware-independent . Ang isang Java .class file na nabuo sa isang Mac na may ARM processor ay maaaring tumakbo sa isang Windows PC na may x86-64 CPU, basta't ang parehong sistema ay may katugmang JVM. Parehong bytecode, magkaibang pisikal na makina.

Ang pangalawa ay ang beripikasyon at seguridad . Bago isagawa ang iyong code, maaaring siyasatin ng virtual machine ang bytecode, tiyakin na wala itong ginagawang anumang ilegal (out-of-range access, mga paglabag sa type model, atbp.), at tanggihan o ihinto ang pagpapatupad kung may makita itong anumang kahina-hinala. Mahalaga ang hakbang na ito sa mga kapaligiran kung saan nagpapatakbo ka ng third-party code o code na na-download mula sa network.

Ang ikatlong pangunahing bentahe ay ang dynamic optimization . Ang isang static compiler ay kailangang gumawa ng ilang mga desisyon sa optimization sa oras ng pag-compile nang hindi nalalaman kung paano talaga kikilos ang programa sa produksyon. Sa kabilang banda, ang isang JIT compiler ay maaaring:

• Tukuyin kung aling mga pamamaraan ang mainit (madalas gamitin) at tipunin ang mga ito gamit ang mga agresibong estratehiya.
• I-espesyalisa ang code ayon sa aktwal na mga uri at pattern ng paggamit (halimbawa, maramihang inlining, pag-aalis ng mga paulit-ulit na pagsusuri).
• I-recompile ang mga seksyon ng code kung magbabago ang mga kundisyon (halimbawa, kung may bagong klase na na-load, sisira ito sa isang nakaraang palagay).

Ang lahat ng ito ay nagbibigay-daan na, kahit na ang panimulang bytecode ay mas generic, ang pangwakas na resulta ay mga bloke ng machine code na lubos na na-optimize para sa partikular na senaryo kung saan tumatakbo ang aplikasyon.

Pagganap: Ang bytecode ba ay palaging mas mabagal kaysa sa katutubong code ng makina?

Ang simpleng pahayag na "ang bytecode ay palaging mas mabagal kaysa sa machine code" ay totoo lamang kung ihahambing mo ito sa isang napakahusay na naipon na katutubong binary at ipagpalagay na isang pangkaraniwang virtual machine na walang JIT o mga pag-optimize.

Sa pagsasagawa, ang bytecode ay dumadaan sa dalawang yugto :

• Isang unang pagpapatupad kung saan maaaring mayroong purong interpretasyon o magaan na kompilasyon ng JITna may mas maraming karga.
• Isang matatag na yugto kung saan naipon na ng JIT ang mga kritikal na landas patungo sa hot machine code at Ang pagganap ay halos kapareho (o minsan ay katumbas) ng sa katutubong code.

Sa mga kapaligirang tulad ng JVM o CLR, ang virtual machine ay maaaring makabuo ng mas na-optimize na machine code kaysa sa isang tradisyonal na static compiler , dahil mayroon itong impormasyon tungkol sa aktwal na pag-uugali ng programa na wala sa compiler noong panahong iyon.

Gayunpaman, ang karagdagang katalinuhang ito ay may kapalit: kinabibilangan ito ng pagtaas ng pagkonsumo ng memorya, mga paghinto ng JIT compilation, at pagiging kumplikado ng runtime . Samakatuwid, sa mga tightly integrated o hard real-time embedded system, ang mga staticly compiled native binary application ay madalas pa ring mas gusto.

Ang Java at ang JVM bilang isang kumpletong halimbawa ng isang pipeline

Ang Java ay isang mahusay na laboratoryo para sa pagtingin sa kumpletong paglalakbay mula sa source code hanggang sa CPU. Sa ecosystem na ito, ang Java ay hindi lamang isang wika: Java = Java API + JVM . Ang wika ang tumutukoy sa syntax at semantics, ang API ang nagbibigay ng mga karaniwang library, at ang JVM ang humahawak sa pagpapatupad ng bytecode.

Una, mayroon tayong Java source code , na isinusulat mo sa mga .java file. Ang mga klaseng ito ay dumadaan sa javac compiler , na nagsasagawa ng lexical, syntactic, at semantic analysis, sinusuri ang mga uri, bumubuo ng mga intermediate na istruktura, at sa huli ay gumagawa ng isang espesyal na object code bilang output: ang bytecode na nakapaloob sa mga .class file.

Ang bytecode na iyon ay hindi pa maipapatupad ng aktwal na makina. Para tumakbo ito sa anumang tugmang platform, dalawa pang bahagi ang gagamitin: isang Java virtual machine na partikular sa bawat kombinasyon ng OS/CPU at isang posibleng JIT compiler na agad na nagbabago ng mga bahagi ng bytecode tungo sa katutubong code.

Kaya, ang parehong .class file ay maaaring tumakbo sa Linux , macOS, o Windows, sa mga arkitektura ng ARM o x86, hangga't mayroong JVM upang iakma ito. Ang problema ng "pag-compile para sa bawat platform" ay napapalitan ng "pagkakaroon ng virtual machine para sa bawat platform," na lubos na nagpapadali sa buhay ng mga developer ng application.

Pangunahing arkitektura ng JVM: mga stack, heap at bytecode

Para mas maunawaan ang Java bytecode, makakatulong na magkaroon ng pangkalahatang ideya kung paano inorganisa ang JVM sa loob . Bagama't nagbago ang mga detalye sa pagitan ng mga bersyon (halimbawa, ang memorya ay muling isinaayos sa Java 8), ang lohikal na istruktura ay nananatiling medyo matatag.

Sa isang banda, mayroon tayong mga istruktura ng thread . Ang bawat thread sa Java ay may sariling execution stack (Java stack), na siya namang naglalaman ng:

• Un counter ng programa kasama ang kasalukuyang posisyon ng pagpapatupad sa loob ng bytecode.
• isang tumpok ng mga framekung saan ang bawat frame ay tumutugma sa isang tawag sa pamamaraan.
• Sa bawat frame, isang hanay ng mga lokal na baryabol (mga parametro, mga panloob na baryabol) at isang salansan ng mga operand kung saan isinasagawa ng bytecode ang mga operasyon nito (push, pop, sums, comparisons, calls, atbp.).

Sa kabilang banda, mayroong ibinahaging memorya sa pagitan ng mga thread , kung saan ang mga sumusunod ay namumukod-tangi:

• El magbunton, kung saan naninirahan ang mga bagay (mga instance ng klase) at kung saan kumikilos ang Tagakolekta ng Basura, na naghihiwalay ng mga sona tulad ng nakababatang henerasyon, matandang henerasyon, atbp.
• Ang non-heap space (sa mga klasikong JVM, PermGen; sa mga modernong JVM, Metaspace), kung saan ang imbakan metadata ng mga klase, constant, string, at ang mismong na-compile na code sa pamamagitan ng JIT sa Code Cache.

Kapag nagsimula ka ng isang Java application, nilo-load ng ClassLoader ang mga kinakailangang klase, pinupunan ang constant pool, bineberipika ang bytecode , at inihahanda ang lahat upang maisagawa ng runtime engine ang mga instruksyon nang paisa-isa sa JVM stack. Ang bawat instruksyon sa bytecode ay minamanipula ang operand stack at mga lokal na variable, at maaaring ma-access ang constant pool ng klase upang malutas ang mga field, method, literal, at iba pa.

Mga praktikal na halimbawa ng Java bytecode: mga katangian, pamamaraan, mga pahayag na "if", at mga loop

Para maipaliwanag nang detalyado ang mga ideyang ito, makakatulong na tingnan kung paano isinasalin ang napakasimpleng Java code sa bytecode. Isipin ang isang klase na may iisang katangian :

pampublikong klase BCTest { int halaga = 42; }

Kapag na-decompile mo ang .class file gamit ang javap, makakakita ka ng mga instruksyon tulad ng `aload_0`, `invokespecial`, `bipush 42`, `putfield`, at `return` sa loob ng constructor. Ang sequence na iyon ay gumagawa ng isang bagay na kasing simple ng:

• Mag-load ito sa stack ng operand.
• Tawagan ang constructor ng Object superclass gamit ang invokespecial.
• I-reload ito, itulak ang literal na 42 gamit ang bipush.
• Iugnay ang 42 na iyon sa patlang tapang ng kasalukuyang bagay na may Putfield.
• Tapusin sa pagbabalik.

Ang bawat instruksyon ay may pinagbabatayang representasyon ng byte: 2A para sa aload_0, B7 00 01 para sa invokespecial #1, 10 2A para sa bipush 42, B5 00 02 para sa putfield #2, B1 para sa return . Sa madaling salita, napakalapit na natin sa isang assembler, ngunit para sa isang stack-based virtual CPU.

Kung magdadagdag ka ng isang simpleng pamamaraan, halimbawa:

pampublikong int kabuuan(int a, int b) { ibalik ang a + b; }

Ang nabuong bytecode ay magiging katulad ng iload_1, iload_2, iadd, ireturn . Ang dalawang parameter mula sa array ng mga lokal na variable ay nilo-load sa operand stack, pinagsama-sama, at ang resulta ay ibinabalik.

Kapag ipinakilala mo ang if bilang isang control flow, tulad ng isang if:

kung ang (a < b) ay magbabalik ng 1; kung hindi ay magbabalik ng 2;

Lumilitaw ang mga tagubilin sa paghahambing at pagtalon, tulad ng `if_icmpge` , na naghahambing sa dalawang pinakamataas na integer sa stack at tumalon sa ibang posisyon ng bytecode batay sa resulta. Gumagana ito nang halos kapareho ng mga conditional jump sa klasikong assembly language, ngunit sa isang virtual stack.

Sa isang pangunahing loop na for :

para sa (int i = 0; i < 5; i++) { vector[i] = i + 2; }

Makakakita ka ng isang tipikal na pattern: pag-initialize ng counter gamit ang iconst_0, istore_2 , pagsuri sa kondisyon gamit ang iload_2, iconst_5, if_icmpge , ang loop body gamit ang aload_1, iload_2, iload_2, iconst_2, iadd, iastore , at pag-update gamit ang iinc 2, 1 na susundan ng isang goto na babalik sa check point. Ito ay halos katulad ng pagbabasa ng x86 assembly, ngunit may mga stack-oriented na operasyon at mga simbolikong sanggunian sa constant pool.

Bytecode na lampas sa Java: Python, .NET, at modernong JavaScript

Bagama't ang Java ang pinaka-simbolikong halimbawa, ang intermediate code model ay karaniwan sa maraming modernong plataporma . Halimbawa, ang Python ay internal na nagko-compile ng source code sa bytecode na maaari mong suriin gamit ang `dis` module . Ang isang simpleng `x = 5` ay binabago sa mga instruksyon tulad ng `LOAD_CONST 5`, `STORE_NAME x` , na isinasagawa ng interpreter sa stack nito.

Sa .NET ecosystem, ang mga wikang tulad ng C# ay kino-compile sa CIL/MSIL (Common Intermediate Language) . Ang IL na ito ay hindi direktang pinapatakbo, ngunit dumadaan sa Common Language Runtime (CLR), na nagsasagawa ng mga tungkuling katulad ng JVM: ito ay nagve-verify, namamahala ng memorya, kino-compile ang JIT sa native machine code , at nagbibigay ng ligtas na kapaligiran sa pagpapatupad.

Maging ang JavaScript, na ayon sa tradisyonal na kahulugan, ay gumagamit ng mga intermediate na representasyon at bytecode sa mga engine tulad ng V8 (Chrome, Node.js) o SpiderMonkey (Firefox) bago maabot ang machine code. Pinagsasama-sama ng engine ang JS source code sa sarili nitong IR (intermediate representation) o bytecode at, batay doon, naglalapat ng iba't ibang mga yugto ng optimization at Just-in-Time (JIT).

Sa lahat ng mga kasong ito, ang padron ay nauulit: readable source code → portable/analyzable bytecode → platform-specific machine code , na may espasyo para magsingit ng beripikasyon, instrumentasyon, static analysis, at mga pag-optimize sa pagitan.

Ang pagtingin sa kumpletong siklo mula sa source code hanggang sa CPU—kabilang ang object code, bytecode, at executable—ay nagbibigay-daan sa iyong maunawaan ang mga layer na ito at mas maunawaan kung bakit inuuna ng ilang wika ang portability, ang iba ay ang native performance, at ang iba naman ay ang balanse sa pagitan ng dalawa. Ang pag-unawa sa mga layer na ito ay makakatulong sa iyo na magsulat ng mga programang hindi lamang gumagana kundi mabilis, ligtas, at madaling ilipat sa pagitan ng mga platform.