რამდენიმე წლის წინ Fabrice Bellard დაწერილი jslinux-ის მიერ არის კომპიუტერის ემულატორი JavaScript-ში დაწერილი. ამის შემდეგ სულ ცოტა მეტი იყო ვირტუალური x86. მაგრამ ყველა მათგანი, რამდენადაც მე ვიცი, იყო თარჯიმანი, ხოლო Qemu, რომელიც დაწერილი იყო ბევრად უფრო ადრე იმავე Fabrice Bellard-ის მიერ და, ალბათ, ნებისმიერი თავმოყვარე თანამედროვე ემულატორი, იყენებს 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-ის გამოყენებით. ადრეც გავრცელდა ჭორები, რომ Fabrice Bellard-მა ეს პირადად გააკეთა, მაგრამ ჩვენ ვსაუბრობდით jslinux-ზე, რომელიც, რამდენადაც ვიცი, არის მხოლოდ JS-ში საკმარისი შესრულების ხელით მიღწევის მცდელობა და დაიწერა ნულიდან. მოგვიანებით დაიწერა Virtual x86 - მისთვის გამოქვეყნდა გაუგებარი წყაროები და, როგორც ითქვა, ემულაციის უფრო დიდმა „რეალიზმა“ შესაძლებელი გახადა SeaBIOS-ის გამოყენება როგორც firmware. გარდა ამისა, იყო მინიმუმ ერთი მცდელობა Qemu-ს პორტირება Emscripten-ის გამოყენებით - მე შევეცადე ამის გაკეთება სოკეტის წყვილი, მაგრამ განვითარება, რამდენადაც მე მესმის, გაყინული იყო.

ასე რომ, როგორც ჩანს, აქ არის წყაროები, აქ არის Emscripten - აიღეთ და შეადგინეთ. მაგრამ ასევე არის ბიბლიოთეკები, რომლებზეც კემუა დამოკიდებული და ბიბლიოთეკები, რომლებზეც ეს ბიბლიოთეკებია დამოკიდებული და ა.შ., და ერთ-ერთი მათგანია libffi, რომელ გლიბზეა დამოკიდებული. ინტერნეტში გავრცელდა ჭორები, რომ არსებობდა ერთი ბიბლიოთეკების პორტების დიდ კოლექციაში Emscripten-ისთვის, მაგრამ რატომღაც ძნელი დასაჯერებელი იყო: ჯერ ერთი, ის არ იყო გამიზნული ახალი შემდგენელი, მეორეც, ის ძალიან დაბალი დონის იყო. ბიბლიოთეკა უბრალოდ აიღო და შეადგინოს JS-ში. და ეს არ არის მხოლოდ ასამბლეის ჩანართების საკითხი - ალბათ, თუ მას გადაუხვევთ, ზოგიერთი გამოძახების კონვენციისთვის შეგიძლიათ შექმნათ საჭირო არგუმენტები სტეკზე და გამოიძახოთ ფუნქცია მათ გარეშე. მაგრამ Emscripten არის სახიფათო რამ: იმისათვის, რომ გენერირებული კოდი ბრაუზერის JS ძრავის ოპტიმიზატორისთვის ნაცნობი იყოს, გამოიყენება რამდენიმე ხრიკი. კერძოდ, ეგრეთ წოდებული relooping - კოდის გენერატორი, რომელიც იყენებს მიღებულ LLVM IR-ს, გარკვეული აბსტრაქტული გადასვლის ინსტრუქციებით, ცდილობს ხელახლა შექმნას დამაჯერებელი if-ები, მარყუჟები და ა.შ. აბა, როგორ გადაეცემა არგუმენტები ფუნქციას? ბუნებრივია, როგორც JS ფუნქციების არგუმენტები, ანუ, თუ ეს შესაძლებელია, არა სტეკის მეშვეობით.

თავიდან იყო იდეა უბრალოდ დამეწერა libffi-ს ჩანაცვლება JS-ით და გამეტარებინა სტანდარტული ტესტები, მაგრამ ბოლოს დაბნეული ვიყავი, როგორ შემექმნა ჩემი სათაურის ფაილები ისე, რომ ისინი მუშაობდნენ არსებულ კოდთან - რა ვქნა? როგორც ამბობენ, "დავალებები ასე რთულია "ჩვენ ასე სულელები ვართ?" მე მომიწია libffi-ის სხვა არქიტექტურაზე გადატანა, ასე ვთქვათ - საბედნიეროდ, Emscripten-ს აქვს ორივე მაკრო inline ასამბლეისთვის (ჯავასკრიპტში, დიახ - კარგი, როგორიც არ უნდა იყოს არქიტექტურა, ასე რომ, ასამბლერი) და ფრენის დროს გენერირებული კოდის გაშვების შესაძლებლობა. ზოგადად, პლატფორმაზე დამოკიდებულ libffi ფრაგმენტებთან გარკვეული დროის განმავლობაში შეხების შემდეგ, მივიღე კომპილირებული კოდი და გავუშვი ის პირველ ტესტზე, რომელიც შემხვდა. ჩემდა გასაკვირად, ტესტი წარმატებით დასრულდა. ჩემი გენიალურობით გაოგნებული - ხუმრობა არ არის, ის მუშაობდა პირველივე გაშვებიდან - მე, ჯერ კიდევ არ დავუჯერე თვალებს, წავედი ისევ დამენახა მიღებული კოდი, რათა შემეფასებინა, სად უნდა ამოთხარო შემდეგი. აი, მეორედ გავგიჟდი - ერთადერთი, რაც ჩემს ფუნქციას ვაკეთებ, იყო ffi_call - იტყობინება წარმატებული ზარი. თვითონ ზარი არ ყოფილა. ასე რომ, მე გავგზავნე ჩემი პირველი მოთხოვნილება, რომელმაც გამოასწორა შეცდომა ტესტში, რომელიც ნათელია ნებისმიერი ოლიმპიადის მოსწავლისთვის - რეალური რიცხვები არ უნდა შედარება. a == b და კიდევ როგორ a - b < EPS - მოდულიც უნდა დაიმახსოვროთ, თორემ 0 აღმოჩნდება ძალიან ტოლი 1/3-ის... ზოგადად, libffi-ს გარკვეული პორტი მოვიფიქრე, რომელიც უმარტივეს ტესტებს გადის და რომლითაც glib არის. შედგენილი - გადავწყვიტე, რომ საჭირო იქნებოდა, მოგვიანებით დავამატებ. წინ რომ ვუყურებ, ვიტყვი, რომ, როგორც იქნა, შემდგენელმა საბოლოო კოდში libffi ფუნქციაც კი არ შეიტანა.

მაგრამ, როგორც უკვე ვთქვი, არის გარკვეული შეზღუდვები და სხვადასხვა განუსაზღვრელი ქცევის თავისუფალ გამოყენებას შორის, უფრო უსიამოვნო ფუნქცია დაიმალა - დიზაინის მიხედვით JavaScript არ უჭერს მხარს მრავალძალიანობას საერთო მეხსიერებით. პრინციპში, ამას ჩვეულებრივ შეიძლება ეწოდოს კარგი იდეა, მაგრამ არა კოდის გადასატანად, რომლის არქიტექტურა მიბმულია C ძაფებთან. ზოგადად რომ ვთქვათ, Firefox ატარებს ექსპერიმენტებს საერთო მუშაკების მხარდაჭერაზე და Emscripten-ს აქვს მათთვის თრედის დანერგვა, მაგრამ მე არ მინდოდა მასზე დამოკიდებულება. ნელ-ნელა მომიწია მულტირედინგის ამოძირკვა 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 backend, რომელიც წარმოქმნის მშობლიურ კოდს, მაგრამ იმუშავებს თუ არა მათზე TCI, სხვა საკითხია. თუმცა, როგორც გაირკვა, TCI-ის დოკუმენტაციაში ცალსახად იყო მითითებული მსგავსი რამ. შედეგად, კოდს დაემატა ფუნქციის ზარები შეუსწორებელი წაკითხვისთვის, რომლებიც აღმოაჩინეს Qemu-ს სხვა ნაწილში.

გროვის განადგურება

შედეგად, TCI-ზე უსწორმასწორო წვდომა გამოსწორდა, შეიქმნა მთავარი მარყუჟი, რომელსაც თავის მხრივ უწოდა პროცესორი, RCU და სხვა წვრილმანები. ასე რომ, მე გავუშვი Qemu ოფციით -d exec,in_asm,out_asm, რაც ნიშნავს, რომ თქვენ უნდა თქვათ რომელი კოდის ბლოკები სრულდება და ასევე გადაცემის დროს დაწეროთ რა იყო სტუმრის კოდი, რა გახდა ჰოსტის კოდი (ამ შემთხვევაში ბაიტიკოდი). ის იწყებს, ახორციელებს რამდენიმე თარგმანის ბლოკს, წერს გამართვის შეტყობინებას, რომელიც დავტოვე, რომ RCU ახლა დაიწყება და... ავარია abort() ფუნქციის შიგნით free(). ფუნქციის შეფერხებით free() ჩვენ მოვახერხეთ, რომ გროვის ბლოკის სათაურში, რომელიც დევს გამოყოფილი მეხსიერების წინა რვა ბაიტში, ბლოკის ზომის ან მსგავსი რამის ნაცვლად, იყო ნაგავი.

გროვის განადგურება - რა საყვარელია... ასეთ შემთხვევაში არის სასარგებლო წამალი - (თუ შესაძლებელია) იგივე წყაროებიდან, აკრიფეთ მშობლიური ბინარი და გაუშვით ვალგრინდის ქვეშ. გარკვეული პერიოდის შემდეგ ბინარი მზად იყო. მე გავუშვი იგივე ოფციებით - ის იშლება ინიციალიზაციის დროსაც კი, სანამ რეალურად მიაღწევს შესრულებას. უსიამოვნოა, რა თქმა უნდა - როგორც ჩანს, წყაროები არ იყო ზუსტად იგივე, რაც გასაკვირი არ არის, რადგან კონფიგურაციამ ოდნავ განსხვავებული ვარიანტები გამოავლინა, მაგრამ მე მაქვს Valgrind - ჯერ გამოვასწორებ ამ შეცდომას და შემდეგ, თუ გამიმართლა , გამოჩნდება ორიგინალი. მე იგივეს ვატარებ Valgrind-ის პირობებში... Y-y-y, y-y-y, Uh-uh, დაიწყო, ნორმალურად გაიარა ინიციალიზაცია და გადავიდა თავდაპირველ შეცდომაზე ერთი გაფრთხილების გარეშე მეხსიერების არასწორი წვდომის შესახებ, რომ აღარაფერი ვთქვათ დაცემაზე. ცხოვრებამ, როგორც ამბობენ, არ მომიმზადა ამისთვის - კრახი პროგრამა წყვეტს კრახს, როდესაც ამოქმედდა Walgrind-ის ქვეშ. რა იყო ეს არის საიდუმლო. ჩემი ჰიპოთეზა არის, რომ ერთხელ მიმდინარე ინსტრუქციის სიახლოვეს ინიციალიზაციის დროს ავარიის შემდეგ, gdb აჩვენა სამუშაო memset-a მოქმედი მაჩვენებლით რომელიმეს გამოყენებით mmx, ან xmm რეგისტრირდება, მაშინ ალბათ ეს იყო ერთგვარი გასწორების შეცდომა, თუმცა ჯერ კიდევ ძნელი დასაჯერებელია.

კარგი, როგორც ჩანს, ვალგრინდი აქ არ ეხმარება. და აქ დაიწყო ყველაზე ამაზრზენი რამ - ყველაფერი თითქოს იწყება, მაგრამ ავარია აბსოლუტურად გაურკვეველი მიზეზების გამო იმ მოვლენის გამო, რომელიც შეიძლებოდა მომხდარიყო მილიონობით ინსტრუქციის წინ. კარგა ხანს გაურკვეველი იყო როგორ მიახლოებოდა. ბოლოს მაინც მომიწია დაჯდომა და გამართვა. დაბეჭდვა, რომლითაც სათაური იყო გადაწერილი, აჩვენა, რომ ის არ ჰგავს რიცხვს, არამედ რაღაც ორობით მონაცემს. და აი, ეს ორობითი სტრიქონი ნაპოვნი იქნა BIOS ფაილში - ანუ, ახლა უკვე შესაძლებელი იყო გონივრული დარწმუნებით ეთქვა, რომ ეს იყო ბუფერის გადადინება და ცხადია, რომ ის ამ ბუფერზე იყო დაწერილი. კარგი, მაშინ მსგავსი რამ - Emscripten-ში, საბედნიეროდ, არ არის მისამართების სივრცის რანდომიზაცია, მასში არც ხვრელებია, ასე რომ თქვენ შეგიძლიათ დაწეროთ სადღაც კოდის შუაში, რომ მონაცემები გამოიყვანოთ კურსორზე ბოლო გაშვებიდან. შეხედეთ მონაცემებს, შეხედეთ მაჩვენებელს და, თუ ის არ შეცვლილა, მიიღეთ საფიქრალი. მართალია, ნებისმიერი ცვლილების შემდეგ ბმულს რამდენიმე წუთი სჭირდება, მაგრამ რა შეგიძლიათ გააკეთოთ? შედეგად, ნაპოვნი იქნა კონკრეტული ხაზი, რომელიც კოპირებდა BIOS-ს დროებითი ბუფერიდან სტუმრის მეხსიერებაში - და, მართლაც, ბუფერში არ იყო საკმარისი ადგილი. ამ უცნაური ბუფერული მისამართის წყაროს პოვნამ გამოიწვია ფუნქცია qemu_anon_ram_alloc ფაილში oslib-posix.c - ლოგიკა იყო ასეთი: ზოგჯერ შეიძლება სასარგებლო იყოს მისამართის გასწორება 2 მბ ზომის უზარმაზარ გვერდზე, ამისათვის ჩვენ ვიკითხავთ mmap ჯერ კიდევ ცოტა, შემდეგ კი ზედმეტს დავაბრუნებთ დახმარებით munmap. და თუ ასეთი გასწორება არ არის საჭირო, მაშინ ჩვენ მივუთითებთ შედეგს 2 მბ-ის ნაცვლად 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) - ფუნქციები უნდა გამოიძახონ არგუმენტების სწორი რაოდენობით. თუ ეს წესი დაირღვა, გამართვის პარამეტრებიდან გამომდინარე, პროგრამა ან იშლება (რაც კარგია) ან საერთოდ გამოიძახებს არასწორ ფუნქციას (რაც სამწუხარო იქნება გამართვა). ასევე არის მესამე ვარიანტი - ჩართეთ შეფუთვების გენერაცია, რომლებიც ამატებენ/აშორებენ არგუმენტებს, მაგრამ მთლიანობაში ეს შეფუთვები დიდ ადგილს იკავებს, მიუხედავად იმისა, რომ სინამდვილეში მე მჭირდება მხოლოდ ასზე ცოტა მეტი შეფუთვა. მარტო ეს ძალიან სამწუხაროა, მაგრამ აღმოჩნდა უფრო სერიოზული პრობლემა: wrapper ფუნქციების გენერირებულ კოდში არგუმენტები გარდაიქმნა და გარდაიქმნა, მაგრამ ზოგჯერ ფუნქცია გენერირებული არგუმენტებით არ იყო გამოძახებული - ისე, ისევე, როგორც ჩემი 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> შედეგად, საბოლოოდ მომეცა საშუალება გამომეცადა ბიბლიოთეკა სამსახურში პიპარსინგიდა დაიწერა სკრიპტი, რომელიც წარმოქმნის ზუსტად იმ შეფუთვებს ზუსტად იმ ფუნქციებისთვის, რისთვისაც საჭიროა.

ასე რომ, ამის შემდეგ, როგორც ჩანს, პროცესორი მუშაობდა. როგორც ჩანს, ეს იმიტომ ხდება, რომ ეკრანი არასოდეს ყოფილა ინიციალიზებული, თუმცა memtest86+-მა შეძლო გაშვება მშობლიურ ასამბლეაში. აქვე უნდა განვმარტოთ, რომ Qemu ბლოკის I/O კოდი იწერება კორუტინებით. Emscripten-ს აქვს საკუთარი ძალიან რთული იმპლემენტაცია, მაგრამ ის მაინც საჭირო იყო Qemu კოდის მხარდაჭერით და შეგიძლიათ პროცესორის გამართვა ახლა: Qemu მხარს უჭერს ვარიანტებს -kernel, -initrd, -append, რომლითაც შეგიძლიათ ჩატვირთოთ Linux ან, მაგალითად, memtest86+, ბლოკის მოწყობილობების საერთოდ გამოყენების გარეშე. მაგრამ აქ არის პრობლემა: მშობლიურ ასამბლეაში შეგიძლიათ ნახოთ Linux-ის ბირთვის გამომავალი კონსოლში ოფციით -nographic, და არ არის გამომავალი ბრაუზერიდან ტერმინალამდე, საიდანაც ის იყო გაშვებული emrun, არ მოვიდა. ანუ, გაუგებარია: პროცესორი არ მუშაობს ან გრაფიკული გამომავალი არ მუშაობს. შემდეგ კი აზრად მომივიდა, რომ ცოტა დაველოდე. აღმოჩნდა, რომ "პროცესორს არ სძინავს, არამედ უბრალოდ ნელა ციმციმებს" და დაახლოებით ხუთი წუთის შემდეგ ბირთვმა გადააგდო შეტყობინებების თაიგული კონსოლზე და განაგრძო დაკიდება. გაირკვა, რომ პროცესორი, ზოგადად, მუშაობს და ჩვენ უნდა ჩავწეროთ კოდი SDL2-თან მუშაობისთვის. სამწუხაროდ, არ ვიცი როგორ გამოვიყენო ეს ბიბლიოთეკა, ამიტომ ზოგიერთ ადგილას შემთხვევით მომიწია მოქმედება. რაღაც მომენტში, ლურჯ ფონზე ეკრანზე პარალელურად0 ხაზი გაბრწყინდა, რაც რამდენიმე აზრს გვთავაზობდა. საბოლოო ჯამში, აღმოჩნდა, რომ პრობლემა ის იყო, რომ Qemu ხსნის რამდენიმე ვირტუალურ ფანჯარას ერთ ფიზიკურ ფანჯარაში, რომელთა შორის შეგიძლიათ გადახვიდეთ Ctrl-Alt-n გამოყენებით: ის მუშაობს მშობლიურ build-ში, მაგრამ არა Emscripten-ში. არასაჭირო ფანჯრების მოშორების შემდეგ ოფციების გამოყენებით -monitor none -parallel none -serial none და ინსტრუქციები იძულებით გადახაზეთ მთელი ეკრანი თითოეულ ჩარჩოზე, ყველაფერი მოულოდნელად მუშაობდა.

კორუტინები

ასე რომ, ბრაუზერში ემულაცია მუშაობს, მაგრამ თქვენ არ შეგიძლიათ მასში რაიმე საინტერესო ერთჯერადი ფლოპის გაშვება, რადგან არ არის I/O ბლოკი - თქვენ გჭირდებათ კორუტინის მხარდაჭერა. Qemu-ს უკვე აქვს რამდენიმე კორუტინის უკანა ნაწილი, მაგრამ JavaScript-ისა და Emscripten კოდის გენერატორის ბუნების გამო, თქვენ არ შეგიძლიათ უბრალოდ დაიწყოთ დატების ჟონგლირება. როგორც ჩანს, "ყველაფერი წავიდა, თაბაშირი ამოღებულია", მაგრამ Emscripten-ის დეველოპერებმა უკვე იზრუნეს ყველაფერზე. ეს საკმაოდ სასაცილოდ არის განხორციელებული: მოდით, ფუნქციის გამოძახება დავარქვათ საეჭვო emscripten_sleep და რამდენიმე სხვა, რომლებიც იყენებენ Asyncify მექანიზმს, ასევე მაჩვენებლის ზარებს და ზარებს ნებისმიერ ფუნქციაზე, სადაც წინა ორი შემთხვევა შეიძლება მოხდეს სტეკის ქვემოთ. ახლა კი, ყოველი საეჭვო ზარის წინ, ჩვენ ვირჩევთ ასინქრონულ კონტექსტს და ზარის შემდეგ დაუყოვნებლივ შევამოწმებთ მოხდა თუ არა ასინქრონული ზარი და თუ მოხდა, ჩვენ ყველა ლოკალურ ცვლადს შევინახავთ ამ ასინქრონულ კონტექსტში, მიუთითეთ რომელი ფუნქცია. გადავიტანოთ კონტროლი მაშინ, როცა გვჭირდება შესრულების გაგრძელება და მიმდინარე ფუნქციიდან გამოსვლა. სწორედ აქ არის ეფექტის შესწავლის შესაძლებლობა გაფლანგვა — ასინქრონული ზარიდან დაბრუნების შემდეგ კოდის შესრულების გასაგრძელებლად, შემდგენელი წარმოქმნის საეჭვო ზარის შემდეგ დაწყებული ფუნქციის „სტუბებს“ - ასე: თუ არის n საეჭვო ზარი, მაშინ ფუნქცია გაფართოვდება სადღაც n/2. ჯერ — ეს მაინც არის, თუ არა. გაითვალისწინეთ, რომ ყოველი პოტენციურად ასინქრონული ზარის შემდეგ, თქვენ უნდა დაამატოთ რამდენიმე ადგილობრივი ცვლადის შენახვა თავდაპირველ ფუნქციაში. შემდგომში, პითონში მარტივი სკრიპტის დაწერაც კი მომიწია, რომელიც, განსაკუთრებით ზედმეტად გამოყენებული ფუნქციების მოცემულ ჯგუფზე დაფუძნებული, რომლებიც სავარაუდოდ „არ აძლევენ ასინქრონიის გავლის საშუალებას“ (ანუ სტეკის პრომოუშენი და ყველაფერი, რაც ახლა აღვწერე, არ არის მუშაობა მათში), მიუთითებს ზარებს პოინტერების საშუალებით, რომლებშიც ფუნქციები უნდა იყოს იგნორირებული კომპილერის მიერ ისე, რომ ეს ფუნქციები არ ჩაითვალოს ასინქრონულად. შემდეგ კი 60 მბ-ზე ნაკლები JS ფაილები აშკარად ძალიან ბევრია - ვთქვათ მინიმუმ 30. თუმცა, ერთხელ მე ვაყენებდი ასამბლეის სკრიპტს და შემთხვევით გავყარე ლინკერის ვარიანტები, რომელთა შორის იყო -O3. მე ვაწარმოებ გენერირებულ კოდს და Chromium ჭამს მეხსიერებას და იშლება. მერე შემთხვევით შევხედე რის გადმოტვირთვას ცდილობდა... აბა, რა ვთქვა, მეც გავიყინებოდი, 500+ MB Javascript-ის გააზრებულად შესწავლა და ოპტიმიზაცია რომ მთხოვეს.

სამწუხაროდ, Asyncify-ის მხარდაჭერის ბიბლიოთეკის კოდში შემოწმებები არ იყო სრულიად მეგობრული longjmp-ები, რომლებიც გამოიყენება ვირტუალური პროცესორის კოდში, მაგრამ მცირე პაჩის შემდეგ, რომელიც გამორთავს ამ შემოწმებებს და ძალით აღადგენს კონტექსტებს, თითქოს ყველაფერი კარგად იყო, კოდი მუშაობდა. შემდეგ კი უცნაური რამ დაიწყო: ხანდახან იწყებოდა შემოწმებები სინქრონიზაციის კოდში - იგივე, რაც არღვევს კოდს, თუ, შესრულების ლოგიკის მიხედვით, ის უნდა დაიბლოკოს - ვიღაც ცდილობდა უკვე დაჭერილი მუტექსის დაჭერას. საბედნიეროდ, ეს არ იყო ლოგიკური პრობლემა სერიულ კოდში - მე უბრალოდ ვიყენებდი Emscripten-ის მიერ მოწოდებულ სტანდარტულ მთავარ მარყუჟის ფუნქციას, მაგრამ ზოგჯერ ასინქრონული ზარი მთლიანად ხსნიდა დასტას და იმ მომენტში ის ვერ მოხერხდებოდა. setTimeout მთავარი მარყუჟიდან - ამრიგად, კოდი შევიდა მთავარ მარყუჟის გამეორებაში წინა გამეორების დატოვების გარეშე. გადაწერა უსასრულო მარყუჟზე და emscripten_sleepდა მუტექსებთან დაკავშირებული პრობლემები შეჩერდა. კოდი კიდევ უფრო ლოგიკური გახდა - ბოლოს და ბოლოს, მე არ მაქვს კოდი, რომელიც ამზადებს შემდეგ ანიმაციურ ჩარჩოს - პროცესორი უბრალოდ ითვლის რაღაცას და ეკრანი პერიოდულად განახლდება. თუმცა, პრობლემები აქ არ ჩერდებოდა: ხანდახან კემუს აღსრულება უბრალოდ ჩუმად წყდებოდა ყოველგვარი გამონაკლისის და შეცდომის გარეშე. იმ მომენტში მე უარი ვთქვი მასზე, მაგრამ, წინ ვიხედები, ვიტყვი, რომ პრობლემა ეს იყო: კორუტინის კოდი, ფაქტობრივად, არ იყენებს setTimeout (ან თუნდაც არც ისე ხშირად, როგორც თქვენ ფიქრობთ): ფუნქცია emscripten_yield უბრალოდ აყენებს ასინქრონული ზარის დროშას. მთელი საქმე იმაშია emscripten_coroutine_next არ არის ასინქრონული ფუნქცია: შიგნიდან ის ამოწმებს დროშას, აღადგენს მას და გადასცემს კონტროლს იქ, სადაც საჭიროა. ანუ სტეკის დაწინაურება აქ მთავრდება. პრობლემა ის იყო, რომ გამოყენების შემდეგ უფასო, რომელიც გამოჩნდა, როდესაც კორუტინის ფონდი გამორთული იყო იმის გამო, რომ მე არ დავაკოპირე კოდის მნიშვნელოვანი ხაზი არსებული კორუტინის ფონიდან, ფუნქცია qemu_in_coroutine დაბრუნდა true, როდესაც სინამდვილეში ის უნდა დაბრუნებულიყო false. ამან გამოიწვია ზარი emscripten_yield, რომლის ზემოთაც დასტაზე არავინ იყო emscripten_coroutine_next, დასტა გაიშალა ზევით, მაგრამ არა setTimeoutროგორც უკვე ვთქვი, არ იყო გამოფენილი.

JavaScript კოდის გენერირება

და აი, ფაქტობრივად, არის დაპირებული „დაფქული ხორცის უკან დაბრუნება“. Ნამდვილად არ. რა თქმა უნდა, თუ ბრაუზერში ჩავუშვით Qemu-ს და მასში Node.js-ს, მაშინ, ბუნებრივია, Qemu-ში კოდის გენერირების შემდეგ მივიღებთ სრულიად არასწორ JavaScript-ს. მაგრამ მაინც, რაღაც საპირისპირო ტრანსფორმაცია.

პირველი, ცოტა იმაზე, თუ როგორ მუშაობს Qemu. გთხოვთ, დაუყოვნებლივ მაპატიოთ: მე არ ვარ პროფესიონალი Qemu დეველოპერი და ჩემი დასკვნები შეიძლება იყოს მცდარი ზოგან. როგორც ამბობენ, „მოსწავლის აზრი არ უნდა ემთხვეოდეს მასწავლებლის აზრს, პეანოს აქსიომატიკას და საღი აზრი“. Qemu-ს აქვს გარკვეული რაოდენობის მხარდაჭერილი სტუმრის არქიტექტურა და თითოეულისთვის არის მსგავსი დირექტორია target-i386. მშენებლობისას შეგიძლიათ მიუთითოთ რამდენიმე სტუმარი არქიტექტურის მხარდაჭერა, მაგრამ შედეგი იქნება მხოლოდ რამდენიმე ბინარი. სტუმარი არქიტექტურის მხარდაჭერის კოდი, თავის მხრივ, წარმოქმნის ზოგიერთ შიდა Qemu ოპერაციებს, რომლებსაც TCG (Tiny Code Generator) უკვე აქცევს მასპინძლის არქიტექტურის მანქანურ კოდად. როგორც tcg დირექტორიაში მდებარე readme ფაილშია ნათქვამი, ის თავდაპირველად იყო ჩვეულებრივი C შემდგენელის ნაწილი, რომელიც მოგვიანებით ადაპტირებული იყო JIT-ისთვის. ამიტომ, მაგალითად, სამიზნე არქიტექტურა ამ დოკუმენტის თვალსაზრისით აღარ არის სტუმრის არქიტექტურა, არამედ მასპინძელი არქიტექტურა. რაღაც მომენტში გამოჩნდა კიდევ ერთი კომპონენტი - Tiny Code Interpreter (TCI), რომელმაც უნდა შეასრულოს კოდი (თითქმის იგივე შიდა ოპერაციები) კონკრეტული ჰოსტის არქიტექტურისთვის კოდის გენერატორის არარსებობის შემთხვევაში. სინამდვილეში, როგორც მის დოკუმენტაციაში წერია, ეს თარჯიმანი შეიძლება ყოველთვის არ მუშაობდეს ისე, როგორც JIT კოდის გენერატორი, არა მხოლოდ რაოდენობრივად, არამედ ხარისხობრივად. თუმცა არ ვარ დარწმუნებული, რომ მისი აღწერა სრულად აქტუალურია.

თავიდან ვცადე სრულფასოვანი TCG backend-ის გაკეთება, მაგრამ სწრაფად დავბნეულიყავი წყაროს კოდში და ბაიტეკოდის ინსტრუქციების არც თუ ისე მკაფიო აღწერაში, ამიტომ გადავწყვიტე შემეკრა TCI თარჯიმანი. ამან რამდენიმე უპირატესობა მისცა:

• კოდის გენერატორის დანერგვისას შეგიძლიათ შეხედოთ არა ინსტრუქციების აღწერას, არამედ თარჯიმნის კოდს
• თქვენ შეგიძლიათ შექმნათ ფუნქციები არა ყველა თარგმანის ბლოკისთვის, არამედ, მაგალითად, მხოლოდ მეასე შესრულების შემდეგ
• თუ გენერირებული კოდი შეიცვლება (და ეს შესაძლებელია, თუ ვიმსჯელებთ ფუნქციების მიხედვით სახელებით, რომლებიც შეიცავს სიტყვა პაჩს), მე დამჭირდება გენერირებული JS კოდის გაუქმება, მაგრამ მაინც მექნება მისი რეგენერაცია.

რაც შეეხება მესამე პუნქტს, დარწმუნებული არ ვარ, რომ დაყენება შესაძლებელია კოდის პირველად შესრულების შემდეგ, მაგრამ პირველი ორი წერტილი საკმარისია.

თავდაპირველად, კოდი გენერირებული იყო დიდი გადამრთველის სახით ორიგინალური ბაიტეკოდის ინსტრუქციის მისამართზე, მაგრამ შემდეგ, როდესაც გავიხსენე სტატია Emscripten-ის, გენერირებული JS-ის ოპტიმიზაციისა და გადახვევის შესახებ, გადავწყვიტე მეტი ადამიანის კოდი გენერირება, მით უმეტეს, რომ ემპირიულად ის აღმოჩნდა, რომ თარგმანის ბლოკში ერთადერთი შესვლის წერტილი მისი დაწყებაა. ცოტა ხნის შემდეგ, ჩვენ გვქონდა კოდის გენერატორი, რომელიც ქმნიდა კოდს if-ებით (თუმცა მარყუჟების გარეშე). მაგრამ ცუდი იღბალი, ის ჩამოვარდა, რაც აგზავნიდა შეტყობინებას, რომ ინსტრუქციები იყო არასწორი სიგრძის. უფრო მეტიც, ბოლო ინსტრუქცია ამ რეკურსიის დონეზე იყო brcond. კარგი, მე დავამატებ იდენტურ შემოწმებას ამ ინსტრუქციის თაობაზე რეკურსიული ზარის დაწყებამდე და შემდეგ და... არც ერთი მათგანი არ შესრულებულა, მაგრამ assert switch-ის შემდეგ ისინი მაინც ვერ მოხერხდა. საბოლოო ჯამში, გენერირებული კოდის შესწავლის შემდეგ მივხვდი, რომ გადართვის შემდეგ, მიმდინარე ინსტრუქციის მაჩვენებელი ხელახლა იტვირთება დასტადან და სავარაუდოდ გადაწერილია გენერირებული 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-ს უფრო თანამედროვე ვერსიის თავზე. იმავდროულად, გიტაში არის თემა ბლოგის ფორმატში: ყოველი "დონისთვის", რომელიც რაღაცნაირად მაინც გაიარა, დამატებულია დეტალური კომენტარი რუსულ ენაზე. სინამდვილეში, ეს სტატია დიდწილად არის დასკვნის ხელახალი მოთხრობა git log.

შეგიძლიათ სცადოთ ეს ყველაფერი აქ (უფრთხილდით მოძრაობას).

რაც უკვე მუშაობს:

• x86 ვირტუალური პროცესორი მუშაობს
• არსებობს JIT კოდის გენერატორის სამუშაო პროტოტიპი მანქანის კოდიდან JavaScript-მდე
• არსებობს სხვა 32-ბიტიანი სტუმრის არქიტექტურის აწყობის შაბლონი: ახლავე შეგიძლიათ აღფრთოვანებულიყავით Linux-ით MIPS არქიტექტურით ბრაუზერში ჩატვირთვის ეტაპზე გაყინვისთვის.

კიდევ რა შეგიძლია გააკეთო

• ემულაციის დაჩქარება. JIT რეჟიმშიც კი, როგორც ჩანს, ის უფრო ნელა მუშაობს, ვიდრე Virtual x86 (მაგრამ პოტენციურად არსებობს მთელი Qemu ბევრი ემულირებული აპარატურით და არქიტექტურით)
• ნორმალური ინტერფეისის შესაქმნელად - გულწრფელად რომ ვთქვათ, მე არ ვარ კარგი ვებ დეველოპერი, ასე რომ, ახლა მე შევქმენი სტანდარტული Emscripten გარსი, როგორც შემიძლია
• შეეცადეთ გაუშვათ უფრო რთული Qemu ფუნქციები - ქსელი, VM მიგრაცია და ა.შ.
• UPD: თქვენ უნდა წარადგინოთ თქვენი რამდენიმე განვითარება და შეცდომების შესახებ მოხსენებები Emscripten-ში, როგორც ამას აკეთებდნენ Qemu-ს და სხვა პროექტების წინა პორტერები. მადლობა მათ, რომ შეძლეს უპირობოდ გამოიყენონ თავიანთი წვლილი Emscripten-ში, როგორც ჩემი ამოცანის ნაწილი.

წყარო: www.habr.com