Baitkood

Baitkood (ingl. bytecode, mõnikord ka p-kood, p-kood porditavast koodist, ingl. portable code) on käsustiku vorm, mis on projekteeritud tõhusaks käivitamiseks tarkvaralise interpretaatori poolt. Erinevalt inimloetavast lähtekoodist koosneb baitkood kompaktsetest numberkoodidest, konstantidest ja viidetest (milleks harilikult on numbrilised aadressid), mis kodeerivad kompilaatori parsimise tulemuse ja teostavad semantilist analüüsi programmiobjektide tüübile, skoobile ja pesastamise sügavusele. Tehnilisest vaatenurgast on baitkood lähtekoodist genereeritud ja madala taseme masinast sõltumatu kood.

Paljud kaasaegsed programmeerimiskeeled, eriti kompileeritavad, kasutavad baitkoodi kompilaatori töö hõlbustamiseks ja kiirendamiseks.

Vormilt sarnaneb baitkood masinakoodiga, kuid see on mõeldud täitmiseks mitte reaalse protsessori, vaid virtuaalmasina poolt. Tavaliselt vastava programmeerimiskeele tõlk (mõnikord täiendab seda JIT- või AOT-kompilaatoriga) toimib virtuaalmasinana. Baitkoodi ja seda teostavate virtuaalmasinate spetsifikatsioonid võivad eri keeltes oluliselt erineda: sageli koosneb baitkood juhendist pinupõhise virtuaalmasina jaoks^[1], kuid saab kasutada ka registripõhiseid masinaid^[2][3]. Siiski on enamus baitkoodide juhendeid tavaliselt võrdsed ühe või mitme assembleri käsuga.

Baitkoodi on nime saanud sellest, et iga opkood on traditsiooniliselt ühe baidi suurune. Iga käsk on tavaliselt ühebaidine opcode (0 kuni 255), millele võivad järgneda parameeterid, näiteks registrinumber või mäluaadress.

Täitmine

Tavaliselt baitkoodi programmi täidab baitkoodi interpretaator. Baidikoodi eelis on suurem efektiivsus ja teisaldatavus, st sama baitkood saadakse teostada erinevatel platvormidel ja arhitektuuridel, mille jaoks interpretaator on rakendatud. Otseselt interpreteerivad keeled pakuvad samasugust eelist, kuid tavaliselt baitkood on vähem abstraktne ja kompaktsem kui lähtekood, baitkoodi interpreteerimise tõhusus on tavaliselt kõrgem kui lähtekoodi või abstraktne interpretatsiooni tõlgenduse puhas interpreteerimine. Lisaks on baitkoodi interpretaator sageli lihtsam kui lähtekoodi interpretaator ja seda on lihtsam teisele riistvaraplatvormile üle kanda.

Virtuaalsete masinate kõrgtehnoloogilistes rakendustes saab kasutada interpretaatori ja JIT-kompilaatori kombinatsiooni, mis programmitöö käigus tõlgib sageli kasutatavaid baitekoodi fragmente masina koodiks, rakendades erinevaid optimeeringuid. JIT-i kompileerimise asemel võib enne täitmist kasutada AOT-kompilaatorit, tõlkides baitkoodi masina koodiks.

Samal ajal on võimalik luua protsessoreid, mille jaoks antud baitkood on otse masina kood (sellised eksperimentaalsed protsessorid loodi näiteks Java ja Forth keelte jaoks).

Ajalugu

Esimesed baitkoodi kasutavad süsteemid olid BCPL-i O-kood (1960ndad), Smalltalk (1976)^[4], SIL (Süsteemi rakendamise keel) Snobol-4 jaoks (1967), p-kood (p-kood, 1970, koos Niklaus Wirthiga), Pascal programmeerimiskeele porditavatele kompilaatoritele^[5][6][7].

P-koodi variante kasutati laialdaselt Pascali keele mitmesugustes rakendustes, näiteks UCSD p-süsteemis (UCSD Pascal).^[8]

Rakendus

Baitkoodi interpreteeritud keeled on Perl, PHP (näiteks Zend Engine), Ruby (alates versioonist 1.9), Python, Erlang ja paljud teised.

Baitkoodi kasutavad laialdased platvormid^[9]:

• Java baitkood (stack virtuaalne masin), mida teostavad erinevad Java virtuaalmasinad^[10][11]. Platvorm oli loodud Sun poolt Java keelele, kuid seda kasutati ka teistes keeltes; On olemas kümneid suure jõudlusega JVM-i rakendusi kasutades JIT-kompilaatoreid.
• Java on võimalik tõlkida registri-masina baitkoodiks, näiteks Dalvik virtuaalmasinas (koos JIT-i koostamisega) või AOT-i kompileerimisega ART-is
• Microsoft .NET-i platvorm kasutab vahepealset keele Intermediate Language (CIL, MSIL) stack-baitkoodi^[8], mida rakendatakse ühise keele Common Language Runtime (CLR) abil, mille on loonud Microsoft C # ja mõnele muule keelele.
• Skriptikeel JavaScript täidetakse erinevate kõrgtehnoloogiliste "mootorite" abil, mis on peamiselt veebibrauseritega varustatud, sageli koos JIT-i optimeerimise võimalusega. Paljud interpretaatorid on ehitatud baitkoodi abil, kuid Javascripti programmid levitatakse lähtekoodidena.
• ActionScript-skriptikeel on tõlgitud stack-baitkoodi, mida jagatakse swf- ja pdf-failidena ning virtuaalsed masinad teostavad seda Adobe Flashis ja Adobe Acrobatis.

Clipper-kompilaator loob käivitatava faili, mis sisaldab programmi lähtekoodist tõlgitud baitekoodi ja seda baitekoodi täitvat virtuaalse masina.

Tavaliselt Java programmid kompileeritakse klassifailidesse (class-fail), mis sisaldavad Java baitkoodi. Need universaalsed failid kantakse üle erinevatesse sihtmärkmehhanismidesse.

Visual Basici varajastes rakendustes (kuni versioon 6) kasutati kõrgetasemelist Microsoft p-koodi^[9]

DBMSis kasutati kõrgetasemelisi p-koode ja baitkoode, mõned BASICi ja Pascali rakendused.

Sun Microsystemsi standardse Open Firmware Openloaderi puhul esindab baitkood Forth operaatorit.

Näited

Python

Kood:

>>> print("Hello, World!")
Hello, World!

Baitkood:

>>> import dis # impordime mooduli "dis" - Disassembler of Python byte code into mnemonics.
>>> dis.dis('print("Hello, World!")')
  1           0 LOAD_NAME                0 (print)
              2 LOAD_CONST               0 ('Hello, World!')
              4 CALL_FUNCTION            1
              6 RETURN_VALUE

Java

Kood:

outer:
for (int i = 2; i < 1000; i++) {
    for (int j = 2; j < i; j++) {
        if (i% j == 0)
            continue outer;
    }
    System.out.println (i);
}

Baitkood:

 0:   iconst_2
 1:   istore_1
 2:   iload_1
 3:   sipush  1000
 6:   if_icmpge       44
 9:   iconst_2
 10:  istore_2
 11:  iload_2
 12:  iload_1
 13:  if_icmpge       31
 16:  iload_1
 17:  iload_2
 18:  irem
 19:  ifne    25
 22:  goto    38
 25:  iinc    2, 1
 28:  goto    11
 31:  getstatic       #84; //Field java/lang/System.out:Ljava/io/PrintStream;
 34:  iload_1
 35:  invokevirtual   #85; //Method java/io/PrintStream.println:(I)V
 38:  iinc    1, 1
 41:  goto    2
 44:  return

Arvustus

Traditsiooniliselt on baitkood projekteeritud pinupõhiste virtuaalmasinate stiilis, mis lihtsustab AST genereerimist (!?!?), võimaldab kasutada lihtsamat ja kompaktsemat baitkoodi kodeeringut, lihtsustada interpretaatorit ja vähendada ühe baitkoodi käsu täiitmiseks vajaliku masinkäskude arvu. Teiselt poolt sellised baitkoodivariandid sisaldavad antud programmiks rohkem juhiseid kui registripõhiste virtuaalmasinate baitkoodid , mille tõttu interpretaator peab tegema rohkem kaudse väärtuse alusel hargnemisi, mille puhul hargnemiste ennustamine ei toimi hästi^[3]. Registripõhiste virtuaalmasinate baitkoodil on veidi suurem masina koodide arv, kuid hargnemiste arv on umbes kaks korda väiksem kui stopp-baitkood(?) ja interpretaator on kümneid protsente kiirem^[3]. Samuti on pinupõhiste masinate baitkood optimeerimise jaoks keerulisem (viited muutuvad kaudseteks, seotud käsud ei ole rühmitatud, väljendid jagatakse mitme põhiploki vahel)^[12] ja nõutakse korstna kasutamise õigsuse kontrollimist^[13]

Vead kontrollimises stack-masinate baitkoodi tõid kaasa hulga äärmiselt ohtlike haavatavuste tekkimise, eriti kümneid AVM2 virtuaalmasinas, mida Adobe Flashis kasutati ActionScript^[14][15][16] ja mitme varasema populaarse Java-süsteemiga (JVM). )^[17][18]

2000ndate lõpus - 2010. aasta alguses, kahtlesid V8-kompilaatorite autorid (JavaScript-i keel, mida sageli rakendatakse baitkoodi kaudu))^[19] ja Dart^[20], et kiire ja tõhusa virtuaalse masina jaoks on vaja vaheprotseduuride baitkoode. Nendes projektides oli realiseeritud otsene JIT-i koostamine (koostamine käivitusajal) lähtekoodist otse masina koodis.^[21]

Viited

1. Terence Parr. Language Implementation Patterns – Pragmatic Bookshelf, December 2009, ISBN 978-1-934356-45-6 «Part 3: Building Interpreters. Pattern 27 Stack-Based Bytecode Interpreter»
2. Terence Parr. Language Implementation Patterns – Pragmatic Bookshelf, December 2009, ISBN 978-1-934356-45-6 «Part 3: Building Interpreters. Pattern 28 Register-Based Bytecode Interpreter»
3. Yunhe Shi, David Gregg, Andrew Beatty, M. Anton Ertl (2005). "Virtual Machine Showdown: Stack Versus Registers" (inglise) (VEE '05: Proceedings of the 1st ACM/USENIX international conference on Virtual execution environments ed.). Chicago, Illinois, USA: ACM: 153–163. DOI:10.1145/1064979.1065001. ISBN 1-59593-047-7.
4. Bringing Performanceand Scalability toDynamic Languages^{[alaline kõdulink]} // Mario Wolczko, Oracle 2012 слайд 7
5. Руслан Богатырев. Летопись языков Паскаль, Мир ПК, № 04/2001
6. Компиляторы: принципы, технологии и инструментарий – Вильямс, ISBN 9785845901897, стр 517 «12.2 Компиляторы Pascal»
7. THE UCSD P-SYSTEM MUSEUM, 2004
8. Understanding .NET: A Tutorial and Analysis, David Chappell, David Wayne Chappell, 2002, ISBN 9780201741629 page 92
9. C# Versus Java / Dr. Dobb’s Journal February 2001
10. https://web.archive.org/web/20150519071206/http://www.javaworld.com/article/2077233/core-java/bytecode-basics.html 1996
11. Алан Джок. "Компиляторы, интерпретаторы и байт-код". «Computerworld Россия», № 06, 2001. Vaadatud 18.05.2015.
12. Ando Saabas, Tarmo Uustalu (2007). "Type systems for optimizing stack-based code" (PDF) (Electronic Notes in Theoretical Computer Science ed.). Lk 103-119. DOI:10.1016/j.entcs.2007.02.063. Originaali (PDF) arhiivikoopia seisuga 26. mai 2016.: «virtual stack or virtual register VMs can be executed more efficiently using an interpreter. Virtual register machines can be an attractive alternative to stack architectures because they allow the number of executed VM instructions to be substantially reduced.»
13. Gerwin Klein and Martin Wildmoser, Verified Bytecode Subroutines // Journal of Automated Reasoning 30.3-4 (2003): 363–398. «Bytecode verification is a static check for bytecode safety. Its purpose is to ensure that the JVM only executes safe code: no operand stack over- or underflows, no ill-formed instructions, no type errors»
14. Mark Dowd (X-Force Researcher IBM Internet Security Systems), Leveraging the ActionScript Virtual Machine^{[alaline kõdulink]}, IBM 2008 «if there was a way to execute AS3 instructions that had never been verified, it would be quite dangerous. Unverified instructions would be able to manipulate the native runtime stack … The attack works by manipulating a data structure used by the AVM2 verifier such that it doesn’t correctly verify the ActionScript instructions for a given method»
15. Haifei Li, Understanding and Exploiting Flash ActionScript Vulnerabilities Arhiiviversioon seisuga 26. november 2013, 2011 «Bytecode -> Verification process … ActionScript Vulnerabilities are due to various program flow calculating errors in the Verification/Generation Process (the Verification Flow and the Execution Flow are not the same)»
16. Haifei Li (Microsoft), Inside AVM // REcon 2012, Montreal «Most Flash vulnerabilities are ActionScript-related … Faults on verification cause highly-dangerous JIT type confusion vulnerabilities. • highly-dangerous means perfect exploitation: bypassing ASLR+DEP, with%100 reliability, no heapSpray, no JITSpray. • JIT type confusion bugs are due to faults in the verification of AVM!»
17. The last stage of delirium research group, Java and Java Virtual Machine security vulnerabilities and their exploitation techniques, BlackHat 2002: «The flaw stemmed from the fact that Bytecode Verifier did not properly perform the bytecode flow analysis»
18. Verification of Bytecode in a Virtual machine Arhiiviversioon seisuga 30. aprill 2013 // International Journal of Advanced Research in Computer Science and Software Engineering Vol.3 Issue 3 March 2013, ISSN 2277-128X: «Java byte code verification has been studied extensively from a correctness perspective, and several vulnerabilities have been found and eliminated in this process»
19. "Dynamic Machine Code Generation". Google.
20. Loitsch, Florian. "Why Not a Bytecode VM?". Google. Originaali arhiivikoopia seisuga 12. mai 2013. Vaadatud 11. jaanuaril 2019.
21. Dr. Axel Rauschmayer. "JavaScript myth: JavaScript needs a standard bytecode" (inglise).