Mõned aastat tagasi kirjutas Fabrice Bellard jslinuxi — PC emulaatori, mis on kirjutatud JavaScriptis. Pärast seda on olnud veel vähemalt Virtual x86. Kuid nii palju kui mina tean, olid need kõik tõlgendajad, samas kui palju varem sama Fabrice Bellardi poolt kirjutatud Qemu ja tõenäoliselt iga enesest lugupidav kaasaegne emulaator kasutab JIT-kompileerimist külalisekoodi host-süsteemi koodiks. Tundus, et on kõige õigem tegeleda vastupidise ülesande realiseerimisega võrreldes sellega, mida brauserid lahendavad: JIT-kompileerimine masinakoodist JavaScripti, mille jaoks tundus kõige loogilisem portida Qemu. Tundub, et miks just Qemu, kuna on olemas lihtsamaid ja kasutajasõbralikumaid emulaatoreid — näiteks VirtualBox, mis lihtsalt installitakse ja töötab. Kuid Qemu-l on mõned huvitavad omadused

• avatud lähtekood
• võime töötada ilma kerneli draiverita
• võime töötada tõlgendaja režiimis
• toetab suurt hulka nii hosti kui ka külalisarhitektuure

Kolmanda punkti osas saan nüüd juba selgitada, et TCI režiimis tõlgendatakse tegelikult mitte külalismasinate käske, vaid nendest saadud baytkoodi, kuid see ei muuda asja sisu — uuel arhitektuuril Qemu kokkupanemiseks ja käivitamiseks piisab, kui vedamine on õnnelik, C kompilaatorist — koodigeneraatori kirjutamine võib oodata.

Ja nii, pärast kahte aastat aeglast askeldamist Qemu lähtekoodide kallal, on valmis töötav prototüüp, milles saab näiteks käivitada Kolibri OS-i.

Mis on Emscripten

Meie ajastul on tekkinud palju kompilaatoreid, mille lõpp-tulemus on JavaScript. Mõned, nagu TypeScript, on algselt mõeldud parimaks viisiks veebis kirjutada. Samas on Emscripten viis võtta olemasolev C või C++ kood ja kompileerida see brauserile arusaadavasse vormi. On sellel lehel kogutud mitmeid tuntud programmide porte: siit, näiteks võib vaadata PyPy-d — muide, nagu väidetakse, on neil juba JIT. Tegelikult ei saa iga programmi lihtsalt kompileerida ja bra useris käivitada — on rida erilised omadused, millega tuleb leppida, nagu ütleb sellel samal lehel olev kirjutis "Emscripteni saab kasutada peaaegu igasuguse portatiivne C/C++ koodi JavaScripti". See tähendab, et on olemas rida operatsioone, mis on standardi järgi määramatud, kuid tavaliselt töötavad x86-l — näiteks mitteühtlane muutujate juurdepääs, mis mõnel arhitektuuril on täiesti keelatud. Ühesõnaga, Qemu on platvormidevaheline programm ja, nagu lootsime, ei sisalda see palju määramatut käitumist — võta ja kompila, siis natuke mängida JIT-iga — ja valmis! Aga mitte siin…

Esimene katse

Üldiselt ei ole ma esimene, kellel on tulnud idee Qemu JavaScripti portida. ReactOS foorumis küsiti, kas see on võimalik Emscripteni abil. Veel varem levis kuulujutt, et selle tegi isiklikult Fabrice Bellard, kuid jutt käis jslinuxist, mis, kui ma mitte ei eksi, on justkui katse saavutada JS-s piisavat jõudlust käsitsi ja on kirjutatud nullist. Hiljem kirjutati Virtual x86 — selle kohta avaldati obfuskeerimata lähtekood ja nagu väideti, võimaldas suurem "realistlikkus" emulatsiooni kasutada SeaBIOS-i firmware'ina. Lisaks on olnud vähemalt üks katse portida Qemu Emscripteni abil — see üritati teha socketpair, kuid arendus, nii palju kui ma sain aru, oli külmutatud.

Nii et tundub, et siin on lähtekood, siin on Emscripten — võta ja kompileeri. Kuid on ka raamatukogusid, millest Qemu sõltub, ja raamatukogudest, millest need raamatukogud sõltuvad jne, ning üks neist on — libffi, millest sõltub glib. Internetis levisid kuuldused, et Emscripteni jaoks on suurte teekide kogu seas ka see, kuid sellele oli raske uskuda: esiteks, uut kompilaatorit ei olnud, teiseks, see on liiga madala tasemega teek, et lihtsalt võtta ja JS-iks kompileerida. Ja asi pole ainult assembleri sisestustes — tõenäoliselt on võimalik mõnel calling conventionil vajalikud argumendid virna topeltada ja funktsiooni kutsuda ka ilma nendeta. Kuid Emscripten on keeruline tööriist: et genereeritud kood näeks välja tuttav, kasutavad nad mõned trikid. Eelkõige nn relooping — koodigeneraator üritab saadud LLVM IR-l rekonstrueerida usutavaid if-sid, sildu jne. Noh, ja kuidas argumente funktsioonidele edastatakse? Loomulikult nagu JS-funktsioonide argumendid, st kui võimalik, siis mitte virna kaudu.

Alguses polnud mõttes muud, kui lihtsalt kirjutada libffi asendamine JS-iga ja läbida standardtestid, kuid lõpuks ajasin ma end segadusse, kuidas teha oma pealkirjafailid, et need töötaksid olemasoleva koodiga — mis teha, nagu öeldakse, "Kas ülesanded on nii keerulised või oleme meie nii tobedad". Tuli portida libffi veel ühe arhitektuuri peale, kui nii võib öelda — õnneks on Emscriptenil nii makrode tugi inline-assembleri jaoks (JavaScriptis, jah — noh, mis arhitektuur, selline ka assembler) kui ka võimalus käivitada genereeritud kood otse. Ühesõnaga, olles aega viibinud libffi platvormispetsiifiliste fragmentidega, sain ma mingisuguse kompileeritava koodi ja lasin selle läbida esimeselt ettejuhtuvast testist. Minu üllatuseks läbis test edukalt. Olles oma geniaalsusest šokeeritud — naljakas, kuid see töötas esimesel katsel — vaatasin ma uuesti saadud koodi, et hinnata, kuhu edasi kaevata. Siin olin ma taas jahmunud — ainus, mida mu funktsioon tegi. ffi_call — seda raporteeriti edukast kutset. Kutset endaga ei olnud. Nii et ma saatsin oma esimese pull request'i, mis parandas olympiadel arusaadavat viga testis — reaalarveid ei tohiks võrrelda nagu a == b ja isegi nagu a - b < EPS — ei tohi unustada ka moduuli, muidu 0 on tõepoolest võrreldav 1/3-ga... Ühesõnaga, mul sai valmis mingi libffi port, mis läbib kõige lihtsamad testid, ja millega kompileerub glib — mõtlesin, et hiljem, kui on aega, kirjutan rohkem. Osa sellest koodist libffi funktsiooni, nagu selgus, ei kuulunud isegi kompilaatorisse.

Kuid nagu ma juba ütlesin, on mõned piirangud ja mitmekesise määratlemata käitumise seas on üks ebameeldiv joon — JavaScript ei toeta disaini põhjal mällu jagatud mitme haru töötlemist. Üldiselt võib seda isegi nimendada hea ideena, kuid mitte koodi portimiseks, mille arhitektuur tugineb C keele harudele. Üldiselt katsetatakse Firefoxis jagatud töötajate (shared workers) toetust ning Emscriptenis on olemas pthread realiseerimine, kuid sellest sõltuda ei soovinud. Pidin järk-järgult eemaldama mitme haru töötlemise Qemu koodist — st leidma, kus harud käivitatakse, viima harus käivitatava tsükli sisu eraldi funktsiooni ja vaheldumisi kutsuma sellised funktsioonid põhitsüklist.

Teine katse

Mingil hetkel sai selgeks, et olukord ei ole muutunud ning et süsteemitu koodi impostimine ei toota soovitud tulemusi. Järeldus: tuleb leida viis, kuidas süsteematiseerida koodeksite lisamise protsessi. Seetõttu valiti toona uus versioon 2.4.1 (mitte 2.5.0, kuna seal võivad olla veel lahendamata bugid ning mul on juba oma bugide jagu), ning esimesena kirjutati see ohutult ümber. thread-posix.c. Noh, kuidas ohutult: kui keegi proovis teha operatsiooni, mis viis lukustumiseni, kutsuti koheselt välja funktsioon abort() — muidugi ei lahendanud see kohe kõiki probleeme, aga vähemalt oli see kuidagi meeldivam, kui vaikimisi andmete järjepidevuse probleemide saamine.

Üldiselt aitab JavaScripti koodi portimisel Emscripteni valikud väga palju. -s ASSERTIONS=1 -s SAFE_HEAP=1 — need tuvastavad mõningaid undefined behavior tüüpe, näiteks vale järjepidevuse aadressi juurde pääsemist (mis ei ühti absoluutselt typed arraysi koodiga, nagu HEAP32[addr >> 2] = 1) või funktsiooni vale arvu argumentidega kutsumise.

Üldiselt on joondusvead eraldi teema. Nagu ma juba ütlesin, on Qemu-s "degenereeritud" tõlgendav tagajärje koodigeneerimise TCI (tiny code interpreter), ja et Qemu uuel arhitektuuril üles seada ja käivitada, piisab, kui on käepärast C kompilaator. Märksõnad "kui hästi läheb". Mina ei saanud nii hästi hakkama ja selgus, et TCI oma baitkoodi tõlgendamisel kasutab joondamata ligipääsu. See tähendab, et igasugustel ARM-i ja muudel arhitektuuridel, kus on kohustuslik joondatud ligipääs, kompileeritakse Qemu, kuna neile on olemas normatiivne TCG-tagaehitus, mis genereerib natiivkoodi, aga kas TCI töötab nendel arhitektuuridel — see on veel küsimus. Siiski, nagu selgus, mainiti TCI dokumentatsioonis midagi sellist selgelt. Lõppkokkuvõttes lisati koodile funktsioonikutsed joondamata lugemise jaoks, mis leiti Qemu-s teises osas.

Mälu purunemine

Lõppkokkuvõttes anti TCI joondamata juurdepääs korda, loodi peatsükkel, mis vaheldumisi kutsus esile protsessori, RCU ja veel mõned pisiasjad. Ja nüüd käivitan Qemu valikuga -d exec,in_asm,out_asm, mis tähendas, et tuleb rääkida, millised koodiplokid täidetakse, ning samal ajal tõlkida, milline oli külaliskood ja milline on hostikood (antud juhul bytecode). See käivitatakse, täidab mitu tõlkimisplokki, kirjutab minu poolt jäänud tõrkeotsingu sõnumi, et RCU käivitatakse ja... kukub kokku, abort() funktsiooni sees free(). Kui funktsiooni uurimise teel free() õnnestus välja selgitada, et mäluploki pea, mis asub kaheksas baitis, mis eelneb eraldatud mälule, ei olnud ploki suurus ega midagi sellist, vaid prügikogum.

Virna hävimine - kui armas... Sarnases olukorras on kasulik lahendus - (kui võimalik) koguda samad lähtekoodid ja koostada natiivne binaar ning käitada seda Valgrindis. Mõne aja pärast oli binaar valmis. Käitan sama valikute kombinatsiooni - see kukub ikka veel algatamise ajal, ilma et jõuaks õigesse täideviimise etappi. Muidugi on see ebameeldiv - ilmselt ei olnud lähtekoodid täpselt samad, mis pole ka üllatav, kuna configure tuvastas veidi teised valikud, aga mul on ju olemas Valgrind - esmalt lahendan selle vea ja seejärel, kui õnnestub, võib-olla ilmub üles originaal. Käitan kõik sama Valgrindis... Üh-ä-ä, ü-ü-ü, e-e-e, see käivitati, läbisin algatamise normaalselt ja edasi minnes ei kohanud ma algset viga, ilma ühegi mäluaadressimist käsitleva hoiatuseta, rääkimata kukkumisest. Sellise asja jaoks ei olnud elu mind nagu öeldakse ette valmistanud - langev programm lõpetab kukkumise Valgrindis käivitamisel. Mis see oli - mõistatus. Minu hüpotees on, et kuna praeguse käsu ümbruses pärast algatamise kukkumist näitas gdb tööd memset-le kehtiva näidikuga kasutades kas mmx, või xmm kuid, see võib olla mingi joondamisviga, kuigi see tundub siiski kahtlane.

Okei, Valgrind ei näytä olevan apuna. Ja sitten alkoi se kaikkein epämiellytävin — kaikki tuntuu jopa käynnistyvän, mutta romahtaa täysin tuntemattomista syistä tapahtuman vuoksi, joka saattoi tapahtua miljoonia ohjeita sitten. Pitkään aikaa ei ollut edes selvää, mistä aloittaa. Lopulta oli pakko istua alas ja debuggata. Tulostus siitä, mitä otsikko oli kirjoitettu, osoitti, että tämä ei vaikuttanut olevan numero, vaan pikemminkin jotakin binaaridataa. Ja, ihme ja kumma, tämä binaarijono löytyi BIOS-tiedostosta — eli nyt voitiin varmuudella sanoa, että kyseessä oli puskurin ylivuoto, ja ymmärrettiin jopa, mitä tähän puskuriin kirjoitettiin. Ja sitten, kuten sanottu — Emscriptenissä onneksi ei ole osoiteavaruuden randomisointia, eikä siinä ole reikiä, joten voidaan kirjoittaa jonnekin koodin keskelle datan tulostus edellisestä käynnistyksestä, tarkistaa data, katsoa osoittinta, ja jos se ei ole muuttunut, saada tietoa pohdittavaksi. Totta, linkittämiseen menee pari minuuttia jokaisen muutoksen jälkeen, mutta mitäpä tuolle voi. Lopputuloksena löytyi tarkka rivi, joka kopioi BIOSin välitilasta vieraaseen muistiin — ja totisesti, puskurissa ei ollut riittävästi tilaa. Sen outojen puskuriosoitteiden lähteen etsiminen johti funktioon. qemu_anon_ram_alloc failis oslib-posix.c — loogika oli selline: mõnikord võib olla kasulik joondada aadress huge page suurusega 2 MB, selleks küsime mmap esialgu pisut rohkem ja siis tagastame üleliigse munmap. Ja kui selline joondamine ei ole vajalik, siis määrame selle asemel 2 MB tulemuse getpagesize() — mmap siiski tagastab joondatud aadressi... Nii et Emscriptendis mmap lihtsalt kutsub malloc, mis loomulikult ei joonda lehe järgi. Ühesõnaga, viga, mis mind paar kuud häiris, lahendati muudatusega kahe ridade osas.

Funktsioonide kutsumise iseärasused

Ja nüüd juba protsessor midagi arvutab, Qemu ei langema, aga ekraan ei sütti ja protsessor jääb kiiresti lõputuks tsüklisse, nagu nähtub väljundist -d exec,in_asm,out_asm. Ilmus hüpotees: katkestused ajastaja (noh või üldiselt kõik katkestused) ei jõua. Ja tõepoolest, kui võtta native kogumisest, mis kuidagi töötas, katkestused välja keerata, siis saadakse sarnane pilt. Kuid mõistatus osutus hoopis mitte selles: salvestatud jälgimisvõrkude võrdlus, mis anti eristatav valikuga, näitas, et täitmisrada erineb väga varakult. Siinkohal tuleb öelda, et võrdsustamine, mis on salvestatud käivitaja emrun native build debugging output is not really a mechanical process. I don't know exactly how the program running in the browser connects to emrun, but some lines in the output end up swapped, so a difference in the diff is not yet a reason to think the trajectories have diverged. Overall, it became clear that according to the instructions ljmpl the transition occurs through different addresses, and the bytecode generated is fundamentally different: one has a call instruction for a C helper function, while the other does not. After googling the instructions and studying the code that translates these instructions, it became clear that, firstly, a write was made directly to the register cr0 also using a helper — which switches the processor to protected mode, and secondly, the JS version never transitioned to protected mode. The fact is that another feature of Emscripten is its reluctance to accept code like the implementation of the instruction call in TCI, which converts any pointer to a function into the type long long f(int arg0, .. int arg9) — funktsioonid peavad olema kutsutud õigete argumentide arvuga. Kui seda reeglit rikutakse, siis sõltuvalt silumiseseadetest kas programm kukub kokku (mis on hea) või kutsub väga vale funktsiooni (mida on kuradi keeruline siluda). On veel kolmas variant — lubada ümbrikute genereerimist, mis lisavad/viskavad argumendid välja, kuid need ümbrikud võtavad kokku väga palju ruumi, samas kui tegelikult vajan ma vaid natuke rohkem kui sada ümbrikku. Ainuüksi see on üsna kurb, kuid ilmnes tõsisem probleem: genereeritud funktsioonide ümbrike koodis konverteeriti argumendid, kuid vahel ei kutsutud funktsiooni genereeritud argumentidega välja — just nagu minu rakenduses libffi. See tähendab, et mõned abifunktsioonid lihtsalt ei töödanud.

Õnneks on Qemus masinaga loetavad abifunktsioonide loendid, mis on nagu päisefail, näiteks

DEF_HELPER_0(lock, void)
DEF_HELPER_0(unlock, void)
DEF_HELPER_3(write_eflags, void, env, tl, i32)

Need kasutatakse üsna lõbusalt: kõige kummalisemal viisil ülekirjutatakse makrosid DEF_HELPER_n, ja siis lisatakse helper.h. Kuni selleni, et makro avatakse struktuuri initsialiseerijas ja komaga ning seejärel määratletakse massiiv, kus kohale on #include <helper.h> Lõpuks oli aeg proovida kasutada raamatukogu pyparsing, ja kirjutati skript, mis genereerib täpselt need ümbrikud ja täpselt neile funktsioonidele, mis on vajalikud.

Ja nüüd tundub, et protsessor on nagu tööle hakanud. Nagu, kuna ekraan ei initsialiseerunud, kuigi kohaliku versiooniga õnnestus käivitada memtest86+. Siinkohal on vaja täpsustada, et Qemu plokisisendi kood on kirjutatud koroutines. Emscriptenil on oma üsna keeruline rakendus, kuid selle toetamine Qemu koodis on veel vajalik, samas kui protsessorit on võimalik juba nüüd tõrkeotsinguks kasutada: Qemu toetab valikuid -kernel, -initrd, -append, mille abil saab laadida Linuxi või näiteks memtest86+, kasutamata üldse plokiseadmeid. Kuid oht: kohaliku versiooniga oli võimalik jälgida Linuxi kerneli väljundit konsoolile valikuga -nographic, aga brauserist ei olnud mingit väljundit terminali, kust see käivitati. emrun, ei tulnud. See tähendab, et pole selge, kas protsessor ei tööta või graafika väljund. Siis tuli mulle mõte veidi oodata. Selgus, et "protsessor ei maga, vaid lihtsalt vilgub aeglaselt", ja umbes viie minuti pärast viskas südamik konsoolile hunniku teateid ja jäi jälle kinni. Oli selge, et protsessor töötab, ja tuleb süveneda SDL2-ga seotud koodidesse. Kahjuks ei oska ma seda teeki kasutada, seetõttu tuli kohati tegutseda üle meele. Ühel hetkel vilkus ekraanil rida parallel0 sinisel taustal, mis tekitas mõtteid. Lõpuks selgus, et asi on selles, et Qemu avab mitu virtuaalset akent ühes füüsilises aknas, mille vahel saab vahetada Ctrl-Alt-n kombot kasutades: natiivses versioonis töötab see, Emscriptenis — ei. Pärast üleliigsete akende kõrvaldamist valikutega -monitor none -parallel none -serial none ja sundides iga kaadriga kogu ekraani uuesti joonistama, töötab kõik äkitselt.

Koruud

Seega, brauseris emuleerimine toimib, kuid ühekettalisi mänge ei saa seal käivitada, kuna puudub plokk-sisend- ja -väljund — tuleb rakendada korutiinide tuge. Qemu-s on juba mitu korutiinide tausta, kuid JavaScripti ja Emscripteni koodi genereerimise eripärade tõttu ei saa lihtsalt võtta ja alustada stekkide žongleerimist. Tundub, et "kõik on kadunud, gips võetakse maha", kuid Emscripteni arendajad on juba kõik ette valmistanud. See on ellu viidud üsna naljakalt: miks mitte nimetada kahtlaseks funktsiooni kutsumist nagu emscripten_sleep ja mitmeid teisi, mis kasutavad Asyncify mehhanismi, samuti kõnesid pöördumisnäidikute kaudu ja kõnesid mis tahes funktsiooni, kus steki all võib toimuda üks kahest eelnevalt mainitud juhtumist. Nüüd eraldame iga kahtlase kõne eel async konteksti ning kohe pärast kõnet kontrollime, kas toimus asünkroonne kõne. Kui jah, siis salvestame kõik lokaalsed muutujad sellesse async konteksti, määrame ära, millisele funktsioonile juhtimist edastada, kui teostamist tuleb jätkata, ja lahkume praegusest funktsioonist. Siin on tõeline ruum efektide uurimiseks tükeldamiseks — koodi jätkuva täitmise vajaduseks genereerib kompilaator "katkiseid" funktsioone, mis algavad pärast kahtlase kõne tegemist — nagu niimoodi: kui kahtlasi kõnesid on n, siis funktsioon on jaganenud kuskil n/2 võrra — ja see on veel enne, kui arvestada, et algsesse funktsiooni tuleb iga potentsiaalselt asünkroonse kõne järel lisada osa kohalike muutujate salvestamine. Hiljem tuli isegi kirjutada lihtne skript Pythonis, mis antud mitme eriti jagatud funktsiooni puhul, mis eeldatavalt "ei lase asünkroonsust end läbi", (see tähendab, et neis ei toimi virna pööramine ja kõik see, mida ma just kirjeldasin), näitab, millistele funktsioonidele näidatud viidete kaudu tehtavaid kõnesid kompilaator ignoreerida peaks, et andmeid ei käsitletaks asünkroonsetena. Sest JS-failid 60 MB — see on juba selgelt liialdus — olgu vähemalt 30. Kuigi kord seadsin kokkukutsumise skripti ja kogemata viskasin välja lingija võimalused, sealhulgas oli see -O3Käivitades genereeritud koodi, neelab Chromium mälu ja kukkub kokku. Vahetasin pärast juhuslikult sellele, mida ta proovis laadida... Mis ma saan öelda, ma oleksin samuti külmunud, kui mul palutaks põhjalikult uurida ja optimeerida JavaScripti 500+ MB peal.

Kahjuks ei olnud Asyncify toetava koodi kontrollid just kõige paremini ühilduvad longjmp-idega, mida kasutati virtuaalse protsessori koodis, kuid pärast väikest plaastrit, mis keelas need kontrollid ja sunni taastama kontekstid nagu kõik oleks hästi, töötas kood. Ja siis algas kummaline: mõnikord aktiveerusid sünkroonimise koodi kontrollid — need, mis lõpetavad koodi, kui see peaks logic'i kohaselt lukustuma — keegi proovis haarata juba haaratud muteksti. Õnneks polnud see loogiline probleem serialiseeritud koodis — lihtsalt kasutasin Emscripteni pakutavat tavalist main loop funktsionaalsust, kuid mõnikord pöördus asünkroonne kutsung täielikult tagasi kuhja, ja sel hetkel aktiveerus setTimeout main loop'ist — seega, kood sisenes peamise tsükli iteratsiooni ilma eelmisest iteratsioonist väljumata. Kirjutasin ümber lõputuks tsükliks ja emscripten_sleep, ning probleemid muteksitega lakkasid. Kood muutus isegi loogilisemaks — sest põhimõtteliselt ei ole mul mingit koodi, mis valmistab ette järgmist animatsiooni kaadrit — lihtsalt protsessor arvutab midagi ja ekraan uuendab end perioodiliselt. Siiski ei saanud probleemid sellega aga otsa: mõnikord lõpetas Qemu lihtsalt vaikselt täitmise ilma mistahes erandite ja vigadeta. Sel hetkel ma sellele ei pööranud tähelepanu, kuid, et ette ära öelda, probleem seisnes selles: kood korutine, tegelikult ei kasuta setTimeout (noh või vähemalt mitte nii tihti, kui võiks arvata): funktsioon emscripten_yield lihtsalt seab asünkroonse kutsumise lipu. Kogu point on selles, et emscripten_coroutine_next ei ole asünkroonne funktsioon: see kontrollib lippu, lähtestab selle ja suunab juhtimise õigesse kohta. See tähendab, et virna rullimine lõppeb sellel. Probleem oli selles, et kasutamata vaba mälu tõttu, mis ilmus korutinkogumi väljalülitamisel, kuna ma ei kopeerinud olemasolevast coroutine'i tagaküljest olulist koodirida, funktsioon qemu_in_coroutine tagastas true, kui see tegelikult pidi tagastama false. See viis meetodi kutsumiseni emscripten_yield, mille üle polnud virnas emscripten_coroutine_next, virna avardumine ulatus otsani, kuid mingeid setTimeout, nagu ma juba ütlesin, ei olnud seatud.

JavaScripti koodigeneerimine

Ja siin see on, lubatud "liha tagurpidi pööramine". Tegelikult ei ole. Loomulikult, kui käivitada Qemu brauseris ja selles Node.js, siis pärast Qemu-s koodigeneerimist saame absoluutselt mitte seda JavaScripti. Aga siiski, mingil määral on tagasi pöördumine.

Alustuseks räägime natuke sellest, kuidas Qemu töötab. Palun vabandage mind, ma ei ole Qemu professionaalne arendaja ja minu järeldused võivad olla osaliselt valed. Nagu öeldakse: "teise üliõpilase arvamus ei pea kattuma õppejõu, Peano aksioomide ja hea mõistusega". Qemu-l on teatud hulk toetatud külalisarhitektuure ja igaühe jaoks on kataloog nagu target-i386. Kogumise käigus saab näidata toetust mitmele külaliste arhitektuurile, kuid selle tulemusena saadakse lihtsalt mitu binaarset faili. Koodi külalisme arhitektuuri toetamiseks genereerib omakorda teatud siseoperatsioonid Qemu, mille TCG (Tiny Code Generator) muudab juba hosti arhitektuuri masinkoodiks. Kuidas on märgitud readme-failis, mis asub tcg kataloogis, oli see algselt osa tavalisest C-kompilaatorist, mis hiljem kohandati JIT-i jaoks. Seetõttu on näiteks sihtarhitektuur selle dokumendi kontekstis juba mitte külaline, vaid hosti arhitektuur. Mingil hetkel ilmus veel üks komponent — Tiny Code Interpreter (TCI), mis peaks täitma koodi (praktiliselt samu siseoperatsioone) konkreetses hosti arhitektuuri koodigeneraatori puudumisel. Tegelikult, nagu on märgitud tema dokumentatsioonis, ei pruugi see tõlkija alati töötada sama hästi kui JIT-koodigeneraator, mitte ainult kvantitatiivselt kiiruselt, vaid ka kvalitatiivselt. Kuigi ma ei ole kindel, et tema kirjeldus on täielikult ajakohane.

Alguses proovisin luua täisväärtuslikku TCG backend'i, kuid segadusse ajas mind kiiresti lähtefailide keerukus ja arusaamatud bytecode'i juhised, mistõttu otsustasin TCI tõlgendi ümbritsemise kasuks. See andis mitmeid eeliseid:

• koodigeneraatori rakendamisel sain tugineda mitte juhistele, vaid tõlgendi koodile
• funktsioone sai genereerida mitte iga ettejuhtuva tõlkeploki jaoks, vaid näiteks ainult pärast saja täitmise korda
• kui genereeritud koodi muudetakse (mis näib olevat võimalik, arvestades funktsioone, mille nimedes on sõna 'patch'), pean ma invalideerima genereeritud JS-koodi, kuid vähemalt on mul midagi, millest seda uuesti genereerida

Kolmanda punkti osas ei ole ma kindel, et patchimine on võimalik pärast seda, kui kood on esmakordselt täidetud, kuid esimesed kaks punkti on piisavad.

Alguses genereeriti kood suure switch'i kujul bytecode'i algse aadressi järgi, kuid pärast Emscripteni artikli meenutamist, genereeritava JS-i optimeerimist ja reloopingut, otsustasin genereerida inimlikuma koodi. Emapära järgi näis, et ainus sisendpunkt tõlkeplokki oli selle algus. Nüüd, pärast mõningast tööd, valmistasin koodigeneraatori, mis genereeris koodi if-idega (kuigi tsükleid polnud). Siiski tekkis probleem, kood kukkus kokku, tehes teatavaks, et käsk oli vale pikkusega. Sel ajal oli viimase taseme rekursiooni käsk brcond. Hästi, lisame identse kontrolli selle juhendi genereerimise juurde enne rekursiivset väljakutset ja pärast seda ja... mitte ükski neist ei täitunud, kuid pärast assert ’iga switchimist kõik siiski kukkusid. Lõpuks, uurides genereeritud koodi, sain aru, et pärast switchi taastatakse viidatud praegusele instruktsoonile virnast ja tõenäoliselt kirjutatakse üle genereeritava JavaScript koodiga. Nii see oligi. Puhvri suurendamine ühest megabaitist kümnele ei aidanud ning selgeks sai, et koodigeneraator joob ringi. Pidin kontrollima, et me ei ületaks praegust TB-d ja kui me seda teeme, siis anname järgmise TB aadressi negatiivse märgiga, et saaks jätkata täitmist. Lisaks lahendab see probleemi: "milliseid genereeritud funktsioone invalidida, kui see bytecode'i tükk on muutunud?" — invalidida tuleb ainult see funktsioon, mis vastab sellele translatsiooni plokile. Muide, kuigi ma tõrkeotsingut tegin kõik Chromiumis (kuna kasutan Firefoxi ja mul on mugavam kasutada eraldi brauserit katsetamiseks), aitas Firefox mul parandada ühilduvuse probleeme asm.js standardiga, pärast mida töötas kood Chromiums kiiremini.

Näidatud genereeritud kood

Compiling 0x15b46d0:
CompiledTB[0x015b46d0] = function(stdlib, ffi, heap) {
"use asm";
var HEAP8 = new stdlib.Int8Array(heap);
var HEAP16 = new stdlib.Int16Array(heap);
var HEAP32 = new stdlib.Int32Array(heap);
var HEAPU8 = new stdlib.Uint8Array(heap);
var HEAPU16 = new stdlib.Uint16Array(heap);
var HEAPU32 = new stdlib.Uint32Array(heap);

var dynCall_iiiiiiiiiii = ffi.dynCall_iiiiiiiiiii;
var getTempRet0 = ffi.getTempRet0;
var badAlignment = ffi.badAlignment;
var _i64Add = ffi._i64Add;
var _i64Subtract = ffi._i64Subtract;
var Math_imul = ffi.Math_imul;
var _mul_unsigned_long_long = ffi._mul_unsigned_long_long;
var execute_if_compiled = ffi.execute_if_compiled;
var getThrew = ffi.getThrew;
var abort = ffi.abort;
var qemu_ld_ub = ffi.qemu_ld_ub;
var qemu_ld_leuw = ffi.qemu_ld_leuw;
var qemu_ld_leul = ffi.qemu_ld_leul;
var qemu_ld_beuw = ffi.qemu_ld_beuw;
var qemu_ld_beul = ffi.qemu_ld_beul;
var qemu_ld_beq = ffi.qemu_ld_beq;
var qemu_ld_leq = ffi.qemu_ld_leq;
var qemu_st_b = ffi.qemu_st_b;
var qemu_st_lew = ffi.qemu_st_lew;
var qemu_st_lel = ffi.qemu_st_lel;
var qemu_st_bew = ffi.qemu_st_bew;
var qemu_st_bel = ffi.qemu_st_bel;
var qemu_st_leq = ffi.qemu_st_leq;
var qemu_st_beq = ffi.qemu_st_beq;

function tb_fun(tb_ptr, env, sp_value, depth) {
  tb_ptr = tb_ptr|0;
  env = env|0;
  sp_value = sp_value|0;
  depth = depth|0;
  var u0 = 0, u1 = 0, u2 = 0, u3 = 0, result = 0;
  var r0 = 0, r1 = 0, r2 = 0, r3 = 0, r4 = 0, r5 = 0, r6 = 0, r7 = 0, r8 = 0, r9 = 0;
  var r10 = 0, r11 = 0, r12 = 0, r13 = 0, r14 = 0, r15 = 0, r16 = 0, r17 = 0, r18 = 0, r19 = 0;
  var r20 = 0, r21 = 0, r22 = 0, r23 = 0, r24 = 0, r25 = 0, r26 = 0, r27 = 0, r28 = 0, r29 = 0;
  var r30 = 0, r31 = 0, r41 = 0, r42 = 0, r43 = 0, r44 = 0;
    r14 = env|0;
    r15 = sp_value|0;
  START: do {
    r0 = HEAPU32[((r14 + (-4))|0) >> 2] | 0;
    r42 = 0;
    result = ((r0|0) != (r42|0))|0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445321] = r14;
    if(result|0) {
    HEAPU32[1445322] = r15;
    return 0x0345bf93|0;
    }
    r0 = HEAPU32[((r14 + (16))|0) >> 2] | 0;
    r42 = 8;
    r0 = ((r0|0) - (r42|0))|0;
    HEAPU32[(r14 + (16)) >> 2] = r0;
    r1 = 8;
    HEAPU32[(r14 + (44)) >> 2] = r1;
    r1 = r0|0;
    HEAPU32[(r14 + (40)) >> 2] = r1;
    r42 = 4;
    r0 = ((r0|0) + (r42|0))|0;
    r2 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    HEAPU32[1445321] = r14;
    HEAPU32[1445322] = r15;
    qemu_st_lel(env|0, r0|0, r2|0, 34, 22759218);
if(getThrew() | 0) abort();
    r0 = 3241038392;
    HEAPU32[1445307] = r0;
    r0 = qemu_ld_leul(env|0, r0|0, 34, 22759233)|0;
if(getThrew() | 0) abort();
    HEAPU32[(r14 + (24)) >> 2] = r0;
    r1 = HEAPU32[((r14 + (12))|0) >> 2] | 0;
    r2 = HEAPU32[((r14 + (40))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    qemu_st_lel(env|0, r2|0, r1|0, 34, 22759265);
if(getThrew() | 0) abort();
    r0 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[(r14 + (40)) >> 2] = r0;
    r1 = 24;
    HEAPU32[(r14 + (52)) >> 2] = r1;
    r42 = 0;
    result = ((r0|0) == (r42|0))|0;
    if(result|0) {
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    }
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    return execute_if_compiled(22759392|0, env|0, sp_value|0, depth|0) | 0;
    return execute_if_compiled(23164080|0, env|0, sp_value|0, depth|0) | 0;
    break;
  } while(1); abort(); return 0|0;
}
return {tb_fun: tb_fun};
}(window, CompilerFFI, Module.buffer)["tb_fun"]

Kokkuvõte

Nii et töö pole endiselt lõpetatud, aga selle pikaajalise projekti saladuses viimistlemine on mulle tüütuks muutunud. Seetõttu otsustasin avaldada senise tulemuse. Kood on kohati kohutav, kuna see on katsetus ja ei ole selge, mida täpselt teha. Ilmselt peaks hiljem vormistama normaalsed atomaarset commit'id mõne uuema Qemu versiooni peal. Praegu on olemas haru gitis blogi formaadis: igale vähemalt kuidagi läbitud "tasemele" on lisatud ulatuslik kommentaar vene keeles. Sisuliselt on see artikkel märkimisväärses osas - kokkuvõte väljundist git log.

Seda kõike saab proovida siit (ole ettevaatlik, liiklus).

Mis juba praegu töötab:

• Töötab x86 virtuaalne protsessor
• On töötav prototüüp JIT-koodigeneraatorist masinkoodist JavaScripti jaoks
• On ettevalmistus teiste 32-bitiste külaliste arhitektuuride kogumiseks: võite praegu imetleda Linuxi arhitektuurile MIPS, mis hangub brauseris laadimise etapis

Mida veel teha

• Emulatsiooni kiirus. Isegi JIT-režiimis töötab see näiliselt aeglasemalt kui Virtual x86 (aga potentsiaalselt on olemas terve Qemu suure hulga emuleeritud riistvarade ja arhitektuuridega)
• Luua normaalne liides — ma ei ole just veebiarendaja, seega olen seni ümber teinud Emscripteni vaikimisi liidese nii hästi, kui oskasin
• Proovida käivitada keerulisemaid Qemu funktsioone — võrk, VM-i ränne jne.
• UPD: Pean oma vähesed saavutused ja veateated Emscripteni üleminekusse edastama, nagu eelnevad Qemu ja teiste projektide porteerijad tegid. Aitäh neile, et mul oli võimalus nende panust Emscriptenis oma ülesande raames varjatult kasutada.

Allikas: habr.com