För några år sedan skrev Fabrice Bellard jslinux — en emulator av en PC, skriven i JavaScript. Efter det fanns det åtminstone Virtual x86. Men alla dessa, såvitt jag vet, har varit tolkar, medan Qemu, som skrevs betydligt tidigare av samma Fabrice Bellard, och nog alla respektabla moderna emulatorer, använder JIT-kompilering av gästkod till värdmaskinens kod. Jag kände att det var dags att genomföra uppgiften omvänd, i förhållande till den som webbläsare löser: JIT-kompilering av maskinkod till JavaScript, vilket kändes mest logiskt när man portade Qemu. Det kan tyckas, varför just Qemu, det finns ju enklare och mer användarvänliga emulatorer — som VirtualBox till exempel — installerar och fungerar. Men Qemu har flera intressanta egenskaper

• öppna källkoder
• möjlighet att arbeta utan kärndrivrutiner
• möjlighet att arbeta i tolkningsläge
• stöd för många både värd- och gästarkitekturer

När det gäller den tredje punkten kan jag nu förklara att i TCI-läget tolkas inte själva gästmaskininstruktionerna utan bytekoden som erhålls från dem, men det ändrar inte essensen — för att bygga och köra Qemu på en ny arkitektur, om man har tur, räcker det med en C-kompilator — att skriva en kodgenerator kan skjutas upp.

Och nu, efter två års långsam klurande med Qemus källkod på fritiden, har en fungerande prototyp dykt upp, där man redan kan köra, till exempel, Kolibri OS.

Vad är Emscripten

Nuförtiden har det kommit många kompilatorer vars slutresultat är JavaScript. Vissa, såsom TypeScript, var från början avsedda som det bästa sättet att skriva för webben. Samtidigt är Emscripten ett sätt att ta existerande kod i C eller C++ och kompilera den till ett format som webbläsaren kan förstå. På denna sida har många portar av kända program skapats: här, till exempel kan man titta på PyPy — för övrigt sägs det att de redan har JIT. I verkligheten kan inte vilket program som helst enkelt kompileras och köras i webbläsaren — det finns en rad egenskaper, som man får leva med, men som det anges på samma sida "Emscripten can be used to compile almost any bärbar C/C++-kod till JavaScript. Det finns en rad operationer som är osäkra enligt standarden, men som vanligtvis fungerar på x86 — till exempel, ojusterad åtkomst till variabler, vilket på vissa arkitekturer är helt förbjudet. I allmänhet är Qemu ett plattformsoberoende program och man hoppades att det inte innehöll mycket osäker beteende — ta och kompilera, sedan lite arbete med JIT — och klart! Men så enkelt var det inte…

Första försöket

Överhuvudtaget är jag inte den första som fått idén att portera Qemu till JavaScript. På ReactOS-forumet ställdes frågan om detta var möjligt med Emscripten. Redan tidigare hade det flutit rykten om att Fabrice Bellard personligen hade gjort detta, men det handlade om jslinux, vilket såvitt jag vet är ett försök att manuellt uppnå tillräcklig prestanda i JS, och som är skriven från grunden. Senare skrevs Virtual x86 — det lades upp oklyvda källkoder och påstods att den stora "realismen" i emuleringen möjliggjorde användning av SeaBIOS som firmware. Dessutom fanns det åtminstone ett försök att portera Qemu med Emscripten — detta försökte göras socketpair, men utvecklingen, såvitt jag förstod, har stannat av.

Så, det verkar som om här är källkoderna, här är Emscripten — ta och kompilera. Men det finns också bibliotek som Qemu är beroende av, och bibliotek som dessa bibliotek är beroende av, och så vidare, däribland ett som är libffi, som glib är beroende av. Det fanns rykten på internet om att det fanns en sådan i den stora samlingen av portar till bibliotek för Emscripten, men det var svårt att tro: för det första, den samlades inte med den nya kompileraren, och för det andra, det är ett alltför lågnivåbibliotek för att bara kunna kompileras till JS. Och det handlar inte bara om assemblerinsatser — förmodligen kan man, om man vrider och vänder på det, för vissa calling conventions skapa nödvändiga argument på stacken och anropa funktionen utan dem. Men Emscripten är en knepig liten sak: för att den genererade koden ska se bekant ut för JS-motorens optimerare i webbläsaren, används vissa trick. Bland annat så kallad relooping — kodgeneratorn försöker återskapa trovärdiga if-satser, loopar etc. från den erhållna LLVM IR med några abstrakta instruktioner. Hur överförs argumenten i funktionerna? Självklart som argument till JS-funktioner, det vill säga så mycket som möjligt inte via stacken.

I början var tanken att bara skriva en ersättning för libffi i JS och köra standardtester, men till slut blev jag förvirrad över hur jag skulle göra mina header-filer så att de skulle fungera med befintlig kod - vad kan man säga, som man säger, "Antingen är uppgifterna så svåra, eller så är vi så dumma". Jag var tvungen att portera libffi till en annan arkitektur, om man nu kan kalla det så — lyckligtvis finns det i Emscripten både makron för inline assembly (i JavaScript, ja — vilken arkitektur, så även assemblern) och möjlighet att köra kod som genereras on-the-fly. Efter en tid av arbete med plattformsberoende fragment av libffi, lyckades jag få fram en kompilerbar kod och körde den på det första bästa testet. Till min förvåning, bestod testet. Jag var överraskad av min genialitet — är det ett skämt, det fungerade på första försöket — jag, fortfarande oförmögen att tro mina egna ögon, gick tillbaks för att se på den resulterande koden och bedöma vad jag skulle gräva i nästa steg. Här blev jag återigen överraskad — det enda som min funktion gjorde ffi_call — var att rapportera om ett framgångsrikt anrop. Det fanns inget anrop. Så jag skickade min första pull request, som rättade ett uppenbart fel i testet — flyttal ska inte jämföras som a == b och inte ens som a - b < EPS — kom ihåg att jag fortfarande måste lägga till modulen, annars kommer 0 verkligen att bli lika med 1/3… Sammanfattningsvis har jag fått fram en sorts libffi-port som klarar de enklaste testerna och som kan kompilera glib — jag tänkte att jag kan komplettera det senare. För att ligga steget före kan jag säga att kompilatorn faktiskt inte inkluderade den slutliga koden för libffi-funktionen.

Men, som jag redan nämnt, finns det vissa begränsningar, och bland det fria utnyttjandet av olika odefinierat beteende finns det en lite obehaglig särskildhet — JavaScript stöder inte flertrådighet med delad minne som standard. I princip kan detta faktiskt kallas en ganska bra idé, men inte för portering av kod vars arkitektur är baserad på C-trådar. Generellt sett pågår det experiment i Firefox för att stödja delade arbetare, och implementationen av pthread för dem finns i Emscripten, men jag ville inte vara beroende av detta. Jag var tvungen att gradvis avlägsna flertrådighet från Qemu-koden — det vill säga att leta efter var trådar startas, flytta kropparna av looparna som körs i dessa trådar till en separat funktion, och växelvis anropa sådana funktioner från huvudloopen.

Andra försöket

Vid något tillfälle blev det klart att läget var oförändrat, och att oordnat spridande av tillfälliga lösningar i koden inte skulle leda till något bra. Slutsatsen: Jag måste på något sätt systematisera processen för att lägga till tillfälliga lösningar. Därför valde jag den senaste versionen 2.4.1 (inte 2.5.0, eftersom man aldrig vet, om det finns fler obesvarade buggar i den nya versionen, och jag har tillräckligt med mina egna buggar), och som första steg skrev jag om thread-posix.c. Så, hur säkert: om någon försökte utföra en operation som skulle leda till en blockering, anropades direkt funktionen abort() — självklart åtgärdade detta inte alla problem direkt, men åtminstone var det på något sätt bättre än att tyst få data inkonsistens.

Generellt sett, när man porterar kod till JS, hjälper Emscripten-alternativen mycket -s ASSERTIONS=1 -s SAFE_HEAP=1 — de fångar vissa typer av odefinierat beteende som felaktiga adresser (vilket helt strider mot koden för typed arrays som HEAP32[addr >> 2] = 1) eller anrop av funktioner med fel antal argument.

För övrigt, justering av fel är ett eget ämne. Som jag nämnde finns det i Qemu en "degenererad" tolkande backend för kodgenerering TCI (tiny code interpreter), och för att bygga och köra Qemu på en ny arkitektur, om man har tur, räcker det med en C-kompilator. Nyckelord "om man har tur". Jag hade inte tur, och det visade sig att TCI vid tolkning av sin bytekod använder ojusterad åtkomst. Det vill säga, på alla sådana ARM- och andra arkitekturer som kräver justerad åtkomst kompileras Qemu eftersom det finns en korrekt TCG-backend som genererar nativ kod, men om TCI kommer att fungera på dem är fortfarande en fråga. Det visade sig dock att något liknande tydligt angavs i dokumentationen för TCI. Sammanfattningsvis lades det till funktioner för ojusterad läsning, som upptäcktes i en annan del av Qemu.

Krasch av heapen

Till slut åtgärdades den ojusterade åtkomsten i TCI, en huvudloop skapades som turades om att kalla på processorn, RCU och lite smått. Och nu kör jag Qemu med alternativet -d exec,in_asm,out_asm, vilket innebär att det ska anges vilka kodblock som körs, samt vid översättningen skriva vilken gästkod som fanns och vilken värdkod som blev (i det här fallet bytekod). Det startar, kör några översättningsblock, skriver det debugmeddelande jag lämnade, att RCU nu ska startas och… kraschar vid abort() inuti funktionen free(). Genom att gräva i funktionen free() utrettes att i huvudet på heapblocket, som ligger åtta byte före den allokerade minnet, fanns det skräp istället för blockstorlek eller något liknande.

Att förstöra en hög - hur gulligt... I sådana fall finns det ett användbart medel - att, om möjligt, från samma källor bygga en nativ binär och köra den under Valgrind. Efter en tid var binären klar. Jag kör med samma alternativ - den kraschar fortfarande vid initialisering, utan att faktiskt nå utförandet. Obehagligt, så klart - uppenbarligen var källorna inte riktigt desamma, vilket inte är förvånande, eftersom configure upptäckte några andra alternativ, men jag har ju Valgrind - först ska jag fixa den här buggen, och sedan, om jag har tur, kan jag få den ursprungliga att dyka upp. Jag kör allt som vanligt under Valgrind... Uh-oh, den startade, klarade initialiseringen och fortsatte förbi den ursprungliga buggen utan en enda varning om felaktig minnesåtkomst, för att inte tala om kraschar. Till detta var livet, som man säger, inte förberett mig - ett kraschande program slutar krascha när det startas under Valgrind. Vad var detta - en gåta. Min hypotes är att eftersom det i omgivningarna av den aktuella instruktionen efter krasch vid initialisering gdb visade aktivitet memset-a med en giltig pekare med hjälp av antingen mmx, eller xmm register, så kan det ha varit något fel med justeringen, även om det fortfarande är svårt att tro.

Okej, Valgrind verkar inte vara till hjälp här. Och här började det obehagligaste - allt verkar starta, men det kraschar av helt okända skäl på grund av en händelse som kan ha inträffat miljontals instruktioner tillbaka. Det var länge oklart hur man ens skulle närma sig problemet. Tills slut var jag tvungen att sätta mig ner och debuggra. Utskriften av vad som återställde rubriken visade att det inte liknade ett nummer, utan snarare något binärt data. Och, mirakulöst nog, hittades denna binära sträng i BIOS-filen - vilket innebär att man nu med tillräcklig säkerhet kunde säga att det handlade om ett buffertöverskridande, och man förstod till och med vad som skrevs till denna buffert. Vidare, i Emscripten, finns det lyckligtvis ingen randomisering av adresserummet, och det finns inga hål i det, så det går att skriva någonstans mitt i koden och få ut data via pekaren från den tidigare körningen, se på data, titta på pekaren, och om den inte ändrats, få information att fundera på. Problemet är att det tar några minuter att länka efter vilket som helst ändring, men vad kan man göra. Resultatet var att en specifik sträng hittades, som kopierade BIOS från en temporär buffert till gästminnet - och det visade sig att det inte fanns tillräckligt med utrymme i bufferten. Sökandet efter källan till den konstiga buffertadressen ledde mig till funktionen qemu_anon_ram_alloc i filen oslib-posix.c - logiken där var att det ibland kan vara användbart att justera adresser till en huge page på 2 MB, för detta ber vi i mmap först lite mer, och sedan returnerar vi överskottet med hjälp av munmap. Om ingen justering krävs, så anger vi istället för 2 MB resultatet getpagesize() — mmap det kommer ändå ge ut en justerad adress... Så i Emscripten mmap anropas helt enkelt malloc, och den justerar naturligtvis inte på sidan. På det stora hela, buggen som irriterade mig i flera månader, löstes med en ändring i två raderna.

Särskilda funktionsanrop

Och nu räknar processorn något, Qemu kraschar inte, men skärmen tänds inte, och processorn fastnar snabbt, dömd av utskriften. -d exec,in_asm,out_asmDet har uppstått en hypotes: det kommer inga timeravbrott (eller överhuvudtaget inga avbrott). Och visst, om man tar bort avbrotten från den native versionen som av någon anledning fungerade, blir bilden liknande. Men lösningen visade sig vara något helt annat: jämförelsen av spårningen, utförd med den angivna inställningen, visade att körningsvägarna avviker tidigt. Här måste det nämnas att jämförelsen mellan den avlyssnade med hjälp av startprogrammet emrun och den native versionens debugutskrift är inte en helt mekanisk process. Jag vet inte exakt hur programmet som körs i webbläsaren kopplar till emrun, men vissa rader i utskriften hamnar på andra platser, så skillnaden i diffen är inte en anledning att tro att körningsvägarna har avvikit. Sammanfattningsvis blev det tydligt att enligt instruktionerna ljmpl görs övergångar till olika adresser, och dessutom genereras bytekoden på ett helt annat sätt: i den ena finns en instruktion för att anropa en C-funktionshjälpare, i den andra finns den inte. Efter att ha googlat instruktioner och studerat koden som översätter dessa instruktioner, blev det klart att för det första så skrevs direkt till registret cr0 också med hjälp av en hjälpare — vilket förde processorn till skyddat läge, och för det andra att js-versionen aldrig nådde skyddat läge. Och detta beror på att ännu en egenskap hos Emscripten är att den inte vill tolerera kod av typen implementering av instruktionen call i TCI, som varje pekare till en funktion konverterar till typen long long f(int arg0, .. int arg9) — funktioner måste anropas med rätt antal argument. Vid brott mot denna regel kommer programmet antingen att krascha (vilket är bra), eller anropa en helt annan funktion (vilket är trist att felsöka). Det finns även ett tredje alternativ — att aktivera genereringen av omslag som lägger till/för bort argument, men totalt sett tar dessa omslag upp väldigt mycket plats, medan jag i praktiken bara behöver strax över hundra omslag. Detta är tyvärr en stor besvikelse, men det visade sig vara ett mer allvarligt problem: i den genererade koden för omslagfunktionerna konverterades argumenten, men funktionen med de genererade argumenten anropades ibland inte — precis som i min implementation av libffi. Det vill säga, vissa hjälpare utförs helt enkelt inte.

Lyckligtvis har Qemu maskinläsbara listor över hjälpkomponenter i form av en headerfil som liknar

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

De används på ett ganska lustigt sätt: först omdefinieras makron på de mest märkliga sätten DEF_HELPER_n, och sedan inkluderas helper.h. För att makrot ska utökas i en strukturinitialiserare och komma med ett kommatecken, och sedan definieras en array, istället för element — #include <helper.h> Som ett resultat fick jag äntligen tillfälle att försöka använda biblioteket pyparsing, och en skript skapades som genererade wrappers precis för de funktioner som behövdes.

Och nu, efter detta, verkade processorn ha startat. Verkade, eftersom skärmen fortfarande inte initialiserades, även om jag lyckades köra memtest86+ i den inhemska versionen. Här bör det påpekas att Qemus block I/O-kod är skriven med korutiner. I Emscripten finns det en ganska komplicerad implementation, men den behövde också stödjas i Qemus kod, medan processorn kan debuggas redan nu: Qemu stödjer alternativen -kernel, -initrd, -append, med hjälp av vilka man kan ladda Linux eller till exempel memtest86+ utan att använda blockenheter. Men förresten: i den inhemska versionen kunde man se Linux-kärnan till konsolen med alternativet -nographic, men från webbläsaren kom det ingen utdata till terminalen där den startades emrun, vilket inte gav något svar. Det vill säga: är processorn trasig eller är det grafikutmatningen. Och då kom jag på att vänta lite. Det visade sig att "processorn inte sover, utan bara blinkar långsamt", och efter fem minuter spottade kärnan ut en mängd meddelanden till konsolen och hängde sig sedan igen. Det blev klart att processorn fungerar men att jag behöver leta i SDL2-koden. Tyvärr vet jag inte hur man använder detta bibliotek, så jag fick ibland agera på måfå. Vid ett tillfälle flimrade raden parallel0 på en blå bakgrund, vilket väckte vissa tankar. I slutändan visade det sig att problemet var att Qemu öppnar flera virtuella fönster i ett fysiskt fönster, mellan vilka man kan växla med Ctrl-Alt-n: i den inhemska versionen fungerar det, i Emscripten gör det inte. Efter att ha blivit av med onödiga fönster med hjälp av alternativen -monitor none -parallel none -serial none och tvingar till att rita om hela skärmen vid varje bild, fungerade plötsligt allt.

Korutiner

Så emulatorn i webbläsaren fungerar, men det finns inget intressant från ett diskettdrivare att köra eftersom det inte finns något blockin- och utdata — support för korutiner måste implementeras. I Qemu finns det redan flera coroutine-backends, men på grund av JavaScript:s och Emscripten-kodgeneratorns särdrag kan man inte bara börja jonglera med stackar. Det skulle kunna verka som "allt är förlorat, gipset tas bort", men Emscripten-utvecklarna har redan tagit hand om allt. Det är genomfört på ett ganska underhållande sätt: låt oss kalla en misstänkt funktionsanrop som emscripten_sleep och några andra, som använder Asyncify-mekanismen, samt anrop via pekare och funktionsanrop där det kan inträffa något av de tidigare två fallen längre ner i stacken. Så nu, före varje misstänkt anrop, allokerar vi en asynkron kontext, och direkt efter anropet — kontrollerar vi om ett asynkront anrop inträffade, och om det gjorde det, sparar vi alla lokala variabler i denna asynkrona kontext, anger vilken funktion som ska ta över utförandet när vi behöver fortsätta, och vi lämnar den nuvarande funktionen. Här finns det verkligen utrymme för att studera effekten av splittande — för att fortsätta utföra koden efter att ha återvänt från ett asynkront anrop genererar kompilatorn "snuttar" av funktionen, som börjar efter det misstänkta anropet — så här: om det finns n misstänkta anrop, kommer funktionen att delas upp någonstans i n/2 gånger — detta utan att ta hänsyn till att en del lokala variabler måste sparas efter varje potentiellt asynkront anrop i den ursprungliga funktionen. Senare var jag till och med tvungen att skriva ett enkelt script i Python, som för ett givet antal speciellt splittrade funktioner som antas "inte släppa asynkronitet", det vill säga där stapeluppvridning och allt jag just beskrev inte inträffar, angav vilka anrop via pekare i vilka funktioner som kompilatorn skulle ignorera så att dessa funktioner inte betraktades som asynkrona. För annars är 60 MB JS-filer redan uppenbart för mycket — låt dem åtminstone vara 30. Även om jag en gång ställde in ett byggscript och av misstag tog bort länkarnas alternativ, bland vilka det var -O3. Jag kör den genererade koden och Chromium använder för mycket minne och kraschar. Jag råkade sedan titta på vad den försökte ladda... Tja, vad ska jag säga, jag skulle också hänga mig om jag blev ombedd att noggrant granska och optimera JavaScript på över 500 MB.

Tyvärr fungerade kontrollerna i Asyncify-stödbibliotekets kod inte riktigt bra med longjmp-arna som användes i koden för den virtuella processorn, men efter en liten patch som inaktiverade dessa kontroller och tvångsmässigt återställde kontexter som om allt var bra, fungerade koden. Och då började det konstiga: ibland utlöste kontroller i synkroniseringskoden – de som avslutar koden om den logiskt skulle blockeras – någon försökte fånga en redan fångad mutex. Lyckligtvis var det inte ett logiskt problem i den serialiserade koden – jag använde bara den standardfunktionalitet som tillhandahålls av Emscripten för huvudloopen, men ibland rullade det asynkrona anropet helt ut stacken, och vid det tillfället utlöste setTimeout från huvudloopen – så koden kom in i iterationen av huvudloopen utan att ha avslutat den föregående iterationen. Jag skrev om det i en oändlig loop och emscripten_sleep, och problemen med mutexarna upphörde. Koden blev till och med mer logisk – eftersom jag egentligen inte har någon kod som förbereder nästa animationsram – processorn beräknar något och skärmen uppdateras periodiskt. Men problemen slutade inte där: ibland avslutades Qemu tyst utan några undantag eller fel. Vid det tillfället gav jag upp, men för att förskjuta framåt säger jag att problemet låg i: kodkorutinerna använder egentligen inte setTimeout (eller åtminstone inte så ofta som man skulle kunna tro): funktionen emscripten_yield sätter bara en flagga för det asynkrona anropet. Det hela handlar om att emscripten_coroutine_next inte är en asynkron funktion: den kontrollerar sin flagga, nollställer den och överlämnar kontrollen dit den behöver gå. Det betyder att det är där stackutvecklingen avslutas. Problemet var att på grund av use-after-free, som uppstod när coroutine-poolen var inaktiverad eftersom jag inte kopierade över en viktig rad kod från den existerande coroutine-backend, returnerade funktionen qemu_in_coroutine true när den egentligen borde ha returnerat false. Detta ledde till anropet emscripten_yield, över vilken det inte fanns någon stack emscripten_coroutine_next, stacken sträckte sig ända till toppen, men inga setTimeout, som jag redan nämnt, angavs inte.

Kodgenerering JavaScript

Och här är faktiskt den lovade "återställningen av köttfärsen". Egentligen inte. Naturligtvis, om man kör Qemu i webbläsaren och i den – Node.js, kommer vi efter kodgenereringen i Qemu att få en helt annan JavaScript. Men ändå, en form av tillbakaöversättning.

Först lite om hur Qemu fungerar. Jag ber om ursäkt: jag är inte en professionell Qemu-utvecklare och mina slutsatser kan vara felaktiga på vissa ställen. Som man säger, "en students åsikt behöver inte stämma överens med lärarens åsikt, Peanos axiom och sunt förnuft". Qemu har ett antal stödda gästarkitekturer och för varje finns en katalog som liknar target-i386. Vid kompilering kan man ange stöd för flera gästarkitekturer, men resultatet blir helt enkelt flera binära filer. Koden för att stödja gästarkitekturen genererar i sin tur några interna operationer i Qemu, som TCG (Tiny Code Generator) sedan omvandlar till maskinkod för värdarkitekturen. Som anges i readme-filen som finns i katalogen tcg, var det ursprungligen en del av en vanlig C-kompilator som senare anpassades för JIT. Så exempelvis, gästarkitekturen i termer av detta dokument - det är redan värdarkitekturen. Vid ett tillfälle tillkom ytterligare en komponent - Tiny Code Interpreter (TCI), som ska köra koden (nästan samma interna operationer) i avsaknad av kodgenerator för den specifika värdarkitekturen. Faktum är att, som anges i dess dokumentation, denna tolk kanske inte alltid fungerar lika bra som JIT-kodgeneratorn, varken kvantitativt i fråga om hastighet eller kvalitativt. Jag är dock osäker på om dess beskrivning fortfarande är helt aktuell.

I början försökte jag göra en fullständig TCG-backend, men blev snabbt förvirrad av källkoden och den oklara beskrivningen av bytekodens instruktioner, så jag beslutade att kapsla in TCI-tolkaren. Det gav omedelbart flera fördelar:

• vid implementering av kodgeneratorn kunde jag titta inte i beskrivningen av instruktionerna utan i tolkens kod
• Funktioner kan genereras inte för varje mött block av översättning, utan till exempel bara efter den hundrade körningen.
• Vid ändring av den genererade koden (och detta verkar möjligt med tanke på funktioner som har "patch" i namnet) måste jag ogiltigförklara den genererade JS-koden, men åtminstone kommer jag ha något att regenerera den ifrån.

Jag är osäker angående det tredje punkten; jag tvekar på om patchning är möjligt efter att koden har körts första gången, men de första två punkterna är tillräckliga.

Ursprungligen genererades koden som en stor switch baserad på adressen till de ursprungliga bytekodinstruktionerna, men efter att jag kom på en artikel om Emscripten, optimering av den genererade JS:en och relooping, beslutade jag mig för att generera mer mänsklig läsbar kod. Det visade sig empiriskt att den enda ingångspunkten till översättningsblocket var i dess början. Så blev det. Efter en tid hade jag en kodgenerator som genererade kod med if-satser (även om utan loopar). Men här är kruxet, den föll med ett meddelande om att instruktionen hade fel längd. Den sista instruktionen på den här rekursionsnivån var brcond. Okej, jag lägger till en identisk kontroll vid genereringen av denna instruktion före det rekursiva anropet och efteråt, och... ingen av dem utfördes, men efter switchen på assert föll vi ändå. Till slut insåg jag, efter att ha studerat den genererade koden, att pekaren till den aktuella instruktionen laddades om från stacken och antagligen överskrevs av den genererade JavaScript-koden. Och så var det. Ökningen av buffertens storlek från en megabyte till tio ledde inte till något resultat, och det stod klart att kodgeneratorn cirkulerade. Jag var tvungen att kontrollera att vi inte hade gått utanför gränserna för den aktuella TB:n, och om vi hade, ge adressen till nästa TB med ett minustecken så att vi kunde fortsätta köra. Dessutom löser detta problemet med "vilka genererade funktioner ska ogiltigförklaras om denna bit bytekod har ändrats?" – endast den funktion som motsvarar detta översättningsblock måste ogiltigförklaras. Förresten, även om jag debuggade allt i Chromium (eftersom jag använder Firefox och det är lättare för mig att ha en separat webbläsare för experiment), hjälpte Firefox mig att åtgärda inkompatibiliteter med asm.js-standarden, efter vilket koden började köra snabbare i Chromium.

Exempel på genererad kod

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"]

Slutsats

Så, arbetet är fortfarande inte klart, men jag har tröttnat på att hemligt förfina detta långsamma bygge. Därför bestämde jag mig för att publicera vad som finns så långt. Koden är stundtals lite skrämmande, eftersom detta är ett experiment, och det är oklart på förhand vad som behöver göras. Kanske borde man senare skapa normala atomära commits över någon mer modern version av Qemu. Just nu finns det en gren i git i bloggformat: till varje "nivå" man tagit sig igenom har jag lagt till en utförlig kommentar på ryska. Egentligen är denna artikel i stor utsträckning en sammanfattning av slutsatsen. git log.

Detta kan de flesta testa här (försiktigt, trafik).

Vad som redan fungerar:

• En virtuell x86-processor fungerar
• Det finns en fungerande prototyp av JIT-kodgenerator från maskinkod till JavaScript
• Det finns en grund för att bygga andra 32-bitars gästarikitektur: ni kan just nu beundra den som hänger sig i webbläsaren under lastning av Linux för MIPS-arkitekturen

Vad mer kan göras

• Accelerera emuleringen. Även i JIT-läge verkar det fungera långsammare än Virtual x86 (men det finns åtminstone en hel Qemu med många emulerade hårdvaror och arkitekturer)
• Skapa ett bra gränssnitt - jag är, ärligt talat, ingen bra webbutvecklare, så än så länge har jag bara omarbetat standardgränssnittet i Emscripten så gott jag kunnat
• Försöka köra mer komplexa funktioner i Qemu - nätverk, migrering av VM osv.
• UPD: Jag måste skicka in mina få utvecklingsresultat och buggrapporter till upstream Emscripten, precis som tidigare portare av Qemu och andra projekt har gjort. Tack till dem för att jag fick möjlighet att obemärkt använda deras bidrag till Emscripten inom ramen för min uppgift.

Källa: habr.com