QEMU.js: ດຽວນີ້ຮ້າຍແຮງແລະມີ WASM

ມີຄັ້ງໜຶ່ງຂ້ອຍຕັດສິນໃຈມ່ວນ ພິສູດການປີ້ນກັບກັນຂອງຂະບວນການ ແລະຮຽນຮູ້ວິທີການສ້າງ JavaScript (ທີ່ຊັດເຈນກວ່າ, Asm.js) ຈາກລະຫັດເຄື່ອງຈັກ. QEMU ໄດ້ຖືກເລືອກສໍາລັບການທົດລອງ, ແລະບາງຄັ້ງຕໍ່ມາບົດຄວາມໄດ້ຖືກຂຽນໄວ້ໃນ Habr. ໃນຄໍາເຫັນຂ້າພະເຈົ້າໄດ້ຖືກແນະນໍາໃຫ້ remake ໂຄງການໃນ WebAssembly, ແລະແມ້ກະທັ້ງເຊົາດ້ວຍຕົນເອງ ເກືອບແລ້ວ ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ຕ້ອງ​ການ​ໂຄງ​ການ​ໃດ​ຫນຶ່ງ ... ວຽກ​ເຮັດ​ງານ​ທໍາ​ໄດ້​ດໍາ​ເນີນ​ໄປ​, ແຕ່​ຊ້າ​ຫຼາຍ​, ແລະ​ໃນ​ປັດ​ຈຸ​ບັນ​, ບໍ່​ດົນ​ມາ​ນີ້​ໃນ​ບົດ​ຄວາມ​ນັ້ນ​ໄດ້​ປາ​ກົດ​ຂຶ້ນ​. commentary ໃນຫົວຂໍ້ "ດັ່ງນັ້ນມັນສິ້ນສຸດລົງແນວໃດ?" ໃນການຕອບໂຕ້ກັບຄໍາຕອບລາຍລະອຽດຂອງຂ້ອຍ, ຂ້ອຍໄດ້ຍິນ "ນີ້ຄ້າຍຄືກັບບົດຄວາມ." ດີ, ຖ້າທ່ານສາມາດເຮັດໄດ້, ຈະມີບົດຄວາມ. ບາງທີຄົນຈະພົບວ່າມັນເປັນປະໂຫຍດ. ຈາກມັນ, ຜູ້ອ່ານຈະຮຽນຮູ້ບາງຂໍ້ເທັດຈິງກ່ຽວກັບການອອກແບບ backends ການຜະລິດລະຫັດ QEMU, ເຊັ່ນດຽວກັນກັບວິທີການຂຽນຕົວລວບລວມຂໍ້ມູນພຽງແຕ່ໃນເວລາສໍາລັບຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌.

ວຽກງານ

ເນື່ອງຈາກວ່າຂ້ອຍໄດ້ຮຽນຮູ້ວິທີການ "ບາງອັນ" port QEMU ກັບ JavaScript, ເວລານີ້ມັນໄດ້ຖືກຕັດສິນໃຈເຮັດມັນຢ່າງສະຫລາດແລະບໍ່ເຮັດຊ້ໍາຄວາມຜິດພາດເກົ່າ.

ຂໍ້ຜິດພາດອັນດັບຫນຶ່ງ: ສາຂາຈາກການປ່ອຍຈຸດ

ຄວາມ​ຜິດ​ພາດ​ຄັ້ງ​ທໍາ​ອິດ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ແມ່ນ​ການ fork ເວີ​ຊັນ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ຈາກ​ສະ​ບັບ​ຕົ້ນ​ສະ​ບັບ 2.4.1​. ຫຼັງຈາກນັ້ນ, ມັນເບິ່ງຄືວ່າຂ້ອຍເປັນຄວາມຄິດທີ່ດີ: ຖ້າການປ່ອຍຈຸດມີຢູ່, ມັນອາດຈະເປັນຄວາມຫມັ້ນຄົງຫຼາຍກ່ວາງ່າຍດາຍ 2.4, ແລະແມ້ກະທັ້ງຫຼາຍດັ່ງນັ້ນສາຂາ. master. ແລະນັບຕັ້ງແຕ່ຂ້ອຍວາງແຜນທີ່ຈະເພີ່ມຈໍານວນແມງໄມ້ຂອງຕົນເອງ, ຂ້ອຍບໍ່ຕ້ອງການຄົນອື່ນເລີຍ. ນັ້ນອາດຈະແມ່ນວິທີທີ່ມັນຫັນອອກ. ແຕ່ນີ້ແມ່ນສິ່ງທີ່: QEMU ບໍ່ໄດ້ຢືນຢູ່, ແລະໃນບາງຈຸດພວກເຂົາກໍ່ປະກາດການເພີ່ມປະສິດທິພາບຂອງລະຫັດທີ່ສ້າງຂຶ້ນໂດຍ 10 ເປີເຊັນ. "ແມ່ນແລ້ວ, ຕອນນີ້ຂ້ອຍຈະແຊ່ແຂງ," ຂ້ອຍຄິດແລະແຕກຫັກ. ທີ່ນີ້ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດໃຫ້ digression: ເນື່ອງຈາກລັກສະນະດຽວກະທູ້ຂອງ QEMU.js ແລະຄວາມຈິງທີ່ວ່າ QEMU ຕົ້ນສະບັບບໍ່ໄດ້ຫມາຍຄວາມວ່າບໍ່ມີຫຼາຍ threading (ນັ້ນແມ່ນ, ຄວາມສາມາດໃນການດໍາເນີນການພ້ອມກັນຫຼາຍເສັ້ນທາງລະຫັດທີ່ບໍ່ກ່ຽວຂ້ອງ, ແລະ. ບໍ່ພຽງແຕ່ "ໃຊ້ແກ່ນທັງຫມົດ") ແມ່ນສໍາຄັນສໍາລັບມັນ, ຫນ້າທີ່ຕົ້ນຕໍຂອງກະທູ້ທີ່ຂ້ອຍຕ້ອງ "ເຮັດໃຫ້ມັນອອກ" ເພື່ອໃຫ້ສາມາດໂທຫາຈາກພາຍນອກ. ນີ້ໄດ້ສ້າງບັນຫາທໍາມະຊາດບາງຢ່າງໃນລະຫວ່າງການລວມຕົວ. ຢ່າງໃດກໍຕາມ, ຄວາມຈິງທີ່ວ່າບາງສ່ວນຂອງການປ່ຽນແປງຈາກສາຂາ master, ທີ່ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມ merge ລະຫັດຂອງຂ້າພະເຈົ້າ, ຍັງໄດ້ຮັບ cherry ໃນການປ່ອຍຈຸດ (ແລະດັ່ງນັ້ນໃນສາຂາຂອງຂ້າພະເຈົ້າ) ຍັງອາດຈະບໍ່ໄດ້ເພີ່ມຄວາມສະດວກ.

ໂດຍທົ່ວໄປ, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈວ່າມັນຍັງມີຄວາມຫມາຍທີ່ຈະຖິ້ມເຄື່ອງຕົ້ນແບບ, ຖອດມັນອອກສໍາລັບພາກສ່ວນຕ່າງໆແລະສ້າງຮຸ່ນໃຫມ່ຈາກຈຸດເລີ່ມຕົ້ນໂດຍອີງໃສ່ບາງສິ່ງບາງຢ່າງທີ່ສົດກວ່າແລະໃນປັດຈຸບັນຈາກ. master.

ຄວາມຜິດພາດອັນດັບສອງ: ວິທີການ TLP

ໂດຍເນື້ອແທ້ແລ້ວ, ນີ້ບໍ່ແມ່ນຄວາມຜິດພາດ, ໂດຍທົ່ວໄປແລ້ວ, ມັນເປັນພຽງແຕ່ລັກສະນະຂອງການສ້າງໂຄງການໃນເງື່ອນໄຂຂອງຄວາມເຂົ້າໃຈຜິດທີ່ສົມບູນຂອງທັງສອງ "ບ່ອນແລະວິທີການຍ້າຍອອກໄປ?" ແລະໂດຍທົ່ວໄປ "ພວກເຮົາຈະໄປທີ່ນັ້ນບໍ?" ໃນເງື່ອນໄຂເຫຼົ່ານີ້ ການຂຽນໂປລແກລມ clumsy ເປັນທາງເລືອກທີ່ເຫມາະສົມ, ແຕ່, ຕາມທໍາມະຊາດ, ຂ້ອຍບໍ່ຕ້ອງການທີ່ຈະເຮັດຊ້ໍາອີກໂດຍບໍ່ຈໍາເປັນ. ເວລານີ້ຂ້ອຍຢາກເຮັດມັນຢ່າງສະຫລາດ: commits ປະລໍາມະນູ, ການປ່ຽນແປງລະຫັດສະຕິ (ແລະບໍ່ແມ່ນ "stringing random ຕົວອັກສອນຮ່ວມກັນຈົນກ່ວາມັນລວບລວມ (ມີຄໍາເຕືອນ)", Linus Torvalds ເຄີຍເວົ້າກ່ຽວກັບໃຜຜູ້ຫນຶ່ງ, ອີງຕາມ Wikiquote), ແລະອື່ນໆ.

ຄວາມຜິດພາດທີ່ສາມ: ເຂົ້າໄປໃນນ້ໍາໂດຍບໍ່ຮູ້ ford

ຂ້ອຍຍັງບໍ່ໄດ້ກໍາຈັດມັນຢ່າງສົມບູນ, ແຕ່ຕອນນີ້ຂ້ອຍໄດ້ຕັດສິນໃຈທີ່ຈະບໍ່ປະຕິບັດຕາມເສັ້ນທາງຂອງການຕໍ່ຕ້ານຢ່າງຫນ້ອຍ, ແລະເຮັດມັນ "ເປັນຜູ້ໃຫຍ່", ຄື, ຂຽນ TCG backend ຂອງຂ້ອຍຈາກຈຸດເລີ່ມຕົ້ນ, ເພື່ອບໍ່ເປັນ. ຕ້ອງເວົ້າຕໍ່ມາ, "ແມ່ນແລ້ວ, ແນ່ນອນ, ຊ້າ, ແຕ່ຂ້ອຍບໍ່ສາມາດຄວບຄຸມທຸກສິ່ງທຸກຢ່າງ - ນັ້ນແມ່ນວິທີທີ່ TCI ຖືກຂຽນ ... " ຍິ່ງໄປກວ່ານັ້ນ, ນີ້ໃນເບື້ອງຕົ້ນເບິ່ງຄືວ່າເປັນການແກ້ໄຂທີ່ຊັດເຈນ, ນັບຕັ້ງແຕ່ ຂ້ອຍສ້າງລະຫັດຖານສອງ. ໃນຂະນະທີ່ພວກເຂົາເວົ້າວ່າ, "Ghent ໄດ້ລວບລວມу, ແຕ່ບໍ່ແມ່ນອັນນັ້ນ ": ລະຫັດແມ່ນ, ແນ່ນອນ, ຄູ່, ແຕ່ການຄວບຄຸມບໍ່ສາມາດຖືກໂອນພຽງແຕ່ກັບມັນ - ມັນຕ້ອງໄດ້ຮັບການຊຸກຍູ້ຢ່າງຈະແຈ້ງເຂົ້າໄປໃນຕົວທ່ອງເວັບສໍາລັບການລວບລວມ, ເຊິ່ງກໍ່ໃຫ້ເກີດວັດຖຸທີ່ແນ່ນອນຈາກໂລກ JS, ເຊິ່ງຍັງຕ້ອງການ. ໄດ້​ຮັບ​ການ​ບັນ​ທຶກ​ໄວ້​ບາງ​ບ່ອນ​. ຢ່າງໃດກໍຕາມ, ໃນສະຖາປັດຕະຍະກໍາ RISC ປົກກະຕິ, ເທົ່າທີ່ຂ້າພະເຈົ້າເຂົ້າໃຈ, ສະຖານະການປົກກະຕິແມ່ນຄວາມຕ້ອງການທີ່ຈະປັບຄ່າ cache ຄໍາແນະນໍາສໍາລັບການສ້າງລະຫັດໃຫມ່ຢ່າງຊັດເຈນ - ຖ້ານີ້ບໍ່ແມ່ນສິ່ງທີ່ພວກເຮົາຕ້ອງການ, ໃນກໍລະນີໃດກໍ່ຕາມ, ມັນໃກ້ຊິດ. ນອກຈາກນັ້ນ, ຈາກຄວາມພະຍາຍາມສຸດທ້າຍຂອງຂ້ອຍ, ຂ້ອຍໄດ້ຮຽນຮູ້ວ່າການຄວບຄຸມເບິ່ງຄືວ່າບໍ່ຖືກໂອນໄປຫາກາງຂອງບລັອກການແປພາສາ, ດັ່ງນັ້ນພວກເຮົາກໍ່ບໍ່ຕ້ອງການ bytecode ທີ່ຖືກຕີຄວາມຫມາຍຈາກການຊົດເຊີຍໃດໆ, ແລະພວກເຮົາສາມາດສ້າງມັນຈາກຫນ້າທີ່ຢູ່ໃນ TB. .

ພວກເຂົາເຈົ້າມາແລະເຕະ

ເຖິງແມ່ນວ່າຂ້ອຍໄດ້ເລີ່ມຂຽນລະຫັດຄືນໃຫມ່ໃນເດືອນກໍລະກົດ, ເຫດການ magic ໄດ້ເກີດຂຶ້ນໂດຍບໍ່ໄດ້ສັງເກດເຫັນ: ປົກກະຕິແລ້ວຈົດຫມາຍຈາກ GitHub ມາຮອດເປັນການແຈ້ງເຕືອນກ່ຽວກັບການຕອບສະຫນອງຕໍ່ບັນຫາແລະການຮ້ອງຂໍດຶງ, ແຕ່ຢູ່ທີ່ນີ້, ທັນໃດນັ້ນ ກ່າວໃນກະທູ້ Binaryen ເປັນ backend qemu ໃນສະພາບການ, "ລາວໄດ້ເຮັດບາງສິ່ງບາງຢ່າງເຊັ່ນນັ້ນ, ບາງທີລາວອາດຈະເວົ້າບາງສິ່ງບາງຢ່າງ." ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບການນໍາໃຊ້ຫ້ອງສະຫມຸດທີ່ກ່ຽວຂ້ອງຂອງ Emscripten Binaryen ເພື່ອສ້າງ WASM JIT. ດີ, ຂ້າພະເຈົ້າໄດ້ບອກວ່າທ່ານມີໃບອະນຸຍາດ Apache 2.0 ຢູ່ທີ່ນັ້ນ, ແລະ QEMU ໂດຍລວມແມ່ນແຈກຢາຍພາຍໃຕ້ GPLv2, ແລະພວກມັນບໍ່ເຂົ້າກັນໄດ້ຫຼາຍ. ທັນໃດນັ້ນມັນໄດ້ຫັນອອກວ່າໃບອະນຸຍາດສາມາດ ແກ້ໄຂມັນຢ່າງໃດ (ຂ້ອຍບໍ່ຮູ້: ບາງທີອາດຈະປ່ຽນມັນ, ບາງທີການອອກໃບອະນຸຍາດສອງ, ບາງທີສິ່ງອື່ນ ... ). ນີ້, ແນ່ນອນ, ເຮັດໃຫ້ຂ້ອຍມີຄວາມສຸກ, ເພາະວ່າໃນເວລານັ້ນຂ້ອຍໄດ້ເບິ່ງຢ່າງໃກ້ຊິດ ຮູບແບບຖານສອງ WebAssembly, ແລະຂ້ອຍຮູ້ສຶກໂສກເສົ້າແລະບໍ່ສາມາດເຂົ້າໃຈໄດ້. ນອກຈາກນີ້ຍັງມີຫ້ອງສະຫມຸດທີ່ຈະ devour ຕັນພື້ນຖານທີ່ມີເສັ້ນສະແດງການຫັນປ່ຽນ, ຜະລິດ bytecode, ແລະແມ້ກະທັ້ງແລ່ນມັນຢູ່ໃນນາຍພາສາຕົວມັນເອງ, ຖ້າຈໍາເປັນ.

ຫຼັງຈາກນັ້ນ, ມີຫຼາຍ ຈົດຫມາຍ ໃນບັນຊີລາຍຊື່ທາງໄປສະນີ QEMU, ແຕ່ນີ້ແມ່ນກ່ຽວກັບຄໍາຖາມ, "ໃຜຕ້ອງການມັນແນວໃດ?" ແລະມັນແມ່ນ ທັນໃດນັ້ນ, ມັນໄດ້ຫັນອອກມັນເປັນສິ່ງຈໍາເປັນ. ຢ່າງຫນ້ອຍ, ທ່ານສາມາດຂູດຮ່ວມກັນຄວາມເປັນໄປໄດ້ຂອງການນໍາໃຊ້ຕໍ່ໄປນີ້, ຖ້າມັນເຮັດວຽກຫຼາຍຫຼືຫນ້ອຍໄວ:

• ການເປີດຕົວບາງສິ່ງບາງຢ່າງການສຶກສາໂດຍບໍ່ມີການຕິດຕັ້ງໃດໆ
• virtualization ໃນ iOS, ບ່ອນທີ່, ຕາມຂ່າວລື, ຄໍາຮ້ອງສະຫມັກດຽວທີ່ມີສິດທີ່ຈະສ້າງລະຫັດໃນການບິນແມ່ນເຄື່ອງຈັກ JS (ນີ້ແມ່ນຄວາມຈິງບໍ?)
• ການສາທິດ mini-OS - single-floppy, built-in, firmware ທຸກຊະນິດ, ແລະອື່ນໆ ...

ຄຸນນະສົມບັດ Runtime ຂອງຕົວທ່ອງເວັບ

ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າແລ້ວ, QEMU ແມ່ນຕິດກັບ multithreading, ແຕ່ຕົວທ່ອງເວັບບໍ່ມີມັນ. ແລ້ວ, ນັ້ນແມ່ນ, ບໍ່ ... ທໍາອິດມັນບໍ່ມີຢູ່ທັງຫມົດ, ຫຼັງຈາກນັ້ນ WebWorkers ປາກົດ - ເທົ່າທີ່ຂ້ອຍເຂົ້າໃຈ, ນີ້ແມ່ນ multithreading ໂດຍອີງໃສ່ຂໍ້ຄວາມທີ່ຖ່າຍທອດ. ໂດຍບໍ່ມີຕົວແປທີ່ແບ່ງປັນ. ຕາມທໍາມະຊາດ, ນີ້ສ້າງບັນຫາທີ່ສໍາຄັນໃນເວລາທີ່ porting ລະຫັດທີ່ມີຢູ່ແລ້ວໂດຍອີງໃສ່ຮູບແບບຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນ. ຫຼັງຈາກນັ້ນ, ພາຍໃຕ້ຄວາມກົດດັນຂອງປະຊາຊົນ, ມັນຍັງຖືກປະຕິບັດພາຍໃຕ້ຊື່ SharedArrayBuffers. ມັນໄດ້ຖືກນໍາສະເຫນີເທື່ອລະກ້າວ, ພວກເຂົາເຈົ້າສະເຫຼີມສະຫຼອງການເປີດຕົວຂອງຕົນໃນຕົວທ່ອງເວັບທີ່ແຕກຕ່າງກັນ, ຫຼັງຈາກນັ້ນພວກເຂົາເຈົ້າສະເຫຼີມສະຫຼອງປີໃຫມ່, ແລະຫຼັງຈາກນັ້ນ Meltdown ... ຫຼັງຈາກນັ້ນ, ພວກເຂົາເຈົ້າໄດ້ມາສະຫລຸບວ່າຫຍາບຫຼືຫຍາບການວັດແທກເວລາ, ແຕ່ການຊ່ວຍເຫຼືອຂອງຄວາມຊົງຈໍາຮ່ວມກັນແລະເປັນ. thread incrementing counter, ມັນທັງຫມົດຄືກັນ ມັນຈະເຮັດວຽກອອກຢ່າງຖືກຕ້ອງ. ດັ່ງນັ້ນ, ພວກເຮົາປິດ multithreading ກັບຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນ. ມັນເບິ່ງຄືວ່າຕໍ່ມາພວກເຂົາໄດ້ຫັນມັນຄືນມາ, ແຕ່ຍ້ອນວ່າມັນເຫັນໄດ້ຊັດເຈນຈາກການທົດລອງຄັ້ງທໍາອິດ, ມັນມີຊີວິດທີ່ບໍ່ມີມັນ, ແລະຖ້າເປັນດັ່ງນັ້ນ, ພວກເຮົາຈະພະຍາຍາມເຮັດມັນໂດຍບໍ່ຕ້ອງອີງໃສ່ multithreading.

ລັກສະນະທີສອງແມ່ນເປັນໄປບໍ່ໄດ້ຂອງການຫມູນໃຊ້ໃນລະດັບຕ່ໍາກັບ stack ໄດ້: ທ່ານບໍ່ສາມາດພຽງແຕ່ເອົາ, ຊ່ວຍປະຢັດສະພາບການໃນປະຈຸບັນແລະສະຫຼັບກັບໃຫມ່ທີ່ມີ stack ໃຫມ່. ແຖບການໂທຖືກຈັດການໂດຍ JS virtual machine. ມັນເບິ່ງຄືວ່າ, ບັນຫາແມ່ນຫຍັງ, ນັບຕັ້ງແຕ່ພວກເຮົາຍັງຕັດສິນໃຈທີ່ຈະຈັດການກະແສໃນອະດີດຢ່າງສົມບູນດ້ວຍຕົນເອງ? ຄວາມຈິງແລ້ວແມ່ນວ່າ ຕັນ I/O ໃນ QEMU ແມ່ນຖືກປະຕິບັດຜ່ານ coroutines, ແລະນີ້ແມ່ນບ່ອນທີ່ການຫມູນໃຊ້ stack ລະດັບຕ່ໍາຈະເປັນປະໂຫຍດ. ໂຊກດີ, Emscipten ມີກົນໄກສໍາລັບການດໍາເນີນງານ asynchronous ແລ້ວ, ເຖິງແມ່ນວ່າສອງ: ເຊື່ອມໂຍງ и ນາຍພາສາ. ອັນທໍາອິດເຮັດວຽກໂດຍຜ່ານການ bloat ທີ່ສໍາຄັນໃນລະຫັດ JavaScript ທີ່ສ້າງຂຶ້ນແລະບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນອີກຕໍ່ໄປ. ອັນທີສອງແມ່ນ "ວິທີການທີ່ຖືກຕ້ອງ" ໃນປະຈຸບັນແລະເຮັດວຽກໂດຍຜ່ານການຜະລິດ bytecode ສໍາລັບນາຍພາສາພື້ນເມືອງ. ມັນເຮັດວຽກ, ແນ່ນອນ, ຊ້າ, ແຕ່ມັນບໍ່ເຮັດໃຫ້ລະຫັດ. ແທ້ຈິງແລ້ວ, ການສະຫນັບສະຫນູນ coroutines ສໍາລັບກົນໄກນີ້ຕ້ອງໄດ້ຮັບການປະກອບສ່ວນເປັນເອກະລາດ (ມີ coroutines ທີ່ຂຽນແລ້ວສໍາລັບ Asyncify ແລະມີການຈັດຕັ້ງປະຕິບັດປະມານ API ດຽວກັນສໍາລັບ Emterpreter, ທ່ານພຽງແຕ່ຕ້ອງການເຊື່ອມຕໍ່ພວກມັນ).

ໃນປັດຈຸບັນ, ຂ້າພະເຈົ້າຍັງບໍ່ທັນໄດ້ຈັດການແຍກລະຫັດເຂົ້າໄປໃນຫນຶ່ງທີ່ລວບລວມຢູ່ໃນ WASM ແລະຕີຄວາມຫມາຍໂດຍໃຊ້ Emterpreter, ດັ່ງນັ້ນອຸປະກອນ block ຍັງບໍ່ເຮັດວຽກເທື່ອ (ເບິ່ງໃນຊຸດຕໍ່ໄປ, ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າ ... ). ນັ້ນແມ່ນ, ໃນທີ່ສຸດທ່ານຄວນໄດ້ຮັບບາງສິ່ງບາງຢ່າງເຊັ່ນ: ສິ່ງທີ່ເປັນຊັ້ນຕະຫລົກນີ້:

• ການຕີຄວາມໝາຍຂອງຕັນ I/O. ແລ້ວ, ເຈົ້າຄາດຫວັງວ່າເຮັດຕາມ NVMe ກັບປະສິດທິພາບພື້ນເມືອງບໍ? 🙂
• ລວບລວມລະຫັດ QEMU ຫຼັກ (ນັກແປ, ອຸປະກອນທີ່ເຮັດຕາມແບບຢ່າງອື່ນໆ, ແລະອື່ນໆ)
• ລວບລວມລະຫັດແຂກເຂົ້າໄປໃນ WASM ແບບໄດນາມິກ

ຄຸນນະສົມບັດຂອງແຫຼ່ງ QEMU

ດັ່ງທີ່ທ່ານອາດຈະໄດ້ຄາດເດົາແລ້ວ, ລະຫັດສໍາລັບການຈໍາລອງສະຖາປັດຕະຍະກໍາຂອງແຂກແລະລະຫັດສໍາລັບການສ້າງຄໍາແນະນໍາເຄື່ອງໂຮດແມ່ນແຍກອອກໃນ QEMU. ແທ້ຈິງແລ້ວ, ມັນເປັນເລື່ອງເລັກນ້ອຍ:

• ມີສະຖາປັດຕະຍະກໍາຂອງແຂກ
• ມີແມ່ນ ເຄື່ອງເລັ່ງ, ຄື, KVM ສໍາລັບການ virtualization ຮາດແວໃນ Linux (ສໍາລັບແຂກແລະລະບົບເຈົ້າພາບທີ່ເຂົ້າກັນໄດ້ກັບກັນແລະກັນ), TCG ສໍາລັບການສ້າງລະຫັດ JIT ທຸກບ່ອນ. ເລີ່ມຕົ້ນດ້ວຍ QEMU 2.9, ການສະຫນັບສະຫນູນມາດຕະຖານ virtualization ຮາດແວ HAXM ໃນ Windows ປາກົດ (ລາຍລະອຽດ)
• ຖ້າ TCG ຖືກນໍາໃຊ້ແລະບໍ່ແມ່ນຮາດແວ virtualization, ຫຼັງຈາກນັ້ນມັນມີການສະຫນັບສະຫນູນການຜະລິດລະຫັດແຍກຕ່າງຫາກສໍາລັບແຕ່ລະສະຖາປັດຕະຍະພາບເຈົ້າພາບ, ເຊັ່ນດຽວກັນກັບນາຍແປພາສາທົ່ວໄປ.
• ... ແລະປະມານທັງຫມົດນີ້ - emulated peripherals, ການໂຕ້ຕອບຜູ້ໃຊ້, ການເຄື່ອນຍ້າຍ, ການບັນທຶກ replay, ແລະອື່ນໆ.

ໂດຍວິທີທາງການ, ເຈົ້າຮູ້ບໍ: QEMU ສາມາດ emulate ບໍ່ພຽງແຕ່ຄອມພິວເຕີທັງຫມົດ, ແຕ່ຍັງໂປເຊດເຊີສໍາລັບຂະບວນການຜູ້ໃຊ້ແຍກຕ່າງຫາກໃນ kernel ເຈົ້າພາບ, ເຊິ່ງຖືກນໍາໃຊ້, ສໍາລັບການຍົກຕົວຢ່າງ, ໂດຍ AFL fuzzer ສໍາລັບເຄື່ອງມືສອງ. ບາງທີອາດມີໃຜຜູ້ຫນຶ່ງຕ້ອງການ port ຮູບແບບການດໍາເນີນການນີ້ຂອງ QEMU ກັບ JS? 😉

ເຊັ່ນດຽວກັນກັບຊອບແວຟຣີທີ່ມີເວລາດົນນານທີ່ສຸດ, QEMU ຖືກສ້າງຂຶ້ນໂດຍຜ່ານການໂທ configure и make. ໃຫ້ເວົ້າວ່າທ່ານຕັດສິນໃຈທີ່ຈະເພີ່ມບາງສິ່ງບາງຢ່າງ: backend TCG, ການປະຕິບັດກະທູ້, ບາງສິ່ງບາງຢ່າງອື່ນ. ຢ່າຟ້າວທີ່ຈະມີຄວາມສຸກ / ຢ້ານ (ຂີດກ້ອງຕາມຄວາມເຫມາະສົມ) ໃນຄວາມສົດໃສດ້ານຂອງການສື່ສານກັບ Autoconf - ໃນຄວາມເປັນຈິງ, configure QEMU's ປາກົດຂື້ນວ່າຂຽນດ້ວຍຕົນເອງແລະບໍ່ໄດ້ຖືກສ້າງຂຶ້ນຈາກສິ່ງໃດ.

ການປະກອບເວັບ

ດັ່ງນັ້ນສິ່ງທີ່ເອີ້ນວ່າ WebAssembly (aka WASM)? ນີ້ແມ່ນການທົດແທນສໍາລັບ Asm.js, ບໍ່ໄດ້ທໍາທ່າວ່າເປັນລະຫັດ JavaScript ທີ່ຖືກຕ້ອງອີກຕໍ່ໄປ. ໃນທາງກົງກັນຂ້າມ, ມັນແມ່ນສອງອັນບໍລິສຸດແລະຖືກປັບປຸງໃຫ້ດີທີ່ສຸດ, ແລະເຖິງແມ່ນວ່າພຽງແຕ່ການຂຽນຈໍານວນເຕັມໃນມັນບໍ່ແມ່ນງ່າຍດາຍຫຼາຍ: ສໍາລັບຄວາມຫນາແຫນ້ນ, ມັນຖືກເກັບໄວ້ໃນຮູບແບບ. LEB128.

ທ່ານອາດຈະໄດ້ຍິນກ່ຽວກັບ algorithm relooping ສໍາລັບ Asm.js - ນີ້ແມ່ນການຟື້ນຟູຂອງ "ລະດັບສູງ" ຄໍາແນະນໍາການຄວບຄຸມການໄຫຼວຽນຂອງການປະຕິບັດ (ນັ້ນແມ່ນ, if- then-else, loops, etc.), ສໍາລັບເຄື່ອງຈັກ JS ໄດ້ຖືກອອກແບບ, ຈາກ LLVM IR ລະດັບຕ່ໍາ, ໃກ້ຊິດກັບລະຫັດເຄື່ອງຈັກທີ່ປະຕິບັດໂດຍໂປເຊດເຊີ. ຕາມທໍາມະຊາດ, ການເປັນຕົວແທນລະດັບປານກາງຂອງ QEMU ແມ່ນໃກ້ຊິດກັບທີສອງ. ມັນເບິ່ງຄືວ່ານີ້ແມ່ນ, bytecode, ໃນຕອນທ້າຍຂອງຄວາມທໍລະມານ ... ແລະຫຼັງຈາກນັ້ນມີຕັນ, if- then-else ແລະ loops!..

ແລະນີ້ແມ່ນເຫດຜົນອີກອັນຫນຶ່ງທີ່ Binaryen ເປັນປະໂຫຍດ: ມັນທໍາມະຊາດສາມາດຍອມຮັບຕັນລະດັບສູງຢູ່ໃກ້ກັບສິ່ງທີ່ຈະຖືກເກັບໄວ້ໃນ WASM. ແຕ່ມັນຍັງສາມາດຜະລິດລະຫັດຈາກເສັ້ນສະແດງຂອງຕັນພື້ນຖານແລະການຫັນປ່ຽນລະຫວ່າງພວກມັນ. ດີ, ຂ້າພະເຈົ້າໄດ້ເວົ້າແລ້ວວ່າມັນເຊື່ອງຮູບແບບການເກັບຮັກສາ WebAssembly ຢູ່ເບື້ອງຫລັງ C / C ++ API ທີ່ສະດວກ.

TCG (ຕົວສ້າງລະຫັດນ້ອຍໆ)

ບໍລິສັດ TCG ເດີມ backend ສໍາລັບ C compiler ຫຼັງຈາກນັ້ນ, ປາກົດຂື້ນ, ມັນບໍ່ສາມາດທົນກັບການແຂ່ງຂັນກັບ GCC, ແຕ່ໃນທີ່ສຸດມັນພົບເຫັນສະຖານທີ່ໃນ QEMU ເປັນກົນໄກການສ້າງລະຫັດສໍາລັບເວທີເຈົ້າພາບ. ຍັງມີ backend TCG ທີ່ສ້າງບາງ bytecode ທີ່ບໍ່ມີຕົວຕົນ, ເຊິ່ງຖືກປະຕິບັດທັນທີໂດຍນາຍພາສາ, ແຕ່ຂ້ອຍໄດ້ຕັດສິນໃຈທີ່ຈະຫຼີກເວັ້ນການໃຊ້ມັນໃນເວລານີ້. ຢ່າງໃດກໍ່ຕາມ, ຄວາມຈິງທີ່ວ່າໃນ QEMU ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດໃຫ້ການຫັນປ່ຽນໄປສູ່ TB ທີ່ຜະລິດໂດຍຜ່ານຫນ້າທີ່ tcg_qemu_tb_exec, ມັນໄດ້ກາຍເປັນປະໂຫຍດຫຼາຍສໍາລັບຂ້ອຍ.

ເພື່ອເພີ່ມ TCG backend ໃຫມ່ໃສ່ QEMU, ທ່ານຈໍາເປັນຕ້ອງສ້າງ subdirectory tcg/<имя архитектуры> (ໃນ​ກໍ​ລະ​ນີ​ນີ້, tcg/binaryen), ແລະ​ມັນ​ປະ​ກອບ​ດ້ວຍ​ສອງ​ໄຟລ​໌​: tcg-target.h и tcg-target.inc.c и ລົງທະບຽນ ມັນທັງຫມົດກ່ຽວກັບ configure. ທ່ານສາມາດວາງໄຟລ໌ອື່ນໆຢູ່ທີ່ນັ້ນ, ແຕ່, ຕາມທີ່ທ່ານສາມາດເດົາຈາກຊື່ຂອງສອງອັນນີ້, ພວກມັນທັງສອງຈະຖືກລວມຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ: ຫນຶ່ງເປັນໄຟລ໌ header ປົກກະຕິ (ມັນຖືກລວມຢູ່ໃນ. tcg/tcg.h, ແລະອັນນັ້ນຢູ່ໃນໄຟລ໌ອື່ນຢູ່ໃນໄດເລກະທໍລີ tcg, accel ແລະບໍ່ພຽງແຕ່), ອື່ນໆ - ພຽງແຕ່ເປັນ snippet ລະຫັດໃນ tcg/tcg.c, ແຕ່ມັນສາມາດເຂົ້າເຖິງຫນ້າທີ່ຄົງທີ່ຂອງມັນ.

ການຕັດສິນໃຈວ່າຂ້ອຍຈະໃຊ້ເວລາຫຼາຍເກີນໄປໃນການສືບສວນລາຍລະອຽດຂອງວິທີການເຮັດວຽກ, ຂ້ອຍພຽງແຕ່ຄັດລອກ "ໂຄງກະດູກ" ຂອງສອງໄຟລ໌ນີ້ຈາກການປະຕິບັດ backend ອື່ນ, ຊີ້ໃຫ້ເຫັນຄວາມຊື່ສັດໃນຫົວຂໍ້ໃບອະນຸຍາດ.

ເອກະສານ tcg-target.h ສ່ວນໃຫຍ່ປະກອບດ້ວຍການຕັ້ງຄ່າໃນຮູບແບບ #define-s:

• ມີຈໍານວນການລົງທະບຽນແລະຄວາມກວ້າງເທົ່າໃດໃນສະຖາປັດຕະຍະກໍາເປົ້າຫມາຍ (ພວກເຮົາມີຈໍານວນເທົ່າທີ່ພວກເຮົາຕ້ອງການ, ເທົ່າທີ່ພວກເຮົາຕ້ອງການ - ຄໍາຖາມແມ່ນເພີ່ມເຕີມກ່ຽວກັບສິ່ງທີ່ຈະຖືກສ້າງເປັນລະຫັດທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນໂດຍຕົວທ່ອງເວັບໃນສະຖາປັດຕະຍະກໍາ "ເປົ້າຫມາຍຢ່າງສົມບູນ" ...)
• ການຈັດລໍາດັບຄໍາແນະນໍາຂອງເຈົ້າພາບ: ໃນ x86, ແລະແມ້ແຕ່ຢູ່ໃນ TCI, ຄໍາແນະນໍາແມ່ນບໍ່ສອດຄ່ອງທັງຫມົດ, ແຕ່ຂ້ອຍຈະໃສ່ໃນລະຫັດ buffer ບໍ່ແມ່ນຄໍາແນະນໍາທັງຫມົດ, ແຕ່ຊີ້ໃຫ້ເຫັນເຖິງໂຄງສ້າງຫ້ອງສະຫມຸດ Binaryen, ດັ່ງນັ້ນຂ້ອຍຈະເວົ້າວ່າ: 4. ໄບຕ໌
• ຄໍາແນະນໍາທາງເລືອກໃດທີ່ backend ສາມາດສ້າງໄດ້ - ພວກເຮົາລວມເອົາທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາພົບເຫັນຢູ່ໃນ Binaryen, ໃຫ້ຕົວເລັ່ງການທໍາລາຍສ່ວນທີ່ເຫຼືອເຂົ້າໄປໃນຕົວມັນເອງທີ່ງ່າຍດາຍກວ່າ.
• ຂະຫນາດປະມານຂອງ cache TLB ທີ່ຮ້ອງຂໍໂດຍ backend. ຄວາມຈິງແລ້ວແມ່ນວ່າໃນ QEMU ທຸກສິ່ງທຸກຢ່າງແມ່ນຮ້າຍແຮງ: ເຖິງແມ່ນວ່າມີຫນ້າທີ່ຜູ້ຊ່ວຍທີ່ປະຕິບັດການໂຫຼດ / ຮ້ານຄໍານຶງເຖິງ MMU ແຂກ (ພວກເຮົາຈະຢູ່ໃສໂດຍບໍ່ມີມັນໃນປັດຈຸບັນ?), ພວກເຂົາຊ່ວຍປະຢັດ cache ການແປພາສາຂອງພວກເຂົາໃນຮູບແບບຂອງໂຄງສ້າງ, ການປຸງແຕ່ງທີ່ສະດວກໃນການຝັງໂດຍກົງເຂົ້າໄປໃນຕັນອອກອາກາດ. ຄໍາຖາມແມ່ນ, ສິ່ງທີ່ຊົດເຊີຍໃນໂຄງສ້າງນີ້ຖືກປຸງແຕ່ງຢ່າງມີປະສິດທິພາບຫຼາຍທີ່ສຸດໂດຍຄໍາສັ່ງຂະຫນາດນ້ອຍແລະໄວ?
• ທີ່ນີ້ທ່ານສາມາດປັບຈຸດປະສົງຂອງຫນຶ່ງຫຼືສອງທະບຽນສະຫງວນ, ເປີດໃຊ້ການໂທຫາ TB ຜ່ານຫນ້າທີ່ແລະທາງເລືອກທີ່ຈະອະທິບາຍສອງສາມຂະຫນາດນ້ອຍ. inline- ຫນ້າ​ທີ່​ຄ້າຍ​ຄື​ flush_icache_range (ແຕ່ນີ້ບໍ່ແມ່ນກໍລະນີຂອງພວກເຮົາ)

ເອກະສານ tcg-target.inc.cແນ່ນອນວ່າ, ປົກກະຕິແລ້ວມີຂະຫນາດໃຫຍ່ຫຼາຍແລະມີຫນ້າທີ່ບັງຄັບຫຼາຍ:

• ການເລີ່ມຕົ້ນ, ລວມທັງຂໍ້ຈໍາກັດກ່ຽວກັບຄໍາແນະນໍາທີ່ສາມາດດໍາເນີນການກັບຕົວປະຕິບັດການໃດ. ສຳເນົາໂດຍຂ້ອຍຢ່າງບໍ່ຄາດຄິດຈາກເບື້ອງຫຼັງອື່ນ
• ຟັງຊັນທີ່ໃຊ້ເວລາຫນຶ່ງຄໍາສັ່ງ bytecode ພາຍໃນ
• ນອກນັ້ນທ່ານຍັງສາມາດໃສ່ຫນ້າທີ່ຊ່ວຍຢູ່ທີ່ນີ້, ແລະທ່ານຍັງສາມາດໃຊ້ຟັງຊັນ static ຈາກ tcg/tcg.c

ສໍາລັບຕົວຂ້ອຍເອງ, ຂ້ອຍເລືອກຍຸດທະສາດຕໍ່ໄປນີ້: ໃນຄໍາທໍາອິດຂອງການແປພາສາຕໍ່ໄປ, ຂ້າພະເຈົ້າໄດ້ຂຽນສີ່ຕົວຊີ້: ເຄື່ອງຫມາຍເລີ່ມຕົ້ນ (ມູນຄ່າທີ່ແນ່ນອນໃນບໍລິເວນໃກ້ຄຽງ. 0xFFFFFFFF, ເຊິ່ງກໍານົດສະຖານະປັດຈຸບັນຂອງ TB), ບໍລິບົດ, ໂມດູນທີ່ສ້າງຂຶ້ນ, ແລະຈໍານວນ magic ສໍາລັບ debugging. ທໍາອິດເຄື່ອງຫມາຍຖືກວາງໄວ້ໃນ 0xFFFFFFFF - nບ່ອນທີ່ n - ຕົວເລກບວກເລັກໆນ້ອຍໆ, ແລະແຕ່ລະຄັ້ງທີ່ຖືກປະຕິບັດຜ່ານນາຍພາສາມັນເພີ່ມຂຶ້ນ 1. ເມື່ອມັນຮອດ. 0xFFFFFFFE, ການລວບລວມໄດ້ຈັດຂຶ້ນ, ໂມດູນໄດ້ຖືກບັນທຶກໄວ້ໃນຕາຕະລາງການທໍາງານ, ນໍາເຂົ້າເຂົ້າໄປໃນ "ຕົວເປີດ" ຂະຫນາດນ້ອຍ, ເຊິ່ງການປະຕິບັດໄດ້ມາຈາກ. tcg_qemu_tb_exec, ແລະໂມດູນໄດ້ຖືກໂຍກຍ້າຍອອກຈາກຫນ່ວຍຄວາມຈໍາ QEMU.

ເພື່ອປຽບທຽບຄລາສສິກ, "Crutch, ຫຼາຍປານໃດແມ່ນ intertwined ໃນສຽງນີ້ສໍາລັບຫົວໃຈຂອງ proger ... ". ຢ່າງໃດກໍຕາມ, ຄວາມຊົງຈໍາໄດ້ຮົ່ວໄຫລຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ. ຍິ່ງໄປກວ່ານັ້ນ, ມັນໄດ້ຖືກຄຸ້ມຄອງໂດຍ QEMU! ຂ້ອຍມີລະຫັດທີ່, ເມື່ອຂຽນຄໍາແນະນໍາຕໍ່ໄປ (ດີ, ນັ້ນແມ່ນ, ຕົວຊີ້), ລົບຫນຶ່ງທີ່ມີການເຊື່ອມຕໍ່ຢູ່ໃນສະຖານທີ່ນີ້ກ່ອນຫນ້ານີ້, ແຕ່ນີ້ບໍ່ໄດ້ຊ່ວຍ. ຕົວຈິງແລ້ວ, ໃນກໍລະນີທີ່ງ່າຍທີ່ສຸດ, QEMU ຈັດສັນຫນ່ວຍຄວາມຈໍາໃນຕອນເລີ່ມຕົ້ນແລະຂຽນລະຫັດທີ່ສ້າງຂຶ້ນຢູ່ທີ່ນັ້ນ. ເມື່ອ buffer ແລ່ນອອກ, ລະຫັດຖືກຖິ້ມອອກແລະຕົວຕໍ່ໄປເລີ່ມຕົ້ນທີ່ຈະຂຽນຢູ່ໃນສະຖານທີ່ຂອງມັນ.

ຫຼັງຈາກການສຶກສາລະຫັດ, ຂ້າພະເຈົ້າຮູ້ວ່າ trick ທີ່ມີເລກ magic ໄດ້ອະນຸຍາດໃຫ້ຂ້າພະເຈົ້າບໍ່ລົ້ມເຫລວໃນການທໍາລາຍ heap ໂດຍການປົດປ່ອຍບາງສິ່ງບາງຢ່າງທີ່ຜິດພາດໃນ buffer uninitialized ໃນຄັ້ງທໍາອິດ pass. ແຕ່ໃຜຂຽນໃຫມ່ buffer ເພື່ອ bypass ຫນ້າທີ່ຂອງຂ້ອຍຕໍ່ມາ? ດັ່ງທີ່ນັກພັດທະນາ Emscripten ແນະນໍາ, ເມື່ອຂ້ອຍພົບບັນຫາ, ຂ້ອຍໄດ້ສົ່ງລະຫັດຜົນໄດ້ຮັບກັບຄືນໄປຫາແອັບພລິເຄຊັນພື້ນເມືອງ, ຕັ້ງ Mozilla Record-Replay ໃສ່ມັນ ... ໂດຍທົ່ວໄປແລ້ວ, ໃນທີ່ສຸດຂ້ອຍເຂົ້າໃຈສິ່ງທີ່ງ່າຍດາຍ: ສໍາລັບແຕ່ລະບລັອກ, ກ struct TranslationBlock ກັບຄໍາອະທິບາຍຂອງມັນ. ເດົາຢູ່ໃສ... ຖືກຕ້ອງແລ້ວ, ກ່ອນທ່ອນໄມ້ຢູ່ໃນ buffer. ໂດຍຮູ້ເລື່ອງນີ້, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈທີ່ຈະເຊົາໃຊ້ໄມ້ຄ້ອນ (ຢ່າງຫນ້ອຍບາງອັນ), ແລະພຽງແຕ່ຖິ້ມຕົວເລກ magic, ແລະໂອນຄໍາທີ່ຍັງເຫຼືອໄປ. struct TranslationBlock, ການສ້າງບັນຊີລາຍຊື່ທີ່ເຊື່ອມຕໍ່ດຽວທີ່ສາມາດຜ່ານໄດ້ໄວເມື່ອ cache ການແປພາສາຖືກຕັ້ງໃຫມ່, ແລະເພີ່ມຄວາມຊົງຈໍາ.

ໄມ້ຄ້ອນບາງອັນຍັງຄົງຢູ່: ຕົວຢ່າງ, ເຄື່ອງຫມາຍຈຸດຢູ່ໃນລະຫັດ buffer - ບາງອັນແມ່ນງ່າຍດາຍ BinaryenExpressionRef, ນັ້ນແມ່ນ, ພວກເຂົາເບິ່ງການສະແດງອອກທີ່ຈໍາເປັນຕ້ອງຖືກໃສ່ເຂົ້າໄປໃນຕົວບລັອກພື້ນຖານທີ່ສ້າງຂຶ້ນ, ສ່ວນຫນຶ່ງແມ່ນເງື່ອນໄຂສໍາລັບການຫັນປ່ຽນລະຫວ່າງ BBs, ສ່ວນຫນຶ່ງແມ່ນບ່ອນທີ່ຈະໄປ. ດີ, ມີທ່ອນໄມ້ທີ່ກຽມໄວ້ແລ້ວສໍາລັບ Relooper ທີ່ຕ້ອງໄດ້ຮັບການເຊື່ອມຕໍ່ຕາມເງື່ອນໄຂ. ເພື່ອຈໍາແນກພວກມັນ, ສົມມຸດຕິຖານຖືກນໍາໃຊ້ວ່າພວກມັນຖືກຈັດຮຽງທັງຫມົດຢ່າງຫນ້ອຍສີ່ໄບ, ດັ່ງນັ້ນທ່ານສາມາດນໍາໃຊ້ສອງບິດທີ່ສໍາຄັນສໍາລັບປ້າຍຊື່ຢ່າງປອດໄພ, ທ່ານພຽງແຕ່ຕ້ອງຈື່ຈໍາເອົາມັນອອກຖ້າຈໍາເປັນ. ໂດຍວິທີທາງການ, ປ້າຍຊື່ດັ່ງກ່າວໄດ້ຖືກນໍາໃຊ້ແລ້ວໃນ QEMU ເພື່ອຊີ້ບອກເຫດຜົນສໍາລັບການອອກຈາກ loop TCG.

ການນໍາໃຊ້ Binaryen

ໂມດູນໃນ WebAssembly ມີຟັງຊັນ, ແຕ່ລະອັນປະກອບດ້ວຍຮ່າງກາຍ, ເຊິ່ງເປັນການສະແດງອອກ. ການສະແດງອອກແມ່ນການປະຕິບັດ unary ແລະ binary, ຕັນທີ່ປະກອບດ້ວຍບັນຊີລາຍຊື່ຂອງສະແດງອອກອື່ນໆ, ການໄຫຼຄວບຄຸມ, ແລະອື່ນໆ. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າແລ້ວ, ການໄຫຼເຂົ້າຂອງການຄວບຄຸມຢູ່ທີ່ນີ້ຖືກຈັດຂື້ນຢ່າງແນ່ນອນເປັນສາຂາລະດັບສູງ, loops, ການໂທຫາຫນ້າທີ່, ແລະອື່ນໆ. ການໂຕ້ຖຽງກັບຫນ້າທີ່ບໍ່ໄດ້ຜ່ານໃນ stack, ແຕ່ຢ່າງຊັດເຈນ, ຄືກັນກັບໃນ JS. ຍັງມີຕົວແປທົ່ວໂລກ, ແຕ່ຂ້ອຍບໍ່ໄດ້ໃຊ້ພວກມັນ, ດັ່ງນັ້ນຂ້ອຍຈະບໍ່ບອກເຈົ້າກ່ຽວກັບພວກມັນ.

ຟັງຊັນຍັງມີຕົວແປທ້ອງຖິ່ນ, ຕົວເລກຈາກສູນ, ຂອງປະເພດ: int32 / int64 / float / double. ໃນກໍລະນີນີ້, ຕົວແປທ້ອງຖິ່ນທໍາອິດ n ແມ່ນການໂຕ້ຖຽງທີ່ຖືກສົ່ງໄປຫາຫນ້າທີ່. ກະລຸນາຮັບຊາບວ່າເຖິງແມ່ນວ່າທຸກຢ່າງຢູ່ທີ່ນີ້ບໍ່ແມ່ນລະດັບຕໍ່າທັງໝົດໃນແງ່ຂອງການໄຫຼເຂົ້າຄວບຄຸມ, ຈຳນວນເຕັມຍັງບໍ່ມີຄຸນສົມບັດ “ເຊັນ/ບໍ່ໄດ້ເຊັນ”: ຕົວເລກປະຕິບັດແນວໃດຂຶ້ນກັບລະຫັດປະຕິບັດງານ.

ໂດຍທົ່ວໄປແລ້ວ, Binaryen ສະຫນອງ C-API ງ່າຍດາຍ: ທ່ານ​ສ້າງ​ໂມ​ດູນ​, ໃນພຣະອົງ ສ້າງການສະແດງອອກ - unary, binary, blocks ຈາກການສະແດງອອກອື່ນໆ, ການໄຫຼຄວບຄຸມ, ແລະອື່ນໆ. ຫຼັງຈາກນັ້ນ, ທ່ານສ້າງຫນ້າທີ່ທີ່ມີການສະແດງອອກເປັນຮ່າງກາຍຂອງມັນ. ຖ້າທ່ານ, ເຊັ່ນຂ້ອຍ, ມີເສັ້ນສະແດງການປ່ຽນລະດັບຕ່ໍາ, ອົງປະກອບ relooper ຈະຊ່ວຍເຈົ້າໄດ້. ເທົ່າທີ່ຂ້າພະເຈົ້າເຂົ້າໃຈ, ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ການຄວບຄຸມລະດັບສູງຂອງການໄຫຼຂອງການປະຕິບັດໃນຕັນ, ຕາບໃດທີ່ມັນບໍ່ເກີນຂອບເຂດຂອງຕັນ - ນັ້ນແມ່ນ, ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດໃຫ້ເສັ້ນທາງໄວ / ຊ້າພາຍໃນ. ການແຍກເສັ້ນທາງພາຍໃນລະຫັດການປະມວນຜົນ cache TLB ທີ່ສ້າງຂຶ້ນ, ແຕ່ບໍ່ໃຫ້ແຊກແຊງການໄຫຼເຂົ້າຂອງການຄວບຄຸມ "ພາຍນອກ". ໃນເວລາທີ່ທ່ານປ່ອຍ relooper, ຕັນຂອງມັນຖືກປົດປ່ອຍ; ເມື່ອທ່ານປ່ອຍໂມດູນ, ການສະແດງຜົນ, ຫນ້າທີ່, ແລະອື່ນໆ. ຈັດສັນໃຫ້ມັນຫາຍໄປ. ສະໜາມກິລາ.

ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານຕ້ອງການຕີຄວາມຫມາຍລະຫັດໂດຍບໍ່ໄດ້ສ້າງແລະລຶບຕົວແປທີ່ບໍ່ຈໍາເປັນ, ມັນອາດຈະມີຄວາມຫມາຍທີ່ຈະເອົາເຫດຜົນນີ້ເຂົ້າໄປໃນໄຟລ໌ C ++, ແລະຈາກນັ້ນໂດຍກົງຈັດການ C ++ API ທັງຫມົດຂອງຫ້ອງສະຫມຸດ, bypassing ready- ເຮັດ wrappers.

ດັ່ງນັ້ນເພື່ອສ້າງລະຫັດທີ່ທ່ານຕ້ອງການ

// настроить глобальные параметры (можно поменять потом)
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 ແລະໃນເວລາດຽວກັນເຂົ້າເຖິງຫນ້າທີ່ລວບລວມຢ່າງໄວວາ, array ໄດ້ຖືກສ້າງຂື້ນ (ຕາຕະລາງຫນ້າທີ່ສໍາລັບການນໍາເຂົ້າເຂົ້າໄປໃນ launcher), ແລະຟັງຊັນທີ່ສ້າງຂຶ້ນໄດ້ຖືກຈັດໃສ່ຢູ່ທີ່ນັ້ນ. ເພື່ອຄິດໄລ່ດັດຊະນີຢ່າງໄວວາ, ດັດຊະນີຂອງສູນການແປຄໍາທີ່ໃຊ້ໃນເບື້ອງຕົ້ນໄດ້ຖືກນໍາໃຊ້ເປັນມັນ, ແຕ່ຫຼັງຈາກນັ້ນດັດຊະນີທີ່ຄິດໄລ່ໂດຍໃຊ້ສູດນີ້ເລີ່ມຕົ້ນພຽງແຕ່ເຫມາະກັບພາກສະຫນາມໃນ. struct TranslationBlock.

ໂດຍວິທີທາງການ, ການສາທິດ (ປະຈຸບັນມີໃບອະນຸຍາດຂີ້ຄ້ານ) ພຽງແຕ່ເຮັດວຽກໄດ້ດີໃນ Firefox. ນັກພັດທະນາ Chrome ໄດ້ somehow ບໍ່ພ້ອມ ກັບຄວາມຈິງທີ່ວ່າຜູ້ໃດຜູ້ຫນຶ່ງຕ້ອງການສ້າງຫຼາຍກວ່າຫນຶ່ງພັນຕົວຢ່າງຂອງໂມດູນ WebAssembly, ດັ່ງນັ້ນເຂົາເຈົ້າພຽງແຕ່ຈັດສັນ gigabyte ຂອງພື້ນທີ່ທີ່ຢູ່ virtual ສໍາລັບແຕ່ລະ ...

ນັ້ນແມ່ນທັງຫມົດສໍາລັບໃນປັດຈຸບັນ. ບາງທີອາດມີບົດຄວາມອື່ນຖ້າໃຜສົນໃຈ. ນັ້ນແມ່ນ, ຍັງມີຢ່າງຫນ້ອຍ ເທົ່ານັ້ນ ເຮັດໃຫ້ອຸປະກອນບລັອກເຮັດວຽກ. ມັນຍັງອາດຈະມີຄວາມຫມາຍທີ່ຈະເຮັດໃຫ້ການລວບລວມຂອງໂມດູນ WebAssembly asynchronous, ຕາມປະເພນີໃນໂລກ JS, ເນື່ອງຈາກວ່າຍັງມີນາຍພາສາທີ່ສາມາດເຮັດໄດ້ທັງຫມົດນີ້ຈົນກ່ວາໂມດູນພື້ນເມືອງພ້ອມ.

ສຸດທ້າຍ riddle: ທ່ານໄດ້ລວບລວມຂໍ້ມູນຖານສອງໃນສະຖາປັດຕະຍະກໍາ 32-bit, ແຕ່ລະຫັດ, ໂດຍຜ່ານການດໍາເນີນງານຫນ່ວຍຄວາມຈໍາ, ປີນຈາກ Binaryen, ບາງບ່ອນຢູ່ໃນ stack, ຫຼືບ່ອນອື່ນໃນ 2 GB ເທິງຂອງພື້ນທີ່ທີ່ຢູ່ 32-bit. ບັນຫາແມ່ນວ່າຈາກທັດສະນະຂອງ Binaryen ນີ້ແມ່ນການເຂົ້າເຖິງຂະຫນາດໃຫຍ່ເກີນໄປເປັນທີ່ຢູ່ຜົນໄດ້ຮັບ. ວິທີການເພື່ອໃຫ້ໄດ້ຮັບປະມານນີ້?

ໃນວິທີການຂອງ admin

ຂ້າພະເຈົ້າບໍ່ໄດ້ສິ້ນສຸດການທົດສອບນີ້, ແຕ່ຄວາມຄິດທໍາອິດຂອງຂ້ອຍແມ່ນ "ຖ້າຂ້ອຍຕິດຕັ້ງ Linux 32-bit?" ຫຼັງຈາກນັ້ນ, ສ່ວນເທິງຂອງພື້ນທີ່ທີ່ຢູ່ຈະຖືກຄອບຄອງໂດຍ kernel. ຄໍາຖາມດຽວແມ່ນຫຼາຍປານໃດຈະຖືກຄອບຄອງ: 1 ຫຼື 2 Gb.

ໃນວິທີການຂອງນັກຂຽນໂປລແກລມ (ທາງເລືອກສໍາລັບນັກປະຕິບັດ)

ໃຫ້ລະເບີດຟອງຢູ່ເທິງສຸດຂອງພື້ນທີ່ທີ່ຢູ່. ຂ້ອຍເອງບໍ່ເຂົ້າໃຈວ່າເປັນຫຍັງມັນເຮັດວຽກ - ຢູ່ທີ່ນັ້ນ ແລ້ວ ຕ້ອງມີ stack ເປັນ. ແຕ່ "ພວກເຮົາເປັນຜູ້ປະຕິບັດ: ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກສໍາລັບພວກເຮົາ, ແຕ່ບໍ່ມີໃຜຮູ້ວ່າເປັນຫຍັງ ... "

// 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));
}

... ມັນເປັນຄວາມຈິງທີ່ວ່າມັນບໍ່ເຂົ້າກັນໄດ້ກັບ Valgrind, ແຕ່, ໂຊກດີ, Valgrind ຕົວຂອງມັນເອງໄດ້ກະຕຸ້ນໃຫ້ທຸກຄົນອອກຈາກບ່ອນນັ້ນ :)

ບາງທີບາງຄົນຈະໃຫ້ຄໍາອະທິບາຍທີ່ດີກວ່າວິທີການລະຫັດຂອງຂ້ອຍເຮັດວຽກ ...

ແຫຼ່ງຂໍ້ມູນ: www.habr.com