QEMU.js: ახლა სერიოზული და WASM-ით

ერთხელ გასართობად გადავწყვიტე დაამტკიცეთ პროცესის შექცევადობა და ისწავლეთ როგორ შექმნათ JavaScript (უფრო ზუსტად, Asm.js) მანქანის კოდიდან. ექსპერიმენტისთვის QEMU აირჩიეს და რამდენიმე ხნის შემდეგ Habr-ზე დაიწერა სტატია. კომენტარებში მირჩიეს პროექტის გადაკეთება WebAssembly-ში და თავიც დამეტოვებინა თითქმის დასრულებულია რატომღაც არ მინდოდა პროექტი... მუშაობა მიდიოდა, მაგრამ ძალიან ნელა და ახლა, ახლახანს გამოჩნდა ის სტატია კომენტარი თემაზე "მაშ როგორ დასრულდა ეს ყველაფერი?" ჩემი დეტალური პასუხის საპასუხოდ, მე გავიგე "ეს სტატიას ჰგავს". კარგი, თუ შეიძლება, იქნება სტატია. იქნებ ვინმეს გამოადგეს. მისგან მკითხველი გაიგებს რამდენიმე ფაქტს QEMU კოდის გენერირების backend-ების დიზაინის შესახებ, ასევე როგორ უნდა დაწეროს Just-in-Time კომპილერი ვებ აპლიკაციისთვის.

ამოცანები

ვინაიდან მე უკვე ვისწავლე, როგორმე „როგორმე“ გავატანო QEMU JavaScript-ზე, ამჯერად გადავწყვიტე ეს გონივრულად გამეკეთებინა და ძველი შეცდომები არ გამემეორებინა.

შეცდომა ნომერი პირველი: განშტოება წერტილიდან გამოშვებიდან

ჩემი პირველი შეცდომა იყო ჩემი ვერსიის 2.4.1-ის ზემორე ვერსიიდან გათიშვა. მაშინ კარგი იდეა მომეჩვენა: თუ წერტილის გამოშვება არსებობს, მაშინ ის ალბათ უფრო სტაბილურია, ვიდრე მარტივი 2.4 და მით უმეტეს, ფილიალი master. და რადგან ვგეგმავდი საკუთარი შეცდომების საკმაოდ დიდი რაოდენობის დამატებას, სხვისი საერთოდ არ მჭირდებოდა. ალბათ ასე გამოვიდა. მაგრამ აქ არის საქმე: QEMU არ დგას და რაღაც მომენტში გამოაცხადეს გენერირებული კოდის 10 პროცენტით ოპტიმიზაციაც კი.„ჰო, ახლა გაყინვას ვაპირებ“ გავიფიქრე და გავფუჭდი. აქ ჩვენ გვჭირდება დიგრესიის გაკეთება: QEMU.js-ის ერთნაკადიანი ბუნების გამო და იმ ფაქტის გამო, რომ ორიგინალური QEMU არ გულისხმობს მრავალ ძაფების არარსებობას (ანუ რამდენიმე დაუკავშირებელი კოდის ბილიკის ერთდროულად მუშაობის უნარს, და არა მხოლოდ "გამოიყენე ყველა ბირთვი") არის მისთვის გადამწყვეტი მნიშვნელობა, ძაფების ძირითადი ფუნქციები უნდა გამომეტანა, რომ შემეძლო გარედან გამოძახება. ამან შექმნა ბუნებრივი პრობლემები შერწყმის დროს. თუმცა, ის ფაქტი, რომ ზოგიერთი ცვლილება ფილიალიდან master, რომელთანაც ვცდილობდი ჩემი კოდის შერწყმას, ასევე ალუბლის არჩევა პუნქტის გამოშვებაში (და, შესაბამისად, ჩემს ფილიალში) ასევე, ალბათ, არ იქნებოდა დამატებული მოხერხებულობა.

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

შეცდომა ნომერი მეორე: TLP მეთოდოლოგია

არსებითად, ეს არ არის შეცდომა, ზოგადად, ეს არის მხოლოდ პროექტის შექმნის მახასიათებელი სრული გაუგებრობის პირობებში, როგორც „სად და როგორ გადავიდეთ?“ და ზოგადად „მოვაღწევთ? ამ პირობებში მოუხერხებელი პროგრამირება გამართლებული ვარიანტი იყო, მაგრამ, ბუნებრივია, არ მინდოდა ამის ზედმეტად გამეორება. ამჯერად მინდოდა გამეკეთებინა ეს გონივრულად: ატომური ვალდებულებები, ცნობიერი კოდის ცვლილებები (და არა „შემთხვევითი სიმბოლოების შეკრება, სანამ არ შედგენილი იქნება (გაფრთხილებებით)“, როგორც ერთხელ ლინუს ტორვალდსმა თქვა ვინმეზე, ვიკიციტატის მიხედვით) და ა.შ.

შეცდომა ნომერი მესამე: წყალში ჩასვლა ფორდის ცოდნის გარეშე

მე ჯერ კიდევ არ მომიშორებია ეს მთლიანად, მაგრამ ახლა გადავწყვიტე არ გავყოლოდი უმცირესი წინააღმდეგობის გზას და გავაკეთო ეს „გაზრდილი გზით“, კერძოდ, დავწერო ჩემი TCG backend ნულიდან, რათა არ რომ მოგვიანებით უნდა თქვა: "დიახ, ეს, რა თქმა უნდა, ნელა, მაგრამ მე ვერ ვაკონტროლებ ყველაფერს - ასე წერია TCI..." უფრო მეტიც, ეს თავიდან აშკარა გამოსავალად ჩანდა, ვინაიდან მე ვქმნი ორობით კოდს. როგორც ამბობენ, „გენტი შეიკრიბაу, მაგრამ არა ის”: კოდი, რა თქმა უნდა, ორობითია, მაგრამ მასზე კონტროლი არ შეიძლება უბრალოდ გადაეცეს - ის პირდაპირ ბრაუზერში უნდა გადაიტანოს კომპილაციისთვის, რის შედეგადაც მიიღება გარკვეული ობიექტი JS სამყაროდან, რომელსაც ჯერ კიდევ სჭირდება სადმე გადარჩენა. თუმცა, ნორმალურ RISC არქიტექტურებზე, რამდენადაც მე მესმის, ტიპიური სიტუაციაა ინსტრუქციის ქეშის მკაფიოდ გადატვირთვა რეგენერირებული კოდისთვის - თუ ეს არ არის ის, რაც ჩვენ გვჭირდება, მაშინ, ნებისმიერ შემთხვევაში, ის ახლოსაა. გარდა ამისა, ჩემი ბოლო მცდელობიდან გავიგე, რომ კონტროლი, როგორც ჩანს, არ არის გადაცემული თარგმანის ბლოკის შუაში, ასე რომ, ჩვენ ნამდვილად არ გვჭირდება ბაიტეკოდი ინტერპრეტირებული ნებისმიერი ოფსეტურიდან, და ჩვენ შეგვიძლია მისი გენერირება უბრალოდ ტუბერკულოზის ფუნქციიდან. .

მოვიდნენ და დაარტყეს

მიუხედავად იმისა, რომ კოდის გადაწერა დავიწყე ჯერ კიდევ ივლისში, ჯადოსნური დარტყმა შეუმჩნევლად გაჩნდა: ჩვეულებრივ, წერილები GitHub-დან მოდის როგორც შეტყობინებები Issues და Pull მოთხოვნების პასუხების შესახებ, მაგრამ აქ, მოულოდნელად ხსენება თემაში Binaryen როგორც qemu backend კონტექსტში, ”მან რაღაც ისეთი გააკეთა, იქნებ რამე თქვას”. ჩვენ ვსაუბრობდით Emscripten-ის შესაბამისი ბიბლიოთეკის გამოყენებაზე ბინარიენი WASM JIT-ის შესაქმნელად. ისე, მე ვთქვი, რომ თქვენ გაქვთ Apache 2.0 ლიცენზია იქ და QEMU მთლიანად განაწილებულია GPLv2-ის ქვეშ და ისინი არ არიან ძალიან თავსებადი. მოულოდნელად აღმოჩნდა, რომ ლიცენზია შეიძლება იყოს გაასწორეთ როგორმე (არ ვიცი: იქნებ შეიცვალოს, შესაძლოა ორმაგი ლიცენზირება, შეიძლება სხვა რამ...). ამან, რა თქმა უნდა, გამახარა, რადგან იმ დროისთვის უკვე ყურადღებით დავაკვირდი ორობითი ფორმატი WebAssembly და რაღაცნაირად სევდიანი და გაუგებარი ვიყავი. ასევე არსებობდა ბიბლიოთეკა, რომელიც შთანთქავდა ძირითად ბლოკებს გარდამავალი გრაფიკით, აწარმოებდა ბაიტეკოდს და საჭიროების შემთხვევაში აწარმოებდა მას თავად თარჯიმანში.

მერე კიდევ იყო წერილი QEMU საფოსტო სიაში, მაგრამ ეს უფრო ეხება კითხვას, "ვის სჭირდება ეს მაინც?" Და ეს არის მოულოდნელად, აღმოჩნდა საჭირო. მინიმუმ, შეგიძლიათ გააფუჭოთ შემდეგი გამოყენების შესაძლებლობები, თუ ის მეტ-ნაკლებად სწრაფად მუშაობს:

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

ბრაუზერის Runtime მახასიათებლები

როგორც უკვე ვთქვი, QEMU არის მიბმული მულტირედირებასთან, მაგრამ ბრაუზერს ეს არ აქვს. ანუ, არა... თავიდან ის საერთოდ არ არსებობდა, შემდეგ გამოჩნდა WebWorkers - რამდენადაც მე მესმის, ეს არის მრავალძალიანი გზავნილების გავლის საფუძველზე გაზიარებული ცვლადების გარეშე. ბუნებრივია, ეს ქმნის მნიშვნელოვან პრობლემებს საზიარო მეხსიერების მოდელის საფუძველზე არსებული კოდის პორტირებისას. შემდეგ, საზოგადოების ზეწოლის ქვეშ, ეს სახელითაც განხორციელდა SharedArrayBuffers. თანდათანობით დაინერგა, სხვადასხვა ბრაუზერებში აღნიშნეს მისი გაშვება, შემდეგ აღნიშნეს ახალი წელი და შემდეგ Meltdown... რის შემდეგაც მივიდნენ დასკვნამდე, რომ დროის უხეში ან უხეში გაზომვა, მაგრამ საერთო მეხსიერების და ა. ძაფი მატულობს მრიცხველს, ეს ყველაფერი ერთი და იგივეა საკმაოდ ზუსტად გამოვა. ასე რომ, ჩვენ გამორთეთ multithreading საერთო მეხსიერებით. როგორც ჩანს, მათ მოგვიანებით ჩართეს იგი, მაგრამ, როგორც პირველი ექსპერიმენტიდან გაირკვა, არსებობს სიცოცხლე მის გარეშე და თუ ასეა, ჩვენ ვეცდებით ამის გაკეთებას მრავალძაფის დაყრის გარეშე.

მეორე მახასიათებელია სტეკით დაბალი დონის მანიპულაციების შეუძლებლობა: თქვენ არ შეგიძლიათ უბრალოდ აიღოთ, შეინახოთ მიმდინარე კონტექსტი და გადახვიდეთ ახალზე ახალი სტეკით. ზარის დასტას მართავს JS ვირტუალური მანქანა. როგორც ჩანს, რა არის პრობლემა, რადგან ჩვენ მაინც გადავწყვიტეთ ყოფილი ნაკადების მართვა მთლიანად ხელით? ფაქტია, რომ QEMU-ში I/O ბლოკი ხორციელდება კორუტინის საშუალებით და სწორედ აქ გამოდგება დაბალი დონის სტეკის მანიპულაციები. საბედნიეროდ, Emscipten უკვე შეიცავს ასინქრონული ოპერაციების მექანიზმს, თუნდაც ორს: ასინციფიკაცია и იმპერატორი. პირველი მუშაობს გენერირებულ JavaScript კოდში მნიშვნელოვანი გაფუჭებით და აღარ არის მხარდაჭერილი. მეორე არის ამჟამინდელი "სწორი გზა" და მუშაობს ბაიტეკოდის გენერაციაში მშობლიური თარჯიმნისთვის. ის მუშაობს, რა თქმა უნდა, ნელა, მაგრამ არ აფუჭებს კოდს. მართალია, ამ მექანიზმისთვის კორუტინების მხარდაჭერა დამოუკიდებლად უნდა ყოფილიყო (უკვე იყო დაწერილი კორუტინები Asyncify-სთვის და იყო დაახლოებით იგივე API-ის დანერგვა Emterpreter-ისთვის, თქვენ უბრალოდ დაგჭირდათ მათი დაკავშირება).

ამ დროისთვის, მე ჯერ ვერ მოვახერხე კოდის დაყოფა, რომელიც შედგენილია WASM-ში და ინტერპრეტირებულია Emterpreter-ის გამოყენებით, ამიტომ ბლოკის მოწყობილობები ჯერ არ მუშაობს (იხილეთ შემდეგ სერიაში, როგორც ამბობენ...). ანუ, საბოლოოდ თქვენ უნდა მიიღოთ მსგავსი სასაცილო ფენიანი რამ:

• ინტერპრეტირებული ბლოკი I/O. ისე, მართლა ელოდით იმიტირებულ NVMe-ს მშობლიური შესრულებით? 🙂
• სტატიკურად შედგენილი ძირითადი QEMU კოდი (მთარგმნელი, სხვა ემულირებული მოწყობილობები და ა.შ.)
• დინამიურად შედგენილი სტუმრის კოდი WASM-ში

QEMU წყაროების მახასიათებლები

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

• არის სტუმარი არქიტექტურები
• არსებობს ამაჩქარებლები, კერძოდ, KVM ტექნიკის ვირტუალიზაციისთვის Linux-ზე (სტუმარი და მასპინძელი სისტემებისთვის ერთმანეთთან თავსებადი), TCG JIT კოდის გენერირებისთვის ნებისმიერ ადგილას. QEMU 2.9-დან დაწყებული, გამოჩნდა HAXM ტექნიკის ვირტუალიზაციის სტანდარტის მხარდაჭერა Windows-ზე (დეტალები)
• თუ გამოიყენება TCG და არა ტექნიკის ვირტუალიზაცია, მაშინ მას აქვს ცალკეული კოდის გენერირების მხარდაჭერა თითოეული ჰოსტის არქიტექტურისთვის, ასევე უნივერსალური თარჯიმანისთვის.
• ... და ამ ყველაფრის გარშემო - ემულირებული პერიფერიული მოწყობილობები, მომხმარებლის ინტერფეისი, მიგრაცია, ჩანაწერი-გამეორება და ა.შ.

სხვათა შორის, იცოდით: QEMU-ს შეუძლია არა მხოლოდ მთელი კომპიუტერის, არამედ პროცესორის მიბაძვა ჰოსტის ბირთვში ცალკე მომხმარებლის პროცესისთვის, რომელსაც იყენებს, მაგალითად, AFL fuzzer ორობითი ინსტრუმენტაციისთვის. იქნებ ვინმეს სურს QEMU-ის მუშაობის ამ რეჟიმის JS-ზე გადატანა? 😉

ისევე როგორც გრძელვადიანი უფასო პროგრამული უზრუნველყოფის უმეტესობა, QEMU აგებულია ზარის საშუალებით configure и make. ვთქვათ, თქვენ გადაწყვიტეთ დაამატოთ რაღაც: TCG backend, thread განხორციელება, რაღაც სხვა. ნუ ჩქარობთ იყოთ ბედნიერი/შეშინებული (ხაზი გაუსვით შესაბამისს) Autoconf-თან კომუნიკაციის პერსპექტივაში - სინამდვილეში, configure QEMU-ები, როგორც ჩანს, თვითნაკეთია და არაფრისგან არ არის წარმოქმნილი.

WebAssembly

რა ჰქვია ამ ნივთს WebAssembly (აკა WASM)? ეს არის Asm.js-ის ჩანაცვლება, რომელიც აღარ არის პრეტენზია, როგორც მოქმედი JavaScript კოდი. პირიქით, ის არის წმინდა ბინარული და ოპტიმიზებული და მასში მთელი რიცხვის უბრალოდ ჩაწერაც კი არ არის ძალიან მარტივი: კომპაქტურობისთვის ის ინახება ფორმატში. LEB128.

შესაძლოა გსმენიათ გადაბრუნების ალგორითმის შესახებ Asm.js-ისთვის - ეს არის „მაღალი დონის“ ნაკადის კონტროლის ინსტრუქციების აღდგენა (ანუ, if-then-else, loops და ა.შ.), რისთვისაც შექმნილია JS ძრავები. დაბალი დონის LLVM IR, უფრო ახლოს არის პროცესორის მიერ შესრულებული მანქანის კოდთან. ბუნებრივია, QEMU-ის შუალედური წარმომადგენლობა უფრო ახლოს არის მეორესთან. როგორც ჩანს, აქ არის, ბაიტიკოდი, ტანჯვის დასასრული... და შემდეგ არის ბლოკები, თუ-მაშინ-სხვა და მარყუჟები!..

და ეს არის კიდევ ერთი მიზეზი, რის გამოც Binaryen არის სასარგებლო: მას შეუძლია ბუნებრივად მიიღოს მაღალი დონის ბლოკები ახლოს, რაც შეინახება WASM-ში. მაგრამ მას ასევე შეუძლია შექმნას კოდი ძირითადი ბლოკების გრაფიკიდან და მათ შორის გადასვლებიდან. ისე, მე უკვე ვთქვი, რომ ის მალავს WebAssembly შენახვის ფორმატს მოსახერხებელი C/C++ API-ს მიღმა.

TCG (პატარა კოდის გენერატორი)

GCT თავდაპირველად იყო backend C კომპილერისთვის. შემდეგ, როგორც ჩანს, მან ვერ გაუძლო კონკურენციას GCC-თან, მაგრამ საბოლოოდ იპოვა თავისი ადგილი QEMU-ში, როგორც კოდის გენერირების მექანიზმი მასპინძელი პლატფორმისთვის. ასევე არის TCG backend, რომელიც აგენერირებს აბსტრაქტულ ბაიტეკოდს, რომელსაც თარჯიმანი მაშინვე ასრულებს, მაგრამ მე გადავწყვიტე ამჯერად მისი გამოყენება ავარიდე. თუმცა, ის ფაქტი, რომ QEMU-ში უკვე შესაძლებელია გენერირებულ ტუბერკულოზზე გადასვლის ჩართვა ფუნქციის მეშვეობით. tcg_qemu_tb_exec, ძალიან სასარგებლო აღმოჩნდა ჩემთვის.

QEMU-ში ახალი TCG backend-ის დასამატებლად, თქვენ უნდა შექმნათ ქვედირექტორია tcg/<имя архитектуры> (ამ შემთხვევაში, tcg/binaryen), და შეიცავს ორ ფაილს: tcg-target.h и tcg-target.inc.c и დანიშნოს ეს ყველაფერი configure. თქვენ შეგიძლიათ სხვა ფაილების განთავსება იქ, მაგრამ, როგორც ამ ორის სახელებიდან მიხვდებით, ორივე იქნება ჩართული სადმე: ერთი, როგორც ჩვეულებრივი სათაურის ფაილი (ის შედის tcg/tcg.hდა ის უკვე არის დირექტორიების სხვა ფაილებში tcg, accel და არა მხოლოდ), მეორე - მხოლოდ როგორც კოდის ნაწყვეტი tcg/tcg.c, მაგრამ მას აქვს წვდომა მის სტატიკური ფუნქციებზე.

გადავწყვიტე, რომ ძალიან დიდ დროს დავხარჯავდი დეტალურ გამოკვლევებზე იმის შესახებ, თუ როგორ მუშაობს იგი, მე უბრალოდ დავაკოპირე ამ ორი ფაილის „ჩონჩხები“ სხვა backend-ის იმპლემენტაციიდან, გულწრფელად მივუთითე ეს ლიცენზიის სათაურში.

ფაილი tcg-target.h შეიცავს ძირითადად ფორმაში არსებულ პარამეტრებს #define-s:

• რამდენი რეგისტრი და რა სიგანეა სამიზნე არქიტექტურაზე (გვაქვს რამდენიც გვინდა, რამდენიც გვსურს - კითხვა უფრო იმაზეა, თუ რა იქნება გენერირებული ბრაუზერის მიერ უფრო ეფექტურ კოდში "სრულიად სამიზნე" არქიტექტურაზე ...)
• ჰოსტის ინსტრუქციების გასწორება: x86-ზე და თუნდაც TCI-ში, ინსტრუქციები საერთოდ არ არის გასწორებული, მაგრამ მე ვაპირებ კოდის ბუფერში ჩასვას არა ინსტრუქციები, არამედ მითითებები Binaryen ბიბლიოთეკის სტრუქტურებზე, ასე რომ, მე ვიტყვი: 4 ბაიტები
• რა არასავალდებულო ინსტრუქციების გენერირება შეუძლია backend-ს - ჩვენ ჩართავთ ყველაფერს, რასაც ვიპოვით Binaryen-ში, ნება მიეცით ამაჩქარებელს დანარჩენი უფრო მარტივებად დაყოს.
• რა არის TLB ქეშის სავარაუდო ზომა, რომელიც მოთხოვნილია backend-ის მიერ. ფაქტია, რომ QEMU-ში ყველაფერი სერიოზულია: მიუხედავად იმისა, რომ არის დამხმარე ფუნქციები, რომლებიც ასრულებენ დატვირთვას/შენახვას სტუმრის MMU-ს გათვალისწინებით (სად ვიქნებოდით ახლა მის გარეშე?), ისინი ინახავენ თავიანთ თარგმან ქეშს სტრუქტურის სახით, რომლის დამუშავება მოსახერხებელია უშუალოდ სამაუწყებლო ბლოკებში ჩასართავად. საკითხავია, რა ოფსეტი მუშავდება ამ სტრუქტურაში ყველაზე ეფექტურად ბრძანებების მცირე და სწრაფი თანმიმდევრობით?
• აქ შეგიძლიათ შეცვალოთ ერთი ან ორი რეზერვირებული რეგისტრის დანიშნულება, ჩართოთ ტუბერკულოზის გამოძახება ფუნქციის საშუალებით და სურვილისამებრ აღწეროთ რამდენიმე მცირე inline- ფუნქციონირებს, როგორიცაა flush_icache_range (მაგრამ ეს არ არის ჩვენი შემთხვევა)

ფაილი tcg-target.inc.cრა თქმა უნდა, ჩვეულებრივ, ზომით გაცილებით დიდია და შეიცავს რამდენიმე სავალდებულო ფუნქციას:

• ინიციალიზაცია, მათ შორის შეზღუდვები, თუ რომელ ოპერატორებზე შეიძლება მოქმედებდეს ინსტრუქციები. უხეშად დაკოპირებულია ჩემ მიერ სხვა ბექენდიდან
• ფუნქცია, რომელიც იღებს ერთ შიდა ბაიტიკოდის ინსტრუქციას
• აქ ასევე შეგიძლიათ დააყენოთ დამხმარე ფუნქციები, ასევე შეგიძლიათ გამოიყენოთ სტატიკური ფუნქციები tcg/tcg.c

ჩემთვის ავირჩიე შემდეგი სტრატეგია: შემდეგი თარგმანის ბლოკის პირველ სიტყვებში დავწერე ოთხი მაჩვენებელი: საწყისი ნიშანი (გარკვეული მნიშვნელობა სიახლოვეს 0xFFFFFFFF, რომელმაც განსაზღვრა ტუბერკულოზის ამჟამინდელი მდგომარეობა), კონტექსტი, გენერირებული მოდული და ჯადოსნური ნომერი გამართვისთვის. თავდაპირველად ნიშანი მოთავსდა 0xFFFFFFFF - nსად n - მცირე დადებითი რიცხვი და ყოველ ჯერზე, როცა იგი ასრულებდა თარჯიმნის მეშვეობით, ის იზრდებოდა 1-ით. როცა მიაღწია 0xFFFFFFFE, შედგა შედგენა, მოდული შენახული იყო ფუნქციების ცხრილში, იმპორტირებული იყო პატარა „გამშვებში“, საიდანაც მოხდა შესრულება. tcg_qemu_tb_execდა მოდული ამოიღეს QEMU მეხსიერებიდან.

კლასიკოსების პერიფრაზირებისთვის, "კრინტი, რამდენს ერწყმის ამ ხმაში პროგერის გულისთვის...". თუმცა მეხსიერება სადღაც ჟონავდა. უფრო მეტიც, მეხსიერებას მართავდა QEMU! მე მქონდა კოდი, რომელიც, შემდეგი ინსტრუქციის დაწერისას (კარგად, ეს არის მაჩვენებელი), წავშალე ის, ვისი ბმულიც ადრე იყო ამ ადგილას, მაგრამ ამან არ უშველა. სინამდვილეში, უმარტივეს შემთხვევაში, QEMU გამოყოფს მეხსიერებას გაშვებისას და იქ წერს გენერირებულ კოდს. როდესაც ბუფერი ამოიწურება, კოდი იშლება და მის ადგილას იწყება შემდეგის ჩაწერა.

კოდის შესწავლის შემდეგ მივხვდი, რომ ჯადოსნური ნომრის ხრიკმა საშუალება მომცა, არ დავმარცხდე გროვის განადგურებისას, პირველივე უღელტეხილზე არაინინიციალიზებულ ბუფერზე რაიმე შეცდომის გათავისუფლებით. მაგრამ ვინ ხელახლა წერს ბუფერს, რომ მოგვიანებით გვერდის ავლით ჩემი ფუნქცია? როგორც Emscripten-ის დეველოპერები გვირჩევენ, როცა პრობლემა შემექმნა, მიღებული კოდი გადავიტანე უკან მშობლიურ აპლიკაციაში, დავაყენე მასზე Mozilla Record-Replay... ზოგადად, საბოლოოდ მივხვდი მარტივ რამეს: თითოეული ბლოკისთვის, ა struct TranslationBlock თავისი აღწერით. გამოიცანით სად... ასეა, ზუსტად ბუფერში ბლოკის წინ. ამის გაცნობიერებით გადავწყვიტე ყავარჯნების გამოყენება (მინიმუმ რამდენიმე) დამეტოვებინა და უბრალოდ გამოვყარე ჯადოსნური ნომერი და დარჩენილი სიტყვები გადავეცი. struct TranslationBlock, შექმნა ცალმხრივად დაკავშირებული სია, რომელიც შეიძლება სწრაფად გაიაროს თარგმანის ქეშის გადატვირთვისას და გაათავისუფლოს მეხსიერება.

რჩება რამდენიმე ხელჯოხები: მაგალითად, მონიშნული მაჩვენებლები კოდის ბუფერში - ზოგიერთი მათგანი უბრალოდ BinaryenExpressionRef, ანუ ისინი უყურებენ გამონათქვამებს, რომლებიც წრფივად უნდა იყოს ჩასმული გენერირებულ ძირითად ბლოკში, ნაწილი არის BB-ებს შორის გადასვლის პირობა, ნაწილი არის სად წავიდეთ. ისე, უკვე არის მომზადებული ბლოკები Relooper-ისთვის, რომლებიც უნდა იყოს დაკავშირებული პირობების მიხედვით. მათი განსასხვავებლად გამოიყენება ვარაუდი, რომ ისინი ყველა გასწორებულია მინიმუმ ოთხი ბაიტით, ასე რომ თქვენ შეგიძლიათ უსაფრთხოდ გამოიყენოთ ყველაზე ნაკლებად მნიშვნელოვანი ორი ბიტი ეტიკეტისთვის, უბრალოდ უნდა გახსოვდეთ, რომ საჭიროების შემთხვევაში ამოიღოთ იგი. სხვათა შორის, ასეთი ეტიკეტები QEMU-ში უკვე გამოიყენება TCG მარყუჟიდან გასვლის მიზეზის მითითებისთვის.

Binaryen-ის გამოყენება

WebAssembly-ის მოდულები შეიცავს ფუნქციებს, რომელთაგან თითოეული შეიცავს სხეულს, რომელიც არის გამოხატულება. გამონათქვამები არის ერთიანი და ორობითი ოპერაციები, ბლოკები, რომლებიც შედგება სხვა გამონათქვამების სიებისგან, საკონტროლო ნაკადი და ა.შ. როგორც უკვე ვთქვი, აქ კონტროლის ნაკადი ორგანიზებულია ზუსტად როგორც მაღალი დონის განშტოებები, მარყუჟები, ფუნქციების გამოძახებები და ა.შ. ფუნქციების არგუმენტები არ არის გადაცემული სტეკზე, მაგრამ აშკარად, ისევე როგორც JS-ში. ასევე არის გლობალური ცვლადები, მაგრამ მე არ გამომიყენებია, ამიტომ მათ შესახებ არ გეტყვით.

ფუნქციებს ასევე აქვთ ლოკალური ცვლადები, დანომრილი ნულიდან, ტიპის: int32 / int64 / float / double. ამ შემთხვევაში, პირველი n ლოკალური ცვლადი არის ფუნქციაზე გადაცემული არგუმენტები. გთხოვთ გაითვალისწინოთ, რომ მიუხედავად იმისა, რომ აქ ყველაფერი არ არის მთლად დაბალი დონის კონტროლის ნაკადის თვალსაზრისით, მთელი რიცხვები მაინც არ ატარებენ ატრიბუტს „ხელმოწერილი/ხელმოუწერელი“: როგორ იქცევა რიცხვი დამოკიდებულია ოპერაციის კოდზე.

ზოგადად რომ ვთქვათ, Binaryen უზრუნველყოფს მარტივი C-API: თქვენ ქმნით მოდულს, მასში შექმენით გამონათქვამები - ერთიანი, ორობითი, ბლოკები სხვა გამონათქვამებიდან, კონტროლი ნაკადი და ა.შ. შემდეგ თქვენ ქმნით ფუნქციას გამოხატვის სახით, როგორც მისი სხეული. თუ თქვენ, როგორც მე, გაქვთ დაბალი დონის გადასვლის გრაფიკი, დაგეხმარება relooper კომპონენტი. რამდენადაც მე მესმის, შესაძლებელია ბლოკში შესრულების ნაკადის მაღალი დონის კონტროლის გამოყენება, თუ ის არ სცილდება ბლოკის საზღვრებს - ანუ შესაძლებელია შიდა სწრაფი ბილიკის გაკეთება / ნელი ბილიკის განშტოება ჩაშენებული TLB ქეშის დამუშავების კოდის შიგნით, მაგრამ არ ჩაერიოს „გარე“ კონტროლის ნაკადში. როდესაც ათავისუფლებთ რელუპერს, მისი ბლოკები თავისუფლდება, მოდულის გათავისუფლებისას ქრება მისთვის გამოყოფილი გამონათქვამები, ფუნქციები და ა.შ. არენაზე.

თუმცა, თუ გსურთ კოდის ინტერპრეტაცია ფრენის დროს, თარჯიმნის ინსტანციის ზედმეტი შექმნისა და წაშლის გარეშე, შეიძლება აზრი ჰქონდეს ამ ლოგიკის C++ ფაილში ჩასმა და იქიდან პირდაპირ მართოთ ბიბლიოთეკის მთელი C++ API, მზა გვერდის ავლით. გააკეთა შეფუთვები.

ასე რომ, კოდის შესაქმნელად გჭირდებათ

// настроить глобальные параметры (можно поменять потом)
BinaryenSetAPITracing(0);

BinaryenSetOptimizeLevel(3);
BinaryenSetShrinkLevel(2);

// создать модуль
BinaryenModuleRef MODULE = BinaryenModuleCreate();

// описать типы функций (как создаваемых, так и вызываемых)
helper_type  BinaryenAddFunctionType(MODULE, "helper-func", BinaryenTypeInt32(), int32_helper_args, ARRAY_SIZE(int32_helper_args));
// (int23_helper_args приоб^Wсоздаются отдельно)

// сконструировать супер-мега выражение
// ... ну тут уж вы как-нибудь сами :)

// потом создать функцию
BinaryenAddFunction(MODULE, "tb_fun", tb_func_type, func_locals, FUNC_LOCALS_COUNT, expr);
BinaryenAddFunctionExport(MODULE, "tb_fun", "tb_fun");
...
BinaryenSetMemory(MODULE, (1 << 15) - 1, -1, NULL, NULL, NULL, NULL, NULL, 0, 0);
BinaryenAddMemoryImport(MODULE, NULL, "env", "memory", 0);
BinaryenAddTableImport(MODULE, NULL, "env", "tb_funcs");

// запросить валидацию и оптимизацию при желании
assert (BinaryenModuleValidate(MODULE));
BinaryenModuleOptimize(MODULE);

... თუ რამე დამავიწყდა, ბოდიში, ეს მხოლოდ მასშტაბის წარმოსაჩენადაა და დეტალები დოკუმენტაციაშია.

და ახლა იწყება crack-fex-pex, დაახლოებით ასეთი:

static char buf[1 << 20];
BinaryenModuleOptimize(MODULE);
BinaryenSetMemory(MODULE, 0, -1, NULL, NULL, NULL, NULL, NULL, 0, 0);
int sz = BinaryenModuleWrite(MODULE, buf, sizeof(buf));
BinaryenModuleDispose(MODULE);
EM_ASM({
  var module = new WebAssembly.Module(new Uint8Array(wasmMemory.buffer, $0, $1));
  var fptr = $2;
  var instance = new WebAssembly.Instance(module, {
      'env': {
          'memory': wasmMemory,
          // ...
      }
  );
  // и вот уже у вас есть instance!
}, buf, sz);

იმისათვის, რომ როგორმე დავაკავშიროთ QEMU და JS სამყაროები და ამავდროულად სწრაფად მივიღოთ კომპილირებული ფუნქციები, შეიქმნა მასივი (ფუნქციების ცხრილი გამშვებში იმპორტისთვის) და იქ განთავსდა გენერირებული ფუნქციები. ინდექსის სწრაფად გამოსათვლელად, თავდაპირველად გამოიყენებოდა ნულოვანი სიტყვის მთარგმნელობითი ბლოკის ინდექსი, მაგრამ შემდეგ ამ ფორმულით გამოთვლილი ინდექსი დაიწყო უბრალოდ ველში მორგება. struct TranslationBlock.

სხვათა შორის, დემო (ამჟამად ბუნდოვანი ლიცენზიით) კარგად მუშაობს მხოლოდ Firefox-ში. Chrome-ის დეველოპერები იყვნენ რატომღაც არ არის მზად იმ ფაქტზე, რომ ვინმეს სურდა შექმნას WebAssembly მოდულის ათასზე მეტი ეგზემპლარი, ამიტომ მათ უბრალოდ გამოყვეს გიგაბაიტი ვირტუალური მისამართების ადგილი თითოეულისთვის...

ჯერ სულ ესაა. იქნებ სხვა სტატია იყოს თუ ვინმე დაინტერესდება. კერძოდ, რჩება მაინც უბრალოდ ბლოკის მოწყობილობების მუშაობა. შესაძლოა აზრიც ჰქონდეს, რომ WebAssembly მოდულების კომპილაცია იყოს ასინქრონული, როგორც ეს ჩვეულებრივ ხდება JS სამყაროში, რადგან ჯერ კიდევ არის თარჯიმანი, რომელსაც შეუძლია გააკეთოს ეს ყველაფერი მანამ, სანამ მშობლიური მოდული მზად არ იქნება.

ბოლოს გამოცანა: თქვენ შეადგინეთ ბინარი 32-ბიტიან არქიტექტურაზე, მაგრამ კოდი მეხსიერების ოპერაციების მეშვეობით ადის Binaryen-დან, სადმე სტეკზე, ან სადმე სხვაგან 2-ბიტიანი მისამართების სივრცის ზედა 32 გბ-ში. პრობლემა ის არის, რომ Binaryen-ის თვალსაზრისით, ეს არის წვდომა ძალიან დიდ შედეგად მისამართზე. როგორ მოვიშოროთ ეს?

ადმინისტრატორის გზით

მე არ დავასრულე ამის ტესტირება, მაგრამ ჩემი პირველი აზრი იყო "რა მოხდება, თუ 32-ბიტიანი Linux დავაინსტალირე?" შემდეგ მისამართების სივრცის ზედა ნაწილი დაიკავებს ბირთვს. ერთადერთი საკითხია, რამდენი იქნება დაკავებული: 1 თუ 2 გბ.

პროგრამისტის გზით (ვარიანტი პრაქტიკოსებისთვის)

მოდით ააფეთქოთ ბუშტი მისამართების სივრცის ზედა ნაწილში. მე თვითონ არ მესმის, რატომ მუშაობს - იქ უკვე უნდა იყოს დასტა. მაგრამ "ჩვენ პრაქტიკოსები ვართ: ყველაფერი მუშაობს ჩვენთვის, მაგრამ არავინ იცის რატომ..."

// 2gbubble.c
// Usage: LD_PRELOAD=2gbubble.so <program>

#include <sys/mman.h>
#include <assert.h>

void __attribute__((constructor)) constr(void)
{
  assert(MAP_FAILED != mmap(1u >> 31, (1u >> 31) - (1u >> 20), PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0));
}

...მართალია ვალგრინდთან არ არის თავსებადი, მაგრამ, საბედნიეროდ, თავად ვალგრინდი ძალიან ეფექტურად უბიძგებს ყველას იქიდან :)

იქნებ ვინმემ უკეთ ახსნას როგორ მუშაობს ჩემი ეს კოდი...

წყარო: www.habr.com