Преди няколко години Фабрис Белард написано от jslinux е компютърен емулатор, написан на JavaScript. След това имаше поне повече Виртуален x86. Но всички те, доколкото знам, бяха интерпретатори, докато Qemu, написан много по-рано от същия Фабрис Белард, и вероятно всеки уважаващ себе си модерен емулатор, използва JIT компилация на гост код в код на хост система. Струваше ми се, че е време да внедря противоположната задача по отношение на тази, която браузърите решават: JIT компилация на машинен код в JavaScript, за което изглеждаше най-логично да се пренесе Qemu. Изглежда, защо Qemu, има по-прости и удобни емулатори - същият VirtualBox, например - инсталиран и работи. Но Qemu има няколко интересни функции

• отворен код
• възможност за работа без драйвер на ядрото
• възможност за работа в режим на преводач
• поддръжка за голям брой както хост, така и гост архитектури

Относно третата точка, сега мога да обясня, че всъщност в режим TCI не се интерпретират самите инструкции на машината за гости, а байт кодът, получен от тях, но това не променя същността - за изграждане и стартиране Qemu на нова архитектура, ако имате късмет, C компилатор е достатъчен - писането на генератор на код може да се отложи.

И сега, след две години спокойно бърникане с изходния код на Qemu в свободното ми време, се появи работещ прототип, в който вече можете да стартирате, например, Kolibri OS.

Какво е Emscripten

В днешно време се появиха много компилатори, чийто краен резултат е JavaScript. Някои, като Type Script, първоначално са предназначени да бъдат най-добрият начин за писане в мрежата. В същото време Emscripten е начин да вземете съществуващ C или C++ код и да го компилирате в четима от браузър форма. На тази страница Събрахме много портове на добре познати програми: тукНапример, можете да погледнете PyPy - между другото, те твърдят, че вече имат JIT. Всъщност не всяка програма може просто да се компилира и стартира в браузър - има редица Характеристика, с което обаче трябва да се примирите, тъй като надписът на същата страница гласи „Emscripten може да се използва за компилиране на почти всякакви портативен C/C++ код към JavaScript". Това означава, че има редица операции, които са недефинирано поведение според стандарта, но обикновено работят на x86 - например неподравнен достъп до променливи, което обикновено е забранено на някои архитектури. Като цяло , Qemu е междуплатформена програма и , исках да повярвам, и вече не съдържа много недефинирано поведение - вземете го и компилирайте, след това побърквайте малко с JIT - и сте готови! Но това не е случай...

Първи опит

Най-общо казано, не съм първият човек, който излезе с идеята за пренасяне на Qemu към JavaScript. Във форума на ReactOS беше зададен въпрос дали това е възможно с помощта на Emscripten. Още по-рано имаше слухове, че Фабрис Белард е направил това лично, но ние говорихме за jslinux, който, доколкото знам, е просто опит за ръчно постигане на достатъчна производителност в JS и е написан от нулата. По-късно беше написан Virtual x86 - за него бяха публикувани неограничени източници и, както беше посочено, по-големият „реализъм“ на емулацията направи възможно използването на SeaBIOS като фърмуер. Освен това имаше поне един опит за пренасяне на Qemu с помощта на Emscripten - опитах се да направя това двойка гнезда, но развитието, доколкото разбирам, беше замразено.

Така че, изглежда, ето източниците, ето Emscripten - вземете го и компилирайте. Но има и библиотеки, от които зависи Qemu, и библиотеки, от които зависят тези библиотеки и т.н., и една от тях е libffi, от което glib зависи. Имаше слухове в интернет, че има такъв в голямата колекция от портове на библиотеки за Emscripten, но някак си беше трудно да се повярва: първо, не беше предназначен да бъде нов компилатор, второ, беше твърде ниско ниво библиотека, за да вземете и компилирате в JS. И това не е само въпрос на вмъквания на асемблиране - вероятно, ако го завъртите, за някои конвенции за извикване можете да генерирате необходимите аргументи в стека и да извикате функцията без тях. Но Emscripten е сложно нещо: за да изглежда генерираният код познат на оптимизатора на JS двигателя на браузъра, се използват някои трикове. По-специално, така нареченото повторно зацикляне - генератор на код, използващ получения LLVM IR с някои абстрактни инструкции за преход, се опитва да пресъздаде правдоподобни ifs, цикли и т.н. Е, как се предават аргументите на функцията? Естествено, като аргументи към JS функции, тоест, ако е възможно, не през стека.

В началото имаше идея просто да напиша заместител на libffi с JS и да пусна стандартни тестове, но накрая се обърках как да направя заглавните си файлове така, че да работят със съществуващия код - какво мога да направя, както се казва, „Толкова ли са сложни задачите „Толкова ли сме глупави?“ Трябваше да пренеса libffi към друга архитектура, така да се каже - за щастие, Emscripten има както макроси за вградено асемблиране (в Javascript, да - добре, каквато и да е архитектурата, така и асемблерът), и способността да изпълнява код, генериран в движение. Като цяло, след като се занимавах известно време със зависещи от платформата libffi фрагменти, получих някакъв компилируем код и го пуснах на първия тест, на който попаднах. За моя изненада тестът беше успешен. Зашеметен от моята гениалност - няма шега, работи от първото стартиране - аз, все още не вярвайки на очите си, отидох да погледна отново получения код, за да преценя къде да ровя по-нататък. Тук полудях за втори път - единственото, което направи функцията ми беше ffi_call - това съобщи за успешно повикване. Самото обаждане нямаше. Така че изпратих първата си заявка за изтегляне, която коригира грешка в теста, която е ясна за всеки ученик на олимпиада - реалните числа не трябва да се сравняват като a == b и дори как a - b < EPS - също трябва да запомните модула, в противен случай 0 ще се окаже много равно на 1/3... Като цяло измислих определен порт на libffi, който преминава най-простите тестове и с който glib е компилиран - реших, че ще е необходимо, ще го добавя по-късно. Гледайки напред, ще кажа, че както се оказа, компилаторът дори не е включил функцията libffi в крайния код.

Но, както вече казах, има някои ограничения и сред свободното използване на различни недефинирани поведения е скрита по-неприятна функция - JavaScript по дизайн не поддържа многопоточност със споделена памет. По принцип това обикновено дори може да се нарече добра идея, но не и за пренасяне на код, чиято архитектура е обвързана с C нишки. Най-общо казано, Firefox експериментира с поддържането на споделени работници и Emscripten има внедряване на pthread за тях, но не исках да разчитам на него. Трябваше бавно да изкореня многонишковостта от кода на Qemu - тоест да открия къде се изпълняват нишките, да преместя тялото на цикъла, работещ в тази нишка, в отделна функция и да извикам такива функции една по една от основния цикъл.

Втори опит

В един момент стана ясно, че проблемът все още е налице и че хаотичното натискане на патерици около кода няма да доведе до нищо добро. Заключение: трябва по някакъв начин да систематизираме процеса на добавяне на патерици. Затова беше взета версия 2.4.1, която беше прясна по това време (не 2.5.0, защото, кой знае, в новата версия ще има грешки, които все още не са уловени, а аз имам достатъчно собствени грешки ), и първото нещо беше да го пренапиша безопасно thread-posix.c. Е, това е толкова безопасно: ако някой се опита да извърши операция, водеща до блокиране, функцията веднага се извиква abort() - разбира се, това не реши всички проблеми наведнъж, но поне беше някак по-приятно от тихото получаване на противоречиви данни.

Като цяло опциите на Emscripten са много полезни при пренасяне на код към JS -s ASSERTIONS=1 -s SAFE_HEAP=1 - те улавят някои видове недефинирано поведение, като извиквания към неподравнен адрес (което изобщо не е в съответствие с кода за въведени масиви като HEAP32[addr >> 2] = 1) или извикване на функция с грешен брой аргументи.

Между другото, грешките при подравняването са отделен въпрос. Както вече казах, Qemu има „изроден“ интерпретативен бекенд за генериране на код TCI (дребен кодов интерпретатор) и за изграждане и стартиране на Qemu на нова архитектура, ако имате късмет, е достатъчен C компилатор. "ако имаш късмет". Нямах късмет и се оказа, че TCI използва неподравнен достъп, когато анализира своя байт код. Тоест, на всички видове ARM и други архитектури с непременно изравнен достъп, Qemu компилира, защото те имат нормален TCG бекенд, който генерира собствен код, но дали TCI ще работи върху тях е друг въпрос. Въпреки това, както се оказа, документацията на TCI ясно показва нещо подобно. В резултат на това към кода бяха добавени извиквания на функции за неподравнено четене, които бяха открити в друга част на Qemu.

Унищожаване на купчина

В резултат на това неподравненият достъп до TCI беше коригиран, беше създаден основен цикъл, който на свой ред извика процесора, RCU и някои други малки неща. И така стартирам Qemu с опцията -d exec,in_asm,out_asm, което означава, че трябва да кажете кои блокове от код се изпълняват, а също и по време на излъчването да напишете какъв е бил кодът на госта, какъв е станал кодът на хоста (в този случай байт код). Стартира, изпълнява няколко блока за превод, пише съобщението за отстраняване на грешки, което оставих, че RCU сега ще стартира и... се срива abort() вътре във функция free(). С човъркане на функцията free() Успяхме да разберем, че в заглавката на heap блока, който се намира в осемте байта предшестващи разпределената памет, вместо размера на блока или нещо подобно, имаше боклук.

Унищожаване на купчината - колко сладко... В такъв случай има полезно лекарство - от (ако е възможно) същите източници, сглобете оригинален двоичен файл и го стартирайте под Valgrind. След известно време двоичният файл беше готов. Стартирам го със същите опции - забива дори при инициализация, преди реално да стигне до изпълнение. Неприятно е, разбира се - очевидно източниците не са били съвсем същите, което не е изненадващо, защото configure проучва малко по-различни опции, но имам Valgrind - първо ще поправя тази грешка и след това, ако имам късмет , ще се появи оригиналният. Пускам същото нещо под Valgrind... Y-y-y, y-y-y, ъъъъ, започна, премина нормално през инициализацията и продължи покрай оригиналния бъг без нито едно предупреждение за неправилен достъп до паметта, да не говорим за падания. Животът, както се казва, не ме подготви за това - сриваща се програма спира да се срива, когато се стартира под Walgrind. Какво беше това е мистерия. Моята хипотеза е, че веднъж в близост до текущата инструкция след срив по време на инициализация, gdb показа работа memset-a с валиден указател, използващ или mmx, или xmm регистри, тогава може би това е някаква грешка в подравняването, въпреки че все още е трудно да се повярва.

Добре, Valgrind изглежда не помага тук. И тук започна най-отвратителното - всичко изглежда дори стартира, но се срива по абсолютно неизвестни причини поради събитие, което можеше да се случи преди милиони инструкции. Дълго време дори не беше ясно как да подходим. В крайна сметка все пак трябваше да седна и да отстранявам грешки. Отпечатването на това, с което е пренаписан заглавката, показа, че не изглежда като число, а по-скоро като някакъв вид двоични данни. И, ето, този двоичен низ беше намерен в BIOS файла - тоест сега беше възможно да се каже с разумна увереност, че това е препълване на буфера и дори е ясно, че е записано в този буфер. Е, тогава нещо подобно - в Emscripten, за щастие, няма рандомизиране на адресното пространство, няма и дупки в него, така че можете да напишете някъде по средата на кода, за да изведете данни чрез указател от последното стартиране, погледнете данните, погледнете показалеца и, ако не се е променил, вземете храна за размисъл. Вярно е, че отнема няколко минути за свързване след всяка промяна, но какво можете да направите? В резултат на това беше намерен конкретен ред, който копира BIOS от временния буфер в паметта за гости - и наистина нямаше достатъчно място в буфера. Намирането на източника на този странен адрес на буфера доведе до функция qemu_anon_ram_alloc във файл oslib-posix.c - логиката беше следната: понякога може да е полезно да приведете адреса към огромна страница с размер 2 MB, за това ще поискаме mmap първо малко повече и след това ще върнем излишъка с помощта munmap. И ако такова подравняване не се изисква, тогава ще посочим резултата вместо 2 MB getpagesize() - mmap все пак ще даде подравнен адрес... Така че в Emscripten mmap само обаждания malloc, но разбира се не се подравнява на страницата. Като цяло грешка, която ме разочароваше за няколко месеца, беше коригирана чрез промяна в двух линии.

Характеристики на извикващи функции

И сега процесорът брои нещо, Qemu не се срива, но екранът не се включва и процесорът бързо преминава в цикли, съдейки по изхода -d exec,in_asm,out_asm. Възникна хипотеза: прекъсванията на таймера (или като цяло всички прекъсвания) не пристигат. И наистина, ако отвиете прекъсванията от родния монтаж, който по някаква причина работи, получавате подобна картина. Но това изобщо не беше отговорът: сравнението на следите, издадени с горната опция, показа, че траекториите на изпълнение се разминават много рано. Тук трябва да се каже това сравнение на това, което е записано с помощта на стартовия панел emrun изходът за отстраняване на грешки с изхода на родния асембли не е напълно механичен процес. Не знам как точно се свързва програма, работеща в браузър emrun, но някои редове в изхода се оказват пренаредени, така че разликата в разликата все още не е причина да се предположи, че траекториите са се разминавали. Като цяло стана ясно, че според инструкциите ljmpl има преход към различни адреси и генерираният байткод е фундаментално различен: единият съдържа инструкция за извикване на помощна функция, другият не. След гугъл инструкциите и изучаване на кода, който превежда тези инструкции, стана ясно, че първо, непосредствено преди него в регистъра cr0 беше направен запис - също с помощта на помощник - който превключи процесора в защитен режим, и второ, че js версията никога не превключи в защитен режим. Но факт е, че друга характеристика на Emscripten е нежеланието му да толерира код като изпълнението на инструкции call в TCI, който всеки указател на функция води до тип long long f(int arg0, .. int arg9) - функциите трябва да се извикват с правилния брой аргументи. Ако това правило бъде нарушено, в зависимост от настройките за отстраняване на грешки, програмата или ще се срине (което е добре), или изобщо ще извика грешна функция (което ще бъде тъжно за отстраняване на грешки). Има и трета опция - активирайте генерирането на обвивки, които добавят / премахват аргументи, но като цяло тези обвивки заемат много място, въпреки факта, че всъщност ми трябват само малко повече от сто обвивки. Само това е много тъжно, но се оказа, че има по-сериозен проблем: в генерирания код на функциите за обвивка аргументите се преобразуват и преобразуват, но понякога функцията с генерираните аргументи не се извиква - добре, точно както в моята реализация на libffi. Тоест някои помощници просто не бяха екзекутирани.

За щастие Qemu има машинночетими списъци с помощници под формата на заглавен файл като

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

Те се използват доста смешно: първо, макросите се предефинират по най-странен начин DEF_HELPER_n, след което се включва helper.h. До степента, в която макросът се разширява в инициализатор на структура и запетая, след което се дефинира масив и вместо елементи - #include <helper.h> В резултат на това най-накрая имах възможност да изпробвам библиотеката на работа pyparsing, и беше написан скрипт, който генерира точно тези обвивки за точно функциите, за които са необходими.

И така, след това процесорът изглеждаше работещ. Изглежда, защото екранът никога не е бил инициализиран, въпреки че memtest86+ успя да работи в родния асембли. Тук е необходимо да се изясни, че блоковият I/O код на Qemu е написан в съпрограми. Emscripten има своя собствена много трудна реализация, но все пак трябваше да се поддържа в кода на Qemu и можете да отстраните грешки в процесора сега: Qemu поддържа опции -kernel, -initrd, -append, с който можете да стартирате Linux или например memtest86+, без изобщо да използвате блокови устройства. Но тук е проблемът: в родния асембли може да се види изходът на Linux ядрото към конзолата с опцията -nographic, и няма изход от браузъра към терминала, откъдето е стартиран emrun, не дойде. Тоест не е ясно: процесорът не работи или графичният изход не работи. И тогава ми хрумна да изчакам малко. Оказа се, че „процесорът не спи, а просто мига бавно“ и след около пет минути ядрото хвърли куп съобщения на конзолата и продължи да виси. Стана ясно, че процесорът като цяло работи и трябва да се поразровим в кода за работа с SDL2. За съжаление, не знам как да използвам тази библиотека, така че на някои места трябваше да действам на случаен принцип. По някое време линията parallel0 мига на екрана на син фон, което навежда на някои мисли. В крайна сметка се оказа, че проблемът е, че Qemu отваря няколко виртуални прозореца в един физически прозорец, между които можете да превключвате с Ctrl-Alt-n: работи в нативната компилация, но не и в Emscripten. След като се отървете от ненужните прозорци с помощта на опции -monitor none -parallel none -serial none и инструкции за принудително преначертаване на целия екран на всеки кадър, всичко изведнъж проработи.

Coroutines

И така, емулацията в браузъра работи, но не можете да стартирате нищо интересно на една дискета в него, защото няма блок I/O - трябва да внедрите поддръжка за съпрограмми. Qemu вече има няколко сърутинни бекенда, но поради естеството на JavaScript и генератора на код Emscripten, не можете просто да започнете да жонглирате със стекове. Изглежда, че „всичко е изчезнало, мазилката се отстранява“, но разработчиците на Emscripten вече са се погрижили за всичко. Това е реализирано доста смешно: нека наречем извикване на функция като това подозрително emscripten_sleep и няколко други, използващи механизма Asyncify, както и извиквания на указател и извиквания към всяка функция, където един от предишните два случая може да се появи по-надолу в стека. И сега, преди всяко подозрително извикване, ще изберем асинхронен контекст и веднага след извикването ще проверим дали е настъпило асинхронно извикване и ако е, ще запазим всички локални променливи в този асинхронен контекст, посочете коя функция за да прехвърлим контрола, когато трябва да продължим изпълнението и да излезем от текущата функция. Това е мястото, където има поле за изследване на ефекта прахосване — за нуждите на продължаване на изпълнението на кода след връщане от асинхронно повикване, компилаторът генерира „закъснения“ на функцията, стартираща след подозрително повикване — по следния начин: ако има n подозрителни извиквания, тогава функцията ще бъде разширена някъде n/2 пъти — това все още е, ако не. Имайте предвид, че след всяко потенциално асинхронно извикване трябва да добавите запазване на някои локални променливи към оригиналната функция. Впоследствие дори трябваше да напиша прост скрипт на Python, който въз основа на даден набор от особено прекомерно използвани функции, които уж „не позволяват на асинхронността да премине през себе си“ (тоест промотирането на стека и всичко, което току-що описах, не работа в тях), показва извиквания чрез указатели, в които функциите трябва да бъдат игнорирани от компилатора, така че тези функции да не се считат за асинхронни. И тогава JS файлове под 60 MB очевидно са твърде много - да кажем поне 30. Въпреки че веднъж настройвах скрипт за асемблиране и случайно изхвърлих опциите за свързване, сред които беше -O3. Пускам генерирания код и Chromium изяжда памет и се срива. Тогава случайно погледнах какво се опитваше да изтегли... Е, какво да кажа, и аз щях да замръзна, ако ме помолиха внимателно да проуча и оптимизирам 500+ MB Javascript.

За съжаление, проверките в кода на библиотеката за поддръжка на Asyncify не бяха напълно приятелски настроени longjmp-s, които се използват в кода на виртуалния процесор, но след малка корекция, която деактивира тези проверки и принудително възстановява контекстите, сякаш всичко е наред, кодът работи. И тогава започна нещо странно: понякога се задействаха проверки в кода за синхронизация - същите, които сриват кода, ако според логиката на изпълнение трябва да бъде блокиран - някой се опита да вземе вече заловен мютекс. За щастие се оказа, че това не е логичен проблем в сериализирания код - просто използвах стандартната функционалност на главния цикъл, предоставена от Emscripten, но понякога асинхронното извикване напълно разгръщаше стека и в този момент се проваляше setTimeout от основния цикъл - по този начин кодът влезе в итерацията на основния цикъл, без да напуска предишната итерация. Пренаписва на безкраен цикъл и emscripten_sleep, и проблемите с mutexes спряха. Кодът дори стана по-логичен - в края на краищата всъщност нямам код, който да подготвя следващия анимационен кадър - процесорът просто изчислява нещо и екранът периодично се актуализира. Проблемите обаче не спират дотук: понякога изпълнението на Qemu просто прекратява безшумно без никакви изключения или грешки. В този момент се отказах от него, но, гледайки напред, ще кажа, че проблемът беше следният: кодът на съпрограммата всъщност не използва setTimeout (или поне не толкова често, колкото си мислите): функция emscripten_yield просто задава флага за асинхронно повикване. Цялата работа е в това emscripten_coroutine_next не е асинхронна функция: вътрешно тя проверява флага, нулира го и прехвърля контрола там, където е необходимо. Тоест популяризирането на стека свършва дотук. Проблемът беше, че поради use-after-free, което се появяваше, когато сърутинният пул беше деактивиран поради факта, че не копирах важен ред код от съществуващия бекенд на съпрограмата, функцията qemu_in_coroutine върна вярно, когато всъщност трябваше да върне фалшиво. Това доведе до обаждане emscripten_yield, над който нямаше никой на стека emscripten_coroutine_next, купчината се разгъна до самия връх, но не setTimeout, както вече казах, не беше изложен.

Генериране на JavaScript код

И ето го всъщност обещаното „връщане на каймата“. Не точно. Разбира се, ако стартираме Qemu в браузъра и Node.js в него, тогава, естествено, след генериране на код в Qemu ще получим напълно грешен JavaScript. Но все пак някаква обратна трансформация.

Първо, малко за това как работи Qemu. Моля да ме извините незабавно: не съм професионален разработчик на Qemu и заключенията ми може да са погрешни на някои места. Както се казва, „мнението на ученика не трябва да съвпада с мнението на учителя, аксиоматиката на Пеано и здравия разум“. Qemu има определен брой поддържани гост архитектури и за всяка има директория като target-i386. Когато изграждате, можете да зададете поддръжка за няколко архитектури за гости, но резултатът ще бъде само няколко двоични файла. Кодът за поддръжка на архитектурата за гост, от своя страна, генерира някои вътрешни операции на Qemu, които TCG (генераторът на малък код) вече превръща в машинен код за архитектурата на хоста. Както е посочено във файла readme, намиращ се в директорията tcg, това първоначално е било част от обикновен C компилатор, който по-късно е адаптиран за JIT. Следователно, например, целевата архитектура по отношение на този документ вече не е гост архитектура, а хост архитектура. В един момент се появи друг компонент - Tiny Code Interpreter (TCI), който трябва да изпълнява код (почти същите вътрешни операции) при липса на генератор на код за конкретна хост архитектура. Всъщност, както се посочва в неговата документация, този интерпретатор може не винаги да работи толкова добре, колкото генератор на JIT код, не само количествено по отношение на скоростта, но и качествено. Въпреки че не съм сигурен, че описанието му е напълно уместно.

Отначало се опитах да направя пълноправен TCG бекенд, но бързо се обърках в изходния код и не съвсем ясно описание на инструкциите за байт код, така че реших да обвия TCI интерпретатора. Това даде няколко предимства:

• когато внедрявате генератор на код, можете да гледате не описанието на инструкциите, а кода на интерпретатора
• можете да генерирате функции не за всеки срещнат блок за превод, но например само след стотното изпълнение
• ако генерираният код се промени (а това изглежда е възможно, съдейки по функциите с имена, съдържащи думата patch), ще трябва да обезсиля генерирания JS код, но поне ще има от какво да го генерирам

Що се отнася до третата точка, не съм сигурен, че корекцията е възможна след първото изпълнение на кода, но първите две точки са достатъчни.

Първоначално кодът беше генериран под формата на голям превключвател на адреса на оригиналната инструкция за байткод, но след това, като си спомних статията за Emscripten, оптимизирането на генерирания JS и повторния цикл, реших да генерирам повече човешки код, особено след като емпирично се оказа, че единствената входна точка в блока за превод е неговият старт. Веднага след казано, след известно време имахме генератор на код, който генерира код с ifs (макар и без цикли). Но лош късмет, той се срина, давайки съобщение, че инструкциите са с някаква неправилна дължина. Освен това последната инструкция на това ниво на рекурсия беше brcond. Добре, ще добавя идентична проверка към генерирането на тази инструкция преди и след рекурсивното извикване и... нито една от тях не беше изпълнена, но след превключването assert те все още се провалиха. В крайна сметка, след като проучих генерирания код, разбрах, че след превключването, указателят към текущата инструкция се презарежда от стека и вероятно е презаписан от генерирания JavaScript код. И така се оказа. Увеличаването на буфера от един мегабайт на десет не доведе до нищо и стана ясно, че генераторът на кодове работи в кръг. Трябваше да проверим дали не сме излезли извън границите на текущата ТБ и ако сме го направили, да издадем адреса на следващата ТБ със знак минус, за да можем да продължим изпълнението. В допълнение, това решава проблема „кои генерирани функции трябва да бъдат анулирани, ако тази част от байт кода се е променила?“ — само функцията, която съответства на този блок за превод, трябва да бъде невалидна. Между другото, въпреки че дебъгвах всичко в Chromium (тъй като използвам Firefox и ми е по-лесно да използвам отделен браузър за експерименти), Firefox ми помогна да коригирам несъвместимостите със стандарта asm.js, след което кодът започна да работи по-бързо в хром.

Пример за генериран код

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

Заключение

И така, работата все още не е завършена, но ми писна тайно да довеждам тази дългосрочна конструкция до съвършенство. Затова реших да публикувам това, с което разполагам за момента. Кодът е малко плашещ на места, защото това е експеримент и не е ясно предварително какво трябва да се направи. Вероятно тогава си струва да издадете нормални атомни ангажименти върху някоя по-модерна версия на Qemu. Междувременно в Gita има тема във формат на блог: за всяко „ниво“, което поне по някакъв начин е преминато, е добавен подробен коментар на руски език. Всъщност тази статия е до голяма степен преразказ на заключението git log.

Можете да опитате всичко тук (пазете се от трафика).

Какво вече работи:

• x86 виртуален процесор работи
• Има работещ прототип на генератор на JIT код от машинен код към JavaScript
• Има шаблон за сглобяване на други 32-битови архитектури за гости: точно сега можете да се възхищавате на Linux за архитектурата MIPS, която замръзва в браузъра на етапа на зареждане

Какво друго можете да направите

• Ускорете емулацията. Дори в режим JIT изглежда, че работи по-бавно от Virtual x86 (но потенциално има цял Qemu с много емулиран хардуер и архитектури)
• За да направя нормален интерфейс - честно казано, не съм добър уеб разработчик, така че засега преработих стандартната обвивка на Emscripten, доколкото мога
• Опитайте се да стартирате по-сложни функции на Qemu - работа в мрежа, миграция на VM и т.н.
• UPS: ще трябва да изпратите няколкото си разработки и доклади за грешки на Emscripten нагоре по веригата, както направиха предишните преносители на Qemu и други проекти. Благодаря им, че успяха имплицитно да използват техния принос към Emscripten като част от моята задача.

Източник: www.habr.com