ສອງສາມປີກ່ອນ Fabrice Bellard ຂຽນໂດຍ jslinux ເປັນ emulator PC ທີ່ຂຽນໃນ JavaScript. ຫຼັງຈາກນັ້ນ, ຢ່າງຫນ້ອຍມີຫຼາຍກວ່ານັ້ນ Virtual x86. ແຕ່ພວກເຂົາທັງຫມົດ, ເທົ່າທີ່ຂ້າພະເຈົ້າຮູ້, ເປັນນາຍພາສາ, ໃນຂະນະທີ່ Qemu, ຂຽນກ່ອນຫນ້ານີ້ໂດຍ Fabrice Bellard ດຽວກັນ, ແລະ, ອາດຈະເປັນ, emulator ທີ່ທັນສະໄຫມທີ່ເຄົາລົບຕົນເອງ, ໃຊ້ການລວບລວມ JIT ຂອງລະຫັດແຂກເຂົ້າໄປໃນລະຫັດລະບົບເຈົ້າພາບ. ມັນເບິ່ງຄືວ່າມັນເຖິງເວລາທີ່ຈະປະຕິບັດວຽກງານກົງກັນຂ້າມທີ່ກ່ຽວຂ້ອງກັບຕົວທ່ອງເວັບທີ່ແກ້ໄຂ: ການລວບລວມ JIT ຂອງລະຫັດເຄື່ອງຈັກເຂົ້າໃນ JavaScript, ເຊິ່ງມັນເບິ່ງຄືວ່າມີເຫດຜົນທີ່ສຸດທີ່ຈະ Port Qemu. ມັນເບິ່ງຄືວ່າ, ເປັນຫຍັງ Qemu, ມີ emulators ທີ່ງ່າຍດາຍແລະເປັນມິດກັບຜູ້ໃຊ້ - ດຽວກັນ VirtualBox, ສໍາລັບການຍົກຕົວຢ່າງ - ຕິດຕັ້ງແລະເຮັດວຽກ. ແຕ່ Qemu ມີລັກສະນະທີ່ຫນ້າສົນໃຈຫຼາຍ

• ແຫຼ່ງເປີດ
• ຄວາມສາມາດໃນການເຮັດວຽກໂດຍບໍ່ມີຕົວຂັບ kernel
• ຄວາມສາມາດໃນການເຮັດວຽກໃນຮູບແບບນາຍພາສາ
• ສະ​ຫນັບ​ສະ​ຫນູນ​ຈໍາ​ນວນ​ຫຼາຍ​ຂອງ​ທັງ​ສະ​ຖາ​ປັດ​ຕະ​ເຈົ້າ​ພາບ​ແລະ​ແຂກ​

ກ່ຽວກັບຈຸດທີສາມ, ຕອນນີ້ຂ້ອຍສາມາດອະທິບາຍໄດ້ວ່າໃນຕົວຈິງແລ້ວ, ໃນໂຫມດ TCI, ມັນບໍ່ແມ່ນຄໍາແນະນໍາຂອງເຄື່ອງແຂກທີ່ຖືກຕີຄວາມຫມາຍ, ແຕ່ bytecode ທີ່ໄດ້ຮັບຈາກພວກມັນ, ແຕ່ນີ້ບໍ່ໄດ້ປ່ຽນແປງຄວາມສໍາຄັນ - ເພື່ອສ້າງແລະດໍາເນີນການ. Qemu ກ່ຽວກັບສະຖາປັດຕະຍະກໍາໃຫມ່, ຖ້າທ່ານໂຊກດີ, A C compiler ແມ່ນພຽງພໍ - ການຂຽນຕົວສ້າງລະຫັດສາມາດຖືກເລື່ອນອອກໄປ.

ແລະໃນປັດຈຸບັນ, ຫຼັງຈາກສອງປີຂອງ tinkering leisurely ກັບລະຫັດແຫຼ່ງ Qemu ໃນເວລາຫວ່າງຂອງຂ້າພະເຈົ້າ, prototype ການເຮັດວຽກໄດ້ປາກົດ, ທີ່ທ່ານສາມາດດໍາເນີນການໄດ້, ສໍາລັບການຍົກຕົວຢ່າງ, Kolibri OS.

Emscripten ແມ່ນຫຍັງ

ໃນປັດຈຸບັນ, ຜູ້ລວບລວມຂໍ້ມູນຈໍານວນຫຼາຍໄດ້ປາກົດ, ຜົນໄດ້ຮັບສຸດທ້າຍແມ່ນ JavaScript. ບາງຄົນ, ເຊັ່ນ Type Script, ໃນເບື້ອງຕົ້ນມີຈຸດປະສົງເພື່ອເປັນວິທີທີ່ດີທີ່ສຸດໃນການຂຽນເວັບ. ໃນເວລາດຽວກັນ, Emscripten ແມ່ນວິທີທີ່ຈະເອົາລະຫັດ C ຫຼື C ++ ທີ່ມີຢູ່ແລ້ວແລະລວບລວມມັນເຂົ້າໄປໃນແບບຟອມທີ່ສາມາດອ່ານໄດ້ຂອງຕົວທ່ອງເວັບ. ສຸດ ຫນ້ານີ້ ພວກ​ເຮົາ​ໄດ້​ເກັບ​ກໍາ​ຂໍ້​ມູນ​ຫຼາຍ​ພອດ​ຂອງ​ໂຄງ​ການ​ທີ່​ມີ​ຊື່​ສຽງ​: ທີ່ນີ້ຕົວຢ່າງ, ທ່ານສາມາດເບິ່ງ PyPy - ໂດຍວິທີທາງການ, ພວກເຂົາເຈົ້າອ້າງວ່າມີ JIT ແລ້ວ. ໃນຄວາມເປັນຈິງ, ບໍ່ແມ່ນທຸກໆໂຄງການສາມາດຖືກລວບລວມແລະດໍາເນີນການໃນຕົວທ່ອງເວັບ - ມີຈໍານວນ ຄຸນ​ລັກ​ສະ​ນະ, ທີ່ທ່ານຕ້ອງເອົາໃຈໃສ່ກັບ, ຢ່າງໃດກໍຕາມ, ເປັນ inscription ໃນຫນ້າດຽວກັນເວົ້າວ່າ "Emscripten ສາມາດຖືກນໍາໃຊ້ເພື່ອລວບລວມເກືອບທຸກ. ພາບ ລະຫັດ C/C++ ກັບ JavaScript ", ນັ້ນແມ່ນ, ມີການປະຕິບັດຈໍານວນຫນຶ່ງທີ່ບໍ່ໄດ້ກໍານົດພຶດຕິກໍາຕາມມາດຕະຖານ, ແຕ່ມັກຈະເຮັດວຽກຢູ່ໃນ x86 - ຕົວຢ່າງ, ການເຂົ້າເຖິງຕົວແປທີ່ບໍ່ສອດຄ່ອງ, ເຊິ່ງໂດຍທົ່ວໄປແມ່ນຫ້າມໃນບາງສະຖາປັດຕະຍະກໍາ. , Qemu ເປັນໂຄງການຂ້າມເວທີແລະ , ຂ້າພະເຈົ້າຢາກຈະເຊື່ອ, ແລະມັນບໍ່ມີພຶດຕິກໍາທີ່ບໍ່ໄດ້ກໍານົດໄວ້ຫຼາຍ - ເອົາມັນແລະລວບລວມ, ຫຼັງຈາກນັ້ນ tinker ເລັກນ້ອຍກັບ JIT - ແລະທ່ານກໍາລັງເຮັດ! ແຕ່ນັ້ນບໍ່ແມ່ນ. ກໍລະນີ...

ພະຍາຍາມ ທຳ ອິດ

ໂດຍທົ່ວໄປແລ້ວ, ຂ້ອຍບໍ່ແມ່ນຄົນທໍາອິດທີ່ຄິດທີ່ຈະເອົາ Qemu ໄປຫາ JavaScript. ມີຄໍາຖາມທີ່ຖາມຢູ່ໃນເວທີ ReactOS ຖ້າສິ່ງນີ້ເປັນໄປໄດ້ໂດຍໃຊ້ Emscripten. ເຖິງແມ່ນວ່າກ່ອນຫນ້ານີ້, ມີຂ່າວລືວ່າ Fabrice Bellard ເຮັດສິ່ງນີ້ສ່ວນບຸກຄົນ, ແຕ່ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບ jslinux, ເຊິ່ງເທົ່າທີ່ຂ້ອຍຮູ້, ແມ່ນພຽງແຕ່ຄວາມພະຍາຍາມເພື່ອບັນລຸການປະຕິບັດທີ່ພຽງພໍໃນ JS ດ້ວຍຕົນເອງ, ແລະຖືກຂຽນຈາກຈຸດເລີ່ມຕົ້ນ. ຕໍ່ມາ, Virtual x86 ໄດ້ຖືກຂຽນ - ແຫຼ່ງທີ່ບໍ່ເຂົ້າໃຈໄດ້ຖືກຈັດພີມມາສໍາລັບມັນ, ແລະ, ດັ່ງທີ່ໄດ້ກ່າວ, "ຄວາມເປັນຈິງ" ທີ່ຍິ່ງໃຫຍ່ກວ່າຂອງ emulation ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ SeaBIOS ເປັນ firmware. ນອກຈາກນັ້ນ, ມີຄວາມພະຍາຍາມທີ່ຈະ Port Qemu ຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງໂດຍໃຊ້ Emscripten - ຂ້ອຍພະຍາຍາມເຮັດສິ່ງນີ້ ຄູ່ເຕົ້າສຽບ, ແຕ່ການພັດທະນາ, ເທົ່າທີ່ຂ້າພະເຈົ້າເຂົ້າໃຈ, ໄດ້ຖືກ frozen.

ດັ່ງນັ້ນ, ມັນຈະເບິ່ງຄືວ່າ, ນີ້ແມ່ນແຫຼ່ງຂໍ້ມູນ, ນີ້ແມ່ນ Emscripten - ເອົາມັນແລະລວບລວມ. ແຕ່ຍັງມີຫ້ອງສະຫມຸດທີ່ Qemu ຂຶ້ນກັບ, ແລະຫ້ອງສະຫມຸດທີ່ຫໍສະຫມຸດເຫຼົ່ານັ້ນຂຶ້ນກັບ, ແລະອື່ນໆ, ແລະຫນຶ່ງໃນນັ້ນແມ່ນ. libffi, ເຊິ່ງ glib ແມ່ນຂຶ້ນກັບ. ມີຂ່າວລືກ່ຽວກັບອິນເຕີເນັດວ່າມີຫນຶ່ງໃນບ່ອນເກັບມ້ຽນຂະຫນາດໃຫຍ່ຂອງຫໍສະຫມຸດສໍາລັບ Emscripten, ແຕ່ມັນກໍ່ຍາກທີ່ຈະເຊື່ອ: ທໍາອິດ, ມັນບໍ່ໄດ້ມີຈຸດປະສົງທີ່ຈະລວບລວມຂໍ້ມູນໃຫມ່, ອັນທີສອງ, ມັນແມ່ນລະດັບຕ່ໍາເກີນໄປ. ຫ້ອງສະຫມຸດພຽງແຕ່ເອົາຂຶ້ນ, ແລະລວບລວມກັບ JS. ແລະມັນບໍ່ແມ່ນພຽງແຕ່ເລື່ອງຂອງການປະກອບການປະກອບ - ບາງທີ, ຖ້າທ່ານບິດມັນ, ສໍາລັບບາງສົນທິສັນຍາການໂທຫາທ່ານສາມາດສ້າງການໂຕ້ຖຽງທີ່ຈໍາເປັນໃນ stack ແລະໂທຫາຫນ້າທີ່ໂດຍບໍ່ມີພວກມັນ. ແຕ່ Emscripten ແມ່ນສິ່ງທີ່ຫຍຸ້ງຍາກ: ເພື່ອເຮັດໃຫ້ລະຫັດທີ່ສ້າງຂຶ້ນເບິ່ງຄືວ່າຄຸ້ນເຄີຍກັບຕົວທ່ອງເວັບ JS engine optimizer, ບາງ tricks ຖືກນໍາໃຊ້. ໂດຍສະເພາະ, ອັນທີ່ເອີ້ນວ່າ relooping - ເຄື່ອງສ້າງລະຫັດໂດຍໃຊ້ LLVM IR ທີ່ໄດ້ຮັບກັບບາງຄໍາແນະນໍາການປ່ຽນແປງທີ່ບໍ່ມີຕົວຕົນພະຍາຍາມສ້າງ ifs, loops, ແລະອື່ນໆ. ແລ້ວ, ການໂຕ້ຖຽງຖືກສົ່ງກັບຫນ້າທີ່ແນວໃດ? ຕາມທໍາມະຊາດ, ເປັນການໂຕ້ຖຽງກັບຫນ້າທີ່ JS, ນັ້ນແມ່ນ, ຖ້າເປັນໄປໄດ້, ບໍ່ແມ່ນຜ່ານ stack.

ໃນຕອນເລີ່ມຕົ້ນມີຄວາມຄິດທີ່ພຽງແຕ່ຂຽນການທົດແທນຂອງ libffi ກັບ JS ແລະດໍາເນີນການທົດສອບມາດຕະຖານ, ແຕ່ໃນທີ່ສຸດຂ້ອຍກໍ່ສັບສົນກ່ຽວກັບວິທີການສ້າງໄຟລ໌ header ຂອງຂ້ອຍເພື່ອໃຫ້ພວກເຂົາເຮັດວຽກກັບລະຫັດທີ່ມີຢູ່ - ຂ້ອຍສາມາດເຮັດຫຍັງໄດ້, ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າ, "ວຽກງານທີ່ສັບສົນຫຼາຍແມ່ນ "ພວກເຮົາໂງ່ຫຼາຍບໍ?" ຂ້ອຍຕ້ອງ port libffi ໄປຫາສະຖາປັດຕະຍະກໍາອື່ນ, ດັ່ງນັ້ນການເວົ້າ - ໂຊກດີ, Emscripten ມີທັງ macro ສໍາລັບການປະກອບ inline (ໃນ Javascript, ແມ່ນ - ດີ, ໃດກໍ່ຕາມສະຖາປັດຕະ, ດັ່ງນັ້ນ assembler), ແລະຄວາມສາມາດໃນການແລ່ນລະຫັດທີ່ສ້າງຂຶ້ນໃນການບິນໄດ້. ໂດຍທົ່ວໄປ, ຫຼັງຈາກ tinkering ກັບ fragments libffi ທີ່ຂຶ້ນກັບເວທີສໍາລັບບາງເວລາ, ຂ້າພະເຈົ້າໄດ້ຮັບບາງລະຫັດທີ່ລວບລວມໄດ້ແລະແລ່ນມັນໃນການທົດສອບຄັ້ງທໍາອິດທີ່ຂ້າພະເຈົ້າເຂົ້າມາ. ເພື່ອຄວາມແປກໃຈຂອງຂ້ອຍ, ການທົດສອບໄດ້ປະສົບຜົນສໍາເລັດ. ຕົກຕະລຶງກັບຄວາມສະຫລາດຂອງຂ້ອຍ - ບໍ່ເປັນເລື່ອງຕະຫລົກ, ມັນເຮັດວຽກຈາກການເປີດຕົວຄັ້ງທໍາອິດ - ຂ້ອຍ, ຍັງບໍ່ເຊື່ອຕາຂອງຂ້ອຍ, ໄດ້ໄປເບິ່ງລະຫັດຜົນໄດ້ຮັບອີກເທື່ອຫນຶ່ງ, ເພື່ອປະເມີນບ່ອນທີ່ຈະຂຸດຕໍ່ໄປ. ທີ່ນີ້ຂ້ອຍໄດ້ຫມາກແຫ້ງເປືອກແຂງເປັນຄັ້ງທີສອງ - ສິ່ງດຽວທີ່ຫນ້າທີ່ຂອງຂ້ອຍເຮັດແມ່ນ ffi_call - ນີ້​ລາຍ​ງານ​ການ​ໂທ​ສົບ​ຜົນ​ສໍາ​ເລັດ​. ບໍ່ມີການໂທຫາຕົວມັນເອງ. ດັ່ງນັ້ນຂ້າພະເຈົ້າໄດ້ສົ່ງຄໍາຮ້ອງຂໍການດຶງຄັ້ງທໍາອິດຂອງຂ້ອຍ, ເຊິ່ງແກ້ໄຂຂໍ້ຜິດພາດໃນການທົດສອບທີ່ຊັດເຈນກັບນັກຮຽນ Olympiad - ຕົວເລກທີ່ແທ້ຈິງບໍ່ຄວນຖືກປຽບທຽບກັບ. a == b ແລະເຖິງແມ່ນວ່າວິທີການ a - b < EPS - ທ່ານຍັງຈໍາເປັນຕ້ອງຈື່ໂມດູນ, ຖ້າບໍ່ດັ່ງນັ້ນ 0 ຈະກາຍເປັນຫຼາຍເທົ່າກັບ 1/3 ... ໂດຍທົ່ວໄປ, ຂ້າພະເຈົ້າໄດ້ມາກັບພອດທີ່ແນ່ນອນຂອງ libffi, ເຊິ່ງຜ່ານການທົດສອບທີ່ງ່າຍດາຍທີ່ສຸດ, ແລະສິ່ງທີ່ glib ແມ່ນ. ລວບລວມ - ຂ້ອຍຕັດສິນໃຈວ່າມັນເປັນສິ່ງຈໍາເປັນ, ຂ້ອຍຈະເພີ່ມມັນຕໍ່ມາ. ຊອກຫາລ່ວງຫນ້າ, ຂ້າພະເຈົ້າຈະເວົ້າວ່າ, ຍ້ອນວ່າມັນຫັນອອກ, compiler ບໍ່ໄດ້ລວມເອົາຫນ້າທີ່ libffi ໃນລະຫັດສຸດທ້າຍ.

ແຕ່, ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າແລ້ວ, ມີຂໍ້ຈໍາກັດບາງຢ່າງ, ແລະໃນບັນດາການນໍາໃຊ້ຟຣີຂອງພຶດຕິກໍາທີ່ບໍ່ໄດ້ກໍານົດໄວ້, ລັກສະນະທີ່ບໍ່ຫນ້າພໍໃຈຫຼາຍໄດ້ຖືກເຊື່ອງໄວ້ - JavaScript ໂດຍການອອກແບບບໍ່ສະຫນັບສະຫນູນ multithreading ກັບຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນ. ໃນຫຼັກການ, ນີ້ສາມາດຖືກເອີ້ນວ່າເປັນຄວາມຄິດທີ່ດີ, ແຕ່ບໍ່ແມ່ນສໍາລັບລະຫັດ porting ທີ່ສະຖາປັດຕະຍະກໍາຖືກຜູກມັດກັບ C threads. ເວົ້າໂດຍທົ່ວໄປແລ້ວ, Firefox ກໍາລັງທົດລອງກັບການສະຫນັບສະຫນູນພະນັກງານຮ່ວມກັນ, ແລະ Emscripten ມີການປະຕິບັດ pthread ສໍາລັບພວກເຂົາ, ແຕ່ຂ້ອຍບໍ່ຕ້ອງການທີ່ຈະຂຶ້ນກັບມັນ. ຂ້ອຍຕ້ອງຄ່ອຍໆຮາກອອກ multithreading ຈາກລະຫັດ Qemu - ນັ້ນແມ່ນ, ຊອກຫາບ່ອນທີ່ກະທູ້ກໍາລັງແລ່ນ, ຍ້າຍຮ່າງກາຍຂອງ loop ທີ່ແລ່ນຢູ່ໃນກະທູ້ນີ້ເຂົ້າໄປໃນຫນ້າທີ່ແຍກຕ່າງຫາກ, ແລະເອີ້ນຟັງຊັນດັ່ງກ່າວຫນຶ່ງຄັ້ງຈາກ loop ຕົ້ນຕໍ.

ຄວາມພະຍາຍາມຄັ້ງທີສອງ

ໃນບາງຈຸດ, ມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າບັນຫາແມ່ນຍັງມີຢູ່, ແລະວ່າດ້ວຍໄມ້ຄ້ອນເທົ້າທີ່ໂດດດ່ຽວຢູ່ຮອບລະຫັດຈະບໍ່ນໍາໄປສູ່ສິ່ງທີ່ດີ. ສະຫຼຸບ: ພວກເຮົາຈໍາເປັນຕ້ອງ somehow systematize ຂະບວນການເພີ່ມ crutches ໄດ້. ດັ່ງນັ້ນ, ເວີຊັ່ນ 2.4.1 ທີ່ສົດໆຕອນນັ້ນຖືກເອົາໄປ (ບໍ່ແມ່ນ 2.5.0, ເພາະໃຜຈະຮູ້, ຈະມີບັກໃນເວີຊັ່ນໃໝ່ທີ່ຍັງບໍ່ທັນຈັບໄດ້ ແລະຂ້ອຍກໍ່ມີບັກຂອງຂ້ອຍເອງ. ), ແລະສິ່ງທໍາອິດແມ່ນການຂຽນຄືນໃຫມ່ຢ່າງປອດໄພ thread-posix.c. ດີ, ນັ້ນແມ່ນ, ປອດໄພ: ຖ້າຜູ້ໃດຜູ້ນຶ່ງພະຍາຍາມປະຕິບັດການປະຕິບັດງານທີ່ນໍາໄປສູ່ການຂັດຂວາງ, ຫນ້າທີ່ຖືກເອີ້ນວ່າທັນທີ abort() - ແນ່ນອນ, ນີ້ບໍ່ໄດ້ແກ້ໄຂບັນຫາທັງຫມົດໃນເວລາດຽວ, ແຕ່ຢ່າງຫນ້ອຍມັນກໍ່ເປັນທີ່ຫນ້າພໍໃຈຫຼາຍກ່ວາການໄດ້ຮັບຂໍ້ມູນທີ່ບໍ່ສອດຄ່ອງກັນຢ່າງງຽບໆ.

ໂດຍທົ່ວໄປ, ທາງເລືອກ Emscripten ແມ່ນມີປະໂຫຍດຫຼາຍໃນການສົ່ງລະຫັດໄປຫາ JS -s ASSERTIONS=1 -s SAFE_HEAP=1 - ພວກເຂົາເຈົ້າຈັບບາງປະເພດຂອງພຶດຕິກໍາທີ່ບໍ່ໄດ້ກໍານົດ, ເຊັ່ນ: ການໂທຫາທີ່ຢູ່ unaligned (ຊຶ່ງບໍ່ສອດຄ່ອງທັງຫມົດກັບລະຫັດສໍາລັບ arrays ພິມເຊັ່ນ: HEAP32[addr >> 2] = 1) ຫຼືໂທຫາຟັງຊັນທີ່ມີຈໍານວນການໂຕ້ຖຽງທີ່ບໍ່ຖືກຕ້ອງ.

ໂດຍວິທີທາງການ, ຄວາມຜິດພາດການຈັດຕໍາແຫນ່ງແມ່ນບັນຫາແຍກຕ່າງຫາກ. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າແລ້ວ, Qemu ມີ backend ການຕີຄວາມ "degenerate" ສໍາລັບການຜະລິດລະຫັດ TCI (ນາຍພາສາລະຫັດຂະຫນາດນ້ອຍ), ແລະການກໍ່ສ້າງແລະດໍາເນີນການ Qemu ໃນສະຖາປັດຕະຍະກໍາໃຫມ່, ຖ້າຫາກວ່າທ່ານໂຊກດີ, ເປັນ compiler C ແມ່ນພຽງພໍ. "ຖ້າທ່ານໂຊກດີ". ຂ້ອຍໂຊກບໍ່ດີ, ແລະມັນໄດ້ຫັນອອກວ່າ TCI ໃຊ້ການເຂົ້າເຖິງທີ່ບໍ່ສອດຄ່ອງກັນເມື່ອວິເຄາະ bytecode ຂອງມັນ. ນັ້ນແມ່ນ, ໃນທຸກປະເພດຂອງ ARM ແລະສະຖາປັດຕະຍະກໍາອື່ນໆທີ່ມີການເຂົ້າເຖິງລະດັບຄວາມຈໍາເປັນ, Qemu ລວບລວມຍ້ອນວ່າພວກເຂົາມີ backend TCG ປົກກະຕິທີ່ສ້າງລະຫັດພື້ນເມືອງ, ແຕ່ວ່າ TCI ຈະເຮັດວຽກກັບພວກມັນແມ່ນຄໍາຖາມອື່ນ. ຢ່າງໃດກໍຕາມ, ຍ້ອນວ່າມັນໄດ້ຫັນອອກ, ເອກະສານ TCI ຊີ້ໃຫ້ເຫັນບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນ. ດັ່ງນັ້ນ, ການເອີ້ນຟັງຊັນສໍາລັບການອ່ານທີ່ບໍ່ສອດຄ່ອງໄດ້ຖືກເພີ່ມເຂົ້າໃນລະຫັດ, ເຊິ່ງໄດ້ຖືກຄົ້ນພົບຢູ່ໃນສ່ວນອື່ນຂອງ Qemu.

ການທໍາລາຍ heap

ດັ່ງນັ້ນ, ການເຂົ້າເຖິງທີ່ບໍ່ສອດຄ່ອງຂອງ TCI ໄດ້ຖືກແກ້ໄຂ, loop ຕົ້ນຕໍໄດ້ຖືກສ້າງຂື້ນເຊິ່ງເອີ້ນວ່າໂປເຊດເຊີ, RCU ແລະບາງສິ່ງເລັກນ້ອຍອື່ນໆ. ແລະດັ່ງນັ້ນຂ້າພະເຈົ້າເປີດຕົວ Qemu ດ້ວຍທາງເລືອກ -d exec,in_asm,out_asm, ຊຶ່ງຫມາຍຄວາມວ່າທ່ານຈໍາເປັນຕ້ອງເວົ້າວ່າລະຫັດໃດທີ່ຖືກປະຕິບັດ, ແລະໃນເວລາອອກອາກາດເພື່ອຂຽນວ່າລະຫັດແຂກແມ່ນຫຍັງ, ລະຫັດເຈົ້າພາບໄດ້ກາຍເປັນ (ໃນກໍລະນີນີ້, bytecode). ມັນ​ເລີ່ມ​ຕົ້ນ​, ປະ​ຕິ​ບັດ​ຕັນ​ການ​ແປ​ພາ​ສາ​ຈໍາ​ນວນ​ຫນຶ່ງ​, ຂຽນ​ຂໍ້​ຄວາມ​ແກ້​ໄຂ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ປະ​ໄວ້​ວ່າ RCU ຈະ​ເລີ່ມ​ຕົ້ນ​ໃນ​ປັດ​ຈຸ​ບັນ​ແລະ ... crashes​. abort() ພາຍໃນຫນ້າທີ່ free(). ໂດຍ tinkering ກັບຫນ້າທີ່ free() ພວກເຮົາໄດ້ຈັດການຄົ້ນພົບວ່າຢູ່ໃນຫົວຂອງ heap block, ເຊິ່ງຢູ່ໃນແປດ bytes ກ່ອນຫນ່ວຍຄວາມຈໍາທີ່ຖືກຈັດສັນ, ແທນທີ່ຈະເປັນຂະຫນາດຂອງ block ຫຼືບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນ, ມີຂີ້ເຫຍື້ອ.

ການທໍາລາຍຂອງ heap - ເຮັດແນວໃດງາມ ... ໃນກໍລະນີດັ່ງກ່າວ, ມີວິທີແກ້ໄຂທີ່ເປັນປະໂຫຍດ - ຈາກ (ຖ້າເປັນໄປໄດ້) ແຫຼ່ງດຽວກັນ, ປະກອບເປັນຖານສອງພື້ນຖານແລະດໍາເນີນການພາຍໃຕ້ Valgrind. ຫຼັງຈາກເວລາໃດຫນຶ່ງ, binary ແມ່ນກຽມພ້ອມ. ຂ້າ​ພະ​ເຈົ້າ​ເປີດ​ມັນ​ມີ​ທາງ​ເລືອກ​ດຽວ​ກັນ - ມັນ crashes ເຖິງ​ແມ່ນ​ວ່າ​ໃນ​ລະ​ຫວ່າງ​ການ​ເລີ່ມ​ຕົ້ນ​, ກ່ອນ​ທີ່​ຈະ​ປະ​ຕິ​ບັດ​ຕົວ​ຈິງ​. ມັນບໍ່ຫນ້າພໍໃຈ, ແນ່ນອນ - ປາກົດຂື້ນ, ແຫຼ່ງຂໍ້ມູນບໍ່ຄືກັນ, ເຊິ່ງບໍ່ແປກໃຈ, ເພາະວ່າ configure scouted ອອກທາງເລືອກທີ່ແຕກຕ່າງກັນເລັກນ້ອຍ, ແຕ່ຂ້ອຍມີ Valgrind - ທໍາອິດຂ້ອຍຈະແກ້ໄຂ bug ນີ້, ແລະຫຼັງຈາກນັ້ນ, ຖ້າຂ້ອຍໂຊກດີ. , ຕົ້ນສະບັບຈະປາກົດ. ຂ້ອຍກໍາລັງແລ່ນສິ່ງດຽວກັນພາຍໃຕ້ Valgrind ... Y-y-y, y-y-y, uh-uh, ມັນໄດ້ເລີ່ມຕົ້ນ, ໂດຍຜ່ານການເລີ່ມຕົ້ນໂດຍປົກກະຕິແລະຍ້າຍອອກໄປໃນອະດີດ bug ຕົ້ນສະບັບໂດຍບໍ່ມີການເຕືອນດຽວກ່ຽວກັບການເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາທີ່ບໍ່ຖືກຕ້ອງ, ບໍ່ໄດ້ກ່າວເຖິງການຕົກ. ຊີວິດ, ຍ້ອນວ່າເຂົາເຈົ້າເວົ້າວ່າ, ບໍ່ໄດ້ກະກຽມຂ້າພະເຈົ້າສໍາລັບການນີ້ - ໂຄງການ crashing ຢຸດ crashing ໃນເວລາທີ່ເປີດຕົວພາຍໃຕ້ Walgrind. ສິ່ງທີ່ມັນເປັນຄວາມລຶກລັບ. ສົມມຸດຕິຖານຂອງຂ້ອຍແມ່ນວ່າຫນຶ່ງຄັ້ງຢູ່ໃກ້ກັບຄໍາແນະນໍາໃນປະຈຸບັນຫຼັງຈາກອຸປະຕິເຫດໃນລະຫວ່າງການເລີ່ມຕົ້ນ, gdb ສະແດງໃຫ້ເຫັນການເຮັດວຽກ. memset-a ກັບຕົວຊີ້ທີ່ຖືກຕ້ອງໂດຍໃຊ້ທັງສອງ mmx, ຫຼື xmm ລົງທະບຽນ, ຫຼັງຈາກນັ້ນບາງທີມັນເປັນບາງປະເພດຂອງຄວາມຜິດພາດການຈັດຕໍາແຫນ່ງ, ເຖິງແມ່ນວ່າມັນຍັງຍາກທີ່ຈະເຊື່ອ.

ຕົກລົງ, Valgrind ເບິ່ງຄືວ່າບໍ່ໄດ້ຊ່ວຍຢູ່ທີ່ນີ້. ແລະໃນທີ່ນີ້ສິ່ງທີ່ຫນ້າລັງກຽດທີ່ສຸດໄດ້ເລີ່ມຕົ້ນ - ທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າຈະເລີ່ມຕົ້ນ, ແຕ່ crashes ສໍາລັບເຫດຜົນທີ່ບໍ່ຮູ້ຈັກຢ່າງແທ້ຈິງເນື່ອງຈາກເຫດການທີ່ອາດຈະເກີດຂຶ້ນຫຼາຍລ້ານຄໍາແນະນໍາກ່ອນຫນ້ານີ້. ສໍາລັບເວລາດົນນານ, ມັນຍັງບໍ່ຊັດເຈນວ່າວິທີການເຂົ້າຫາ. ໃນ​ທີ່​ສຸດ, ຂ້າ​ພະ​ເຈົ້າ​ຍັງ​ໄດ້​ນັ່ງ​ລົງ​ແລະ debug. ການພິມສິ່ງທີ່ຫົວຖືກຂຽນຄືນໃຫມ່ສະແດງໃຫ້ເຫັນວ່າມັນບໍ່ມີລັກສະນະເປັນຕົວເລກ, ແຕ່ບາງປະເພດຂອງຂໍ້ມູນຖານສອງ. ແລະ, ເບິ່ງແລະເບິ່ງ, ສະຕຣິງຄູ່ນີ້ໄດ້ຖືກພົບເຫັນຢູ່ໃນໄຟລ໌ BIOS - ນັ້ນແມ່ນ, ຕອນນີ້ມັນເປັນໄປໄດ້ທີ່ຈະເວົ້າດ້ວຍຄວາມຫມັ້ນໃຈທີ່ສົມເຫດສົມຜົນວ່າມັນເປັນ buffer overflow, ແລະມັນຊັດເຈນວ່າມັນຖືກຂຽນໃສ່ buffer ນີ້. ແລ້ວ, ບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້ - ໃນ Emscripten, ໂຊກດີ, ບໍ່ມີການສຸ່ມພື້ນທີ່ທີ່ຢູ່, ບໍ່ມີຮູຢູ່ໃນນັ້ນ, ດັ່ງນັ້ນທ່ານສາມາດຂຽນບາງບ່ອນຢູ່ກາງລະຫັດເພື່ອສົ່ງຂໍ້ມູນໂດຍຕົວຊີ້ຈາກການເປີດຕົວຄັ້ງສຸດທ້າຍ, ເບິ່ງຂໍ້ມູນ, ເບິ່ງຕົວຊີ້, ແລະ, ຖ້າມັນບໍ່ປ່ຽນແປງ, ເອົາອາຫານສໍາລັບຄວາມຄິດ. ແທ້ຈິງແລ້ວ, ມັນໃຊ້ເວລາສອງສາມນາທີເພື່ອເຊື່ອມຕໍ່ຫຼັງຈາກການປ່ຽນແປງໃດໆ, ແຕ່ວ່າເຈົ້າສາມາດເຮັດຫຍັງໄດ້? ດັ່ງນັ້ນ, ເສັ້ນສະເພາະໄດ້ຖືກພົບເຫັນວ່າຄັດລອກ BIOS ຈາກ buffer ຊົ່ວຄາວໄປຫາຄວາມຊົງຈໍາຂອງແຂກ - ແລະ, ແທ້ຈິງແລ້ວ, ບໍ່ມີພື້ນທີ່ພຽງພໍໃນ buffer. ການຊອກຫາທີ່ມາຂອງທີ່ຢູ່ buffer ທີ່ແປກປະຫຼາດນັ້ນສົ່ງຜົນໃຫ້ມີຫນ້າທີ່ qemu_anon_ram_alloc ໃນໄຟລ oslib-posix.c - ເຫດຜົນມີນີ້: ບາງຄັ້ງມັນສາມາດເປັນປະໂຫຍດທີ່ຈະຈັດຕໍາແຫນ່ງທີ່ຢູ່ໄປຫາຫນ້າຂະຫນາດໃຫຍ່ຂອງຂະຫນາດ 2 MB, ສໍາລັບນີ້ພວກເຮົາຈະຖາມ. mmap ກ່ອນ​ອື່ນ​ອີກ​ພຽງ​ເລັກ​ນ້ອຍ​, ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ພວກ​ເຮົາ​ຈະ​ສົ່ງ​ຄືນ​ສ່ວນ​ເກີນ​ດ້ວຍ​ການ​ຊ່ວຍ​ເຫຼືອ​ munmap. ແລະຖ້າການຈັດຕໍາແຫນ່ງດັ່ງກ່າວບໍ່ຈໍາເປັນ, ຫຼັງຈາກນັ້ນພວກເຮົາຈະຊີ້ບອກຜົນໄດ້ຮັບແທນທີ່ຈະເປັນ 2 MB getpagesize() - mmap ມັນຍັງຈະໃຫ້ທີ່ຢູ່ສອດຄ່ອງ ... ດັ່ງນັ້ນໃນ Emscripten mmap ພຽງແຕ່ໂທຫາ malloc, ແຕ່ແນ່ນອນວ່າມັນບໍ່ສອດຄ່ອງຢູ່ໃນຫນ້າ. ໂດຍທົ່ວໄປ, ແມງໄມ້ທີ່ເຮັດໃຫ້ຂ້ອຍອຸກອັ່ງສໍາລັບສອງສາມເດືອນໄດ້ຖືກແກ້ໄຂໂດຍການປ່ຽນແປງໃນ ຢ່າງໃດອຍ່າງຫນຶ່ງ ສາຍ.

ຄຸນນະສົມບັດຂອງຫນ້າທີ່ໂທຫາ

ແລະໃນປັດຈຸບັນໂຮງງານຜະລິດກໍາລັງນັບບາງສິ່ງບາງຢ່າງ, Qemu ບໍ່ crash, ແຕ່ຫນ້າຈໍບໍ່ເປີດ, ແລະໂຮງງານຜະລິດຢ່າງວ່ອງໄວເຂົ້າໄປໃນ loops, ຕັດສິນໂດຍຜົນຜະລິດ. -d exec,in_asm,out_asm. ສົມມຸດຕິຖານໄດ້ເກີດຂື້ນ: ການຂັດຂວາງການຈັບເວລາ (ຫຼື, ໂດຍທົ່ວໄປ, ການຂັດຂວາງທັງຫມົດ) ບໍ່ມາຮອດ. ແລະແທ້ຈິງແລ້ວ, ຖ້າທ່ານ unscrew ການຂັດຂວາງຈາກສະພາແຫ່ງພື້ນເມືອງ, ເຊິ່ງສໍາລັບເຫດຜົນບາງຢ່າງເຮັດວຽກ, ທ່ານໄດ້ຮັບຮູບພາບທີ່ຄ້າຍຄືກັນ. ແຕ່ນີ້ບໍ່ແມ່ນຄໍາຕອບເລີຍ: ການປຽບທຽບຮ່ອງຮອຍທີ່ອອກມາດ້ວຍຕົວເລືອກຂ້າງເທິງນັ້ນສະແດງໃຫ້ເຫັນວ່າ ເສັ້ນທາງການປະຕິບັດໄດ້ແຕກຕ່າງກັນຫຼາຍໄວ. ໃນທີ່ນີ້ມັນຕ້ອງເວົ້າວ່າການປຽບທຽບສິ່ງທີ່ຖືກບັນທຶກໄວ້ໂດຍໃຊ້ launcher emrun debugging output ກັບຜົນຜະລິດຂອງສະພາແຫ່ງ native ບໍ່ແມ່ນຂະບວນການກົນຈັກຢ່າງສົມບູນ. ຂ້ອຍບໍ່ຮູ້ວ່າໂຄງການທີ່ເຮັດວຽກຢູ່ໃນ browser ເຊື່ອມຕໍ່ແນວໃດ emrun, ແຕ່ບາງສາຍໃນຜົນຜະລິດໄດ້ຫັນອອກໄດ້ຮັບການຈັດລຽງໃຫມ່, ດັ່ງນັ້ນຄວາມແຕກຕ່າງຂອງຄວາມແຕກຕ່າງແມ່ນຍັງບໍ່ທັນເປັນເຫດຜົນທີ່ຈະສົມມຸດວ່າ trajectories ໄດ້ diverged. ໂດຍທົ່ວໄປ, ມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າອີງຕາມຄໍາແນະນໍາ ljmpl ມີການຫັນປ່ຽນໄປຫາທີ່ຢູ່ທີ່ແຕກຕ່າງກັນ, ແລະ bytecode ທີ່ສ້າງຂຶ້ນແມ່ນແຕກຕ່າງກັນໂດຍພື້ນຖານ: ອັນຫນຶ່ງມີຄໍາແນະນໍາທີ່ຈະໂທຫາຫນ້າທີ່ຜູ້ຊ່ວຍ, ອີກອັນຫນຶ່ງບໍ່ມີ. ຫຼັງຈາກ googling ຄໍາແນະນໍາແລະສຶກສາລະຫັດທີ່ແປຄໍາແນະນໍາເຫຼົ່ານີ້, ມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າ, ທໍາອິດ, ທັນທີກ່ອນທີ່ຈະລົງທະບຽນ. cr0 ການບັນທຶກໄດ້ຖືກເຮັດ - ຍັງໃຊ້ຕົວຊ່ວຍ - ເຊິ່ງປ່ຽນໂປເຊດເຊີໄປສູ່ໂຫມດປ້ອງກັນ, ແລະອັນທີສອງ, ຮຸ່ນ js ບໍ່ເຄີຍປ່ຽນເປັນໂຫມດປ້ອງກັນ. ແຕ່ຄວາມຈິງແມ່ນວ່າລັກສະນະອື່ນຂອງ Emscripten ແມ່ນການລັງເລທີ່ຈະທົນທານຕໍ່ລະຫັດເຊັ່ນການປະຕິບັດຄໍາແນະນໍາ. call ໃນ TCI, ເຊິ່ງຕົວຊີ້ຟັງຊັນໃດກໍ່ໄດ້ສົ່ງຜົນໃຫ້ປະເພດ long long f(int arg0, .. int arg9) - ຟັງຊັນຕ້ອງຖືກເອີ້ນດ້ວຍຈໍານວນການໂຕ້ຖຽງທີ່ຖືກຕ້ອງ. ຖ້າກົດລະບຽບນີ້ຖືກລະເມີດ, ຂຶ້ນກັບການຕັ້ງຄ່າການດີບັກ, ໂປລແກລມຈະຂັດຂ້ອງ (ເຊິ່ງເປັນສິ່ງທີ່ດີ) ຫຼືໂທຫາຫນ້າທີ່ຜິດພາດທັງຫມົດ (ເຊິ່ງຫນ້າເສົ້າໃຈທີ່ຈະດີບັກ). ຍັງມີທາງເລືອກທີສາມ - ເປີດໃຊ້ການຜະລິດ wrappers ທີ່ເພີ່ມ / ລົບການໂຕ້ຖຽງ, ແຕ່ລວມເອົາ wrappers ເຫຼົ່ານີ້ໃຊ້ເວລາຫຼາຍພື້ນທີ່, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າໃນຄວາມເປັນຈິງຂ້າພະເຈົ້າພຽງແຕ່ຕ້ອງການພຽງເລັກນ້ອຍຫຼາຍກ່ວາຮ້ອຍ wrappers. ນີ້ຢ່າງດຽວແມ່ນໂສກເສົ້າຫຼາຍ, ແຕ່ໄດ້ຫັນອອກເປັນບັນຫາທີ່ຮ້າຍແຮງກວ່າເກົ່າ: ໃນລະຫັດທີ່ສ້າງຂຶ້ນຂອງຫນ້າທີ່ wrapper, ການໂຕ້ຖຽງໄດ້ຖືກປ່ຽນແລະແປງ, ແຕ່ບາງຄັ້ງຫນ້າທີ່ທີ່ມີການໂຕ້ຖຽງທີ່ສ້າງຂຶ້ນບໍ່ໄດ້ຖືກເອີ້ນວ່າ - ດີ, ຄືກັນກັບໃນ. ການປະຕິບັດ libffi ຂອງຂ້ອຍ. ນັ້ນແມ່ນ, ຜູ້ຊ່ວຍບາງຄົນບໍ່ໄດ້ຖືກປະຕິບັດ.

ໂຊກດີ, Qemu ມີລາຍຊື່ຕົວຊ່ວຍທີ່ສາມາດອ່ານໄດ້ໃນຮູບແບບຂອງໄຟລ໌ header ເຊັ່ນ:

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

ພວກມັນຖືກໃຊ້ເປັນເລື່ອງຕະຫຼົກຫຼາຍ: ທຳອິດ, ມະຫາພາກແມ່ນຖືກກຳນົດຄືນໃໝ່ໃນແບບທີ່ແປກປະຫຼາດທີ່ສຸດ DEF_HELPER_n, ແລະຫຼັງຈາກນັ້ນເປີດ helper.h. ໃນຂອບເຂດທີ່ມະຫາພາກໄດ້ຖືກຂະຫຍາຍໄປສູ່ໂຄງສ້າງເບື້ອງຕົ້ນແລະເຄື່ອງໝາຍຈຸດ, ແລະຫຼັງຈາກນັ້ນ array ຖືກກໍານົດ, ແລະແທນທີ່ຈະເປັນອົງປະກອບ - #include <helper.h> ດັ່ງນັ້ນ, ໃນທີ່ສຸດຂ້ອຍໄດ້ມີໂອກາດທົດລອງຫ້ອງສະຫມຸດຢູ່ບ່ອນເຮັດວຽກ pyparsing, ແລະ script ໄດ້ຖືກຂຽນທີ່ສ້າງ wrappers ເຫຼົ່ານັ້ນຢ່າງແທ້ຈິງສໍາລັບຫນ້າທີ່ທີ່ເຂົາເຈົ້າຕ້ອງການ.

ແລະດັ່ງນັ້ນ, ຫຼັງຈາກນັ້ນ, ໂຮງງານຜະລິດເບິ່ງຄືວ່າຈະເຮັດວຽກ. ມັນເບິ່ງຄືວ່າເປັນຍ້ອນວ່າຫນ້າຈໍບໍ່ເຄີຍໄດ້ຮັບການເລີ່ມຕົ້ນ, ເຖິງແມ່ນວ່າ memtest86+ ສາມາດດໍາເນີນການຢູ່ໃນການປະກອບພື້ນເມືອງ. ໃນທີ່ນີ້ມັນຈໍາເປັນຕ້ອງຊີ້ແຈງວ່າລະຫັດ Qemu block I/O ຖືກຂຽນໄວ້ໃນ coroutines. Emscripten ມີການປະຕິບັດທີ່ຫຍຸ້ງຍາກຫຼາຍຂອງຕົນເອງ, ແຕ່ມັນຍັງຈໍາເປັນຕ້ອງໄດ້ຮັບການສະຫນັບສະຫນູນໃນລະຫັດ Qemu, ແລະທ່ານສາມາດແກ້ໄຂໂປເຊດເຊີໄດ້ໃນປັດຈຸບັນ: Qemu ສະຫນັບສະຫນູນທາງເລືອກ. -kernel, -initrd, -append, ທີ່ທ່ານສາມາດ boot Linux ຫຼື, ສໍາລັບການຍົກຕົວຢ່າງ, memtest86+, ໂດຍບໍ່ມີການນໍາໃຊ້ອຸປະກອນ block ທັງຫມົດ. ແຕ່ນີ້ແມ່ນບັນຫາ: ໃນການປະກອບພື້ນເມືອງຫນຶ່ງສາມາດເຫັນຜົນໄດ້ຮັບຂອງ Linux kernel ກັບ console ທີ່ມີທາງເລືອກ. -nographic, ແລະບໍ່ມີຜົນຜະລິດຈາກຕົວທ່ອງເວັບໄປຫາ terminal ຈາກບ່ອນທີ່ມັນຖືກເປີດຕົວ emrun, ບໍ່ໄດ້ມາ. ນັ້ນແມ່ນ, ມັນບໍ່ຊັດເຈນ: ໂປເຊດເຊີບໍ່ເຮັດວຽກຫຼືຜົນຜະລິດກາຟິກບໍ່ເຮັດວຽກ. ແລະຫຼັງຈາກນັ້ນມັນເກີດຂຶ້ນກັບຂ້ອຍທີ່ຈະລໍຖ້າເລັກນ້ອຍ. ມັນໄດ້ຫັນອອກວ່າ "ໂຮງງານຜະລິດບໍ່ໄດ້ນອນ, ແຕ່ພຽງແຕ່ກະພິບຊ້າໆ," ແລະຫຼັງຈາກປະມານຫ້ານາທີ, kernel ຖິ້ມຊໍ່ຂອງຂໍ້ຄວາມໃສ່ console ແລະສືບຕໍ່ hang. ມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າໂຮງງານຜະລິດ, ໂດຍທົ່ວໄປ, ເຮັດວຽກ, ແລະພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຂຸດເຂົ້າໄປໃນລະຫັດສໍາລັບການເຮັດວຽກກັບ SDL2. ແຕ່ຫນ້າເສຍດາຍ, ຂ້ອຍບໍ່ຮູ້ວິທີການໃຊ້ຫ້ອງສະຫມຸດນີ້, ດັ່ງນັ້ນໃນບາງບ່ອນຂ້ອຍຕ້ອງປະຕິບັດແບບສຸ່ມ. ໃນບາງຈຸດ, ເສັ້ນຂະໜານ 0 ໄດ້ກະພິບໃນຫນ້າຈໍໃນພື້ນຫລັງສີຟ້າ, ເຊິ່ງຊີ້ໃຫ້ເຫັນຄວາມຄິດບາງຢ່າງ. ໃນທີ່ສຸດ, ມັນໄດ້ຫັນອອກວ່າບັນຫາແມ່ນວ່າ Qemu ເປີດປ່ອງຢ້ຽມ virtual ຫຼາຍຢູ່ໃນປ່ອງຢ້ຽມທາງດ້ານຮ່າງກາຍ, ລະຫວ່າງທີ່ທ່ານສາມາດປ່ຽນໂດຍໃຊ້ Ctrl-Alt-n: ມັນເຮັດວຽກຢູ່ໃນການກໍ່ສ້າງພື້ນເມືອງ, ແຕ່ບໍ່ແມ່ນຢູ່ໃນ Emscripten. ຫຼັງຈາກໄດ້ຮັບການກໍາຈັດປ່ອງຢ້ຽມທີ່ບໍ່ຈໍາເປັນໂດຍໃຊ້ທາງເລືອກ -monitor none -parallel none -serial none ແລະຄໍາແນະນໍາເພື່ອບັງຄັບໃຫ້ແຕ້ມຄືນຫນ້າຈໍທັງຫມົດໃນແຕ່ລະກອບ, ທຸກສິ່ງທຸກຢ່າງໄດ້ເຮັດວຽກຢ່າງກະທັນຫັນ.

ລະບຽບ

ດັ່ງນັ້ນ, ການຈໍາລອງໃນຕົວທ່ອງເວັບເຮັດວຽກ, ແຕ່ທ່ານບໍ່ສາມາດດໍາເນີນການໃດໆທີ່ຫນ້າສົນໃຈໃນ floppy ດຽວ, ເພາະວ່າບໍ່ມີ I / O ຕັນ - ທ່ານຈໍາເປັນຕ້ອງປະຕິບັດການສະຫນັບສະຫນູນ coroutines. Qemu ມີ backends coroutine ຫຼາຍແລ້ວ, ແຕ່ເນື່ອງຈາກລັກສະນະຂອງ JavaScript ແລະເຄື່ອງສ້າງລະຫັດ Emscripten, ທ່ານບໍ່ສາມາດເລີ່ມຕົ້ນພຽງແຕ່ juggling stacks. ມັນເບິ່ງຄືວ່າ "ທຸກສິ່ງທຸກຢ່າງໄດ້ຫາຍໄປ, plaster ໄດ້ຖືກໂຍກຍ້າຍ," ແຕ່ນັກພັດທະນາ Emscripten ໄດ້ດູແລທຸກສິ່ງທຸກຢ່າງແລ້ວ. ນີ້ແມ່ນການປະຕິບັດທີ່ຂ້ອນຂ້າງຕະຫລົກ: ໃຫ້ໂທຫາການໂທຫາຫນ້າທີ່ຫນ້າສົງໄສນີ້ emscripten_sleep ແລະອີກຫຼາຍໆກໍລະນີໂດຍໃຊ້ກົນໄກ Asyncify, ເຊັ່ນດຽວກັນກັບການໂທຫາຕົວຊີ້ແລະການໂທໄປຫາຫນ້າທີ່ໃດຫນຶ່ງທີ່ຫນຶ່ງໃນສອງກໍລະນີທີ່ຜ່ານມາອາດຈະເກີດຂຶ້ນຕື່ມອີກໃນ stack. ແລະໃນປັດຈຸບັນ, ກ່ອນທີ່ຈະໂທຫາທີ່ຫນ້າສົງໄສແຕ່ລະຄົນ, ພວກເຮົາຈະເລືອກສະພາບການ async, ແລະທັນທີຫຼັງຈາກການໂທ, ພວກເຮົາຈະກວດເບິ່ງວ່າການໂທ asynchronous ເກີດຂຶ້ນຫຼືບໍ່, ແລະຖ້າມັນມີ, ພວກເຮົາຈະບັນທຶກຕົວແປທ້ອງຖິ່ນທັງຫມົດໃນສະພາບການ async ນີ້, ຊີ້ບອກເຖິງຫນ້າທີ່ໃດ. ເພື່ອໂອນການຄວບຄຸມໄປຫາເວລາທີ່ພວກເຮົາຕ້ອງການສືບຕໍ່ປະຕິບັດ , ແລະອອກຈາກຫນ້າທີ່ປະຈຸບັນ. ນີ້ແມ່ນບ່ອນທີ່ມີຂອບເຂດສໍາລັບການສຶກສາຜົນກະທົບ ການຂູດຮີດ - ສໍາລັບຄວາມຕ້ອງການຂອງການປະຕິບັດລະຫັດຢ່າງຕໍ່ເນື່ອງຫຼັງຈາກກັບຄືນມາຈາກການໂທ asynchronous, compiler ຈະສ້າງ "stubs" ຂອງຟັງຊັນທີ່ເລີ່ມຕົ້ນຫຼັງຈາກການໂທທີ່ຫນ້າສົງໄສ - ແບບນີ້: ຖ້າມີການໂທທີ່ຫນ້າສົງໄສ, ຫຼັງຈາກນັ້ນຟັງຊັນຈະຖືກຂະຫຍາຍຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ n / 2. ເວລາ — ນີ້ແມ່ນຍັງ, ຖ້າບໍ່ຈື່ໄວ້ວ່າຫຼັງຈາກແຕ່ລະການໂທທີ່ອາດຈະ asynchronous, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມການປະຫຍັດຕົວແປທ້ອງຖິ່ນບາງຢ່າງໃຫ້ກັບຫນ້າທີ່ຕົ້ນສະບັບ. ຕໍ່ມາ, ຂ້ອຍຍັງຕ້ອງຂຽນ script ງ່າຍໆໃນ Python, ເຊິ່ງອີງໃສ່ຊຸດຂອງຫນ້າທີ່ໃຊ້ເກີນໂດຍສະເພາະທີ່ສົມມຸດວ່າ "ບໍ່ອະນຸຍາດໃຫ້ asynchrony ຜ່ານຕົວເອງ" (ນັ້ນແມ່ນ, ການສົ່ງເສີມ stack ແລະທຸກສິ່ງທຸກຢ່າງທີ່ຂ້ອຍພຽງແຕ່ອະທິບາຍບໍ່ໄດ້. ເຮັດວຽກຢູ່ໃນພວກມັນ), ຊີ້ບອກການໂທຜ່ານຕົວຊີ້ໃນຫນ້າທີ່ຄວນຈະຖືກລະເລີຍໂດຍ compiler ເພື່ອບໍ່ໃຫ້ຟັງຊັນເຫຼົ່ານີ້ບໍ່ຖືກຖືວ່າເປັນ asynchronous. ແລະຫຼັງຈາກນັ້ນໄຟລ໌ JS ພາຍໃຕ້ 60 MB ແມ່ນຫຼາຍຢ່າງຊັດເຈນ - ໃຫ້ເວົ້າວ່າຢ່າງຫນ້ອຍ 30. ເຖິງແມ່ນວ່າ, ເມື່ອຂ້ອຍໄດ້ຕັ້ງສະຄິບປະກອບ, ແລະໂດຍບັງເອີນຖິ້ມຕົວເລືອກຕົວເຊື່ອມຕໍ່, ໃນນັ້ນມີ. -O3. ຂ້ອຍແລ່ນລະຫັດທີ່ສ້າງຂຶ້ນ, ແລະ Chromium ກິນເຖິງຄວາມຊົງຈໍາ ແລະຂັດຂ້ອງ. ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເບິ່ງໂດຍບັງເອີນວ່າລາວກໍາລັງພະຍາຍາມດາວໂຫລດ ... ດີ, ຂ້ອຍສາມາດເວົ້າຫຍັງໄດ້, ຂ້ອຍຈະແຊ່ແຂງເກີນໄປຖ້າຂ້ອຍຖືກຂໍໃຫ້ສຶກສາຢ່າງລະມັດລະວັງແລະເພີ່ມປະສິດທິພາບ 500+ MB Javascript.

ແຕ່ຫນ້າເສຍດາຍ, ການກວດສອບໃນລະຫັດຫ້ອງສະຫມຸດສະຫນັບສະຫນູນ Asyncify ບໍ່ເປັນມິດກັບທັງຫມົດ longjmp-s ທີ່ຖືກນໍາໃຊ້ໃນລະຫັດໂປເຊດເຊີ virtual, ແຕ່ຫຼັງຈາກ patch ຂະຫນາດນ້ອຍທີ່ປິດການກວດສອບເຫຼົ່ານີ້ແລະບັງຄັບໃຫ້ຟື້ນຟູສະພາບການຄືກັບວ່າທຸກສິ່ງທຸກຢ່າງດີ, ລະຫັດເຮັດວຽກ. ແລະຫຼັງຈາກນັ້ນສິ່ງທີ່ແປກປະຫລາດໄດ້ເລີ່ມຕົ້ນ: ບາງຄັ້ງການກວດສອບໃນລະຫັດ synchronization ໄດ້ຖືກກະຕຸ້ນ - ອັນດຽວກັນທີ່ເຮັດໃຫ້ເກີດຄວາມຜິດພາດຂອງລະຫັດຖ້າ, ອີງຕາມເຫດຜົນຂອງການປະຕິບັດ, ມັນຄວນຈະຖືກສະກັດ - ມີຄົນພະຍາຍາມຈັບ mutex ທີ່ຖືກຈັບແລ້ວ. ໂຊກດີ, ນີ້ບໍ່ແມ່ນບັນຫາທີ່ມີເຫດຜົນໃນລະຫັດ serialized - ຂ້ອຍພຽງແຕ່ໃຊ້ການທໍາງານຂອງ loop ຫຼັກມາດຕະຖານທີ່ສະຫນອງໃຫ້ໂດຍ Emscripten, ແຕ່ບາງຄັ້ງການໂທ asynchronous ຈະ unwrap stack ຫມົດ, ແລະໃນເວລານີ້ມັນຈະລົ້ມເຫລວ. setTimeout ຈາກ loop ຕົ້ນຕໍ - ດັ່ງນັ້ນ, ລະຫັດເຂົ້າໄປໃນ iteration loop ຕົ້ນຕໍໂດຍບໍ່ມີການອອກຈາກ iteration ທີ່ຜ່ານມາ. Rewrote ໃນ loop infinite ແລະ emscripten_sleep, ແລະບັນຫາທີ່ມີ mutexes ຢຸດເຊົາ. ລະຫັດໄດ້ກາຍເປັນເຫດຜົນຫຼາຍ - ຫຼັງຈາກທີ່ທັງຫມົດ, ໃນຄວາມເປັນຈິງ, ຂ້ອຍບໍ່ມີລະຫັດບາງຢ່າງທີ່ກະກຽມກອບການເຄື່ອນໄຫວຕໍ່ໄປ - ໂປເຊດເຊີພຽງແຕ່ຄິດໄລ່ບາງສິ່ງບາງຢ່າງແລະຫນ້າຈໍໄດ້ຖືກປັບປຸງເປັນແຕ່ລະໄລຍະ. ຢ່າງໃດກໍຕາມ, ບັນຫາບໍ່ໄດ້ຢຸດຢູ່ທີ່ນັ້ນ: ບາງຄັ້ງການປະຕິບັດ Qemu ພຽງແຕ່ຢຸດເຊົາຢ່າງງຽບໆໂດຍບໍ່ມີຂໍ້ຍົກເວັ້ນຫຼືຄວາມຜິດພາດ. ໃນເວລານີ້ຂ້ອຍຍອມແພ້ມັນ, ແຕ່ເບິ່ງໄປຂ້າງຫນ້າ, ຂ້ອຍຈະເວົ້າວ່າບັນຫາແມ່ນນີ້: ລະຫັດ coroutine, ໃນຄວາມເປັນຈິງ, ບໍ່ໄດ້ໃຊ້. setTimeout (ຫຼືຢ່າງຫນ້ອຍບໍ່ແມ່ນເລື້ອຍໆຕາມທີ່ເຈົ້າຄິດ): function emscripten_yield ພຽງແຕ່ກໍານົດທຸງການໂທ asynchronous. ຈຸດທັງຫມົດແມ່ນວ່າ emscripten_coroutine_next ບໍ່​ແມ່ນ​ການ​ທໍາ​ງານ asynchronous​: ພາຍ​ໃນ​ມັນ​ກວດ​ສອບ​ທຸງ​ຊາດ​, reset ມັນ​ແລະ​ການ​ໂອນ​ການ​ຄວບ​ຄຸມ​ໄປ​ບ່ອນ​ທີ່​ມັນ​ຈໍາ​ເປັນ​. ນັ້ນແມ່ນ, ການສົ່ງເສີມການ stack ສິ້ນສຸດລົງຢູ່ທີ່ນັ້ນ. ບັນຫາແມ່ນວ່າເນື່ອງຈາກການນໍາໃຊ້ຫຼັງຈາກບໍ່ເສຍຄ່າ, ທີ່ປາກົດໃນເວລາທີ່ສະນຸກເກີ coroutine ໄດ້ຖືກປິດໃຊ້ງານເນື່ອງຈາກຄວາມຈິງທີ່ວ່າຂ້ອຍບໍ່ໄດ້ຄັດລອກລະຫັດທີ່ສໍາຄັນຈາກ backend coroutine ທີ່ມີຢູ່ແລ້ວ, ຫນ້າທີ່. qemu_in_coroutine ກັບຄືນຄວາມຈິງເມື່ອໃນຄວາມເປັນຈິງມັນຄວນຈະໄດ້ກັບຄືນ false. ນີ້ນໍາໄປສູ່ການໂທ emscripten_yield, ຂ້າງເທິງທີ່ບໍ່ມີໃຜຢູ່ໃນ stack ໄດ້ emscripten_coroutine_next, stack unfolded ໄປທາງເທີງຫຼາຍ, ແຕ່ບໍ່ມີ setTimeout, ດັ່ງທີ່ຂ້າພະເຈົ້າເວົ້າແລ້ວ, ບໍ່ໄດ້ຖືກວາງສະແດງ.

ການສ້າງລະຫັດ JavaScript

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

ຫນ້າທໍາອິດ, ເລັກນ້ອຍກ່ຽວກັບວິທີການ Qemu ເຮັດວຽກ. ກະລຸນາໃຫ້ອະໄພຂ້ອຍທັນທີ: ຂ້ອຍບໍ່ແມ່ນນັກພັດທະນາ Qemu ມືອາຊີບແລະບົດສະຫຼຸບຂອງຂ້ອຍອາດຈະຜິດພາດໃນບາງບ່ອນ. ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າ, "ຄວາມຄິດເຫັນຂອງນັກຮຽນບໍ່ຈໍາເປັນຕ້ອງກົງກັນກັບຄວາມຄິດເຫັນຂອງຄູ, Peano ແລະຄວາມຮູ້ສຶກທົ່ວໄປ." Qemu ມີຈໍານວນສະຖາປັດຕະຍະກໍາຂອງແຂກທີ່ສະຫນັບສະຫນູນແລະສໍາລັບແຕ່ລະຄົນມີລາຍຊື່ເຊັ່ນ target-i386. ໃນເວລາທີ່ການກໍ່ສ້າງ, ທ່ານສາມາດກໍານົດການສະຫນັບສະຫນູນສໍາລັບສະຖາປັດຕະຍະກໍາຂອງແຂກຫຼາຍ, ແຕ່ຜົນໄດ້ຮັບຈະເປັນສອງສອງເທົ່າ. ລະຫັດເພື່ອສະຫນັບສະຫນູນສະຖາປັດຕະຂອງແຂກ, ໃນທາງກັບກັນ, ສ້າງບາງການດໍາເນີນງານ Qemu ພາຍໃນ, ເຊິ່ງ TCG (ຕົວສ້າງລະຫັດຂະຫນາດນ້ອຍ) ແລ້ວປ່ຽນເປັນລະຫັດເຄື່ອງຈັກສໍາລັບສະຖາປັດຕະຍະກໍາເຈົ້າພາບ. ດັ່ງທີ່ໄດ້ກ່າວໄວ້ໃນໄຟລ໌ readme ທີ່ຕັ້ງຢູ່ໃນໄດເລກະທໍລີ tcg, ໃນເບື້ອງຕົ້ນນີ້ແມ່ນສ່ວນຫນຶ່ງຂອງ C compiler ປົກກະຕິ, ເຊິ່ງຕໍ່ມາໄດ້ຖືກດັດແປງສໍາລັບ JIT. ດັ່ງນັ້ນ, ສໍາລັບການຍົກຕົວຢ່າງ, ສະຖາປັດຕະຍະກໍາເປົ້າຫມາຍໃນຂໍ້ກໍານົດຂອງເອກະສານນີ້ແມ່ນບໍ່ເປັນສະຖາປັດຕະຂອງແຂກ, ແຕ່ເປັນສະຖາປັດຕະເຈົ້າພາບ. ໃນບາງຈຸດ, ອົງປະກອບອື່ນປາກົດ - ຕົວແປລະຫັດຂະຫນາດນ້ອຍ (TCI), ເຊິ່ງຄວນປະຕິບັດລະຫັດ (ເກືອບດຽວກັນກັບການດໍາເນີນງານພາຍໃນ) ໃນເມື່ອບໍ່ມີຕົວສ້າງລະຫັດສໍາລັບສະຖາປັດຕະຍະກໍາສະເພາະ. ໃນຄວາມເປັນຈິງ, ຕາມເອກະສານຂອງຕົນ, ນາຍພາສານີ້ອາດຈະບໍ່ປະຕິບັດເຊັ່ນດຽວກັນກັບເຄື່ອງສ້າງລະຫັດ JIT, ບໍ່ພຽງແຕ່ໃນປະລິມານຂອງຄວາມໄວ, ແຕ່ຍັງຄຸນນະພາບ. ເຖິງແມ່ນວ່າຂ້ອຍບໍ່ແນ່ໃຈວ່າຄໍາອະທິບາຍຂອງລາວມີຄວາມກ່ຽວຂ້ອງຢ່າງສົມບູນ.

ທໍາອິດຂ້ອຍພະຍາຍາມສ້າງ backend TCG ເຕັມຮູບແບບ, ແຕ່ສັບສົນຢ່າງໄວວາໃນລະຫັດແຫຼ່ງແລະຄໍາອະທິບາຍທີ່ບໍ່ຊັດເຈນທັງຫມົດຂອງຄໍາແນະນໍາ bytecode, ດັ່ງນັ້ນຂ້ອຍຈຶ່ງຕັດສິນໃຈຫໍ່ຕົວແປພາສາ TCI. ນີ້​ໃຫ້​ຂໍ້​ດີ​ຫຼາຍ​ຢ່າງ​:

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

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

ໃນເບື້ອງຕົ້ນ, ລະຫັດໄດ້ຖືກສ້າງຂື້ນໃນຮູບແບບຂອງສະຫຼັບຂະຫນາດໃຫຍ່ທີ່ຢູ່ຂອງຄໍາແນະນໍາ bytecode ຕົ້ນສະບັບ, ແຕ່ຫຼັງຈາກນັ້ນ, ຈື່ຈໍາບົດຄວາມກ່ຽວກັບ Emscripten, ການເພີ່ມປະສິດທິພາບຂອງ JS ທີ່ຖືກສ້າງຂື້ນແລະ relooping, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈສ້າງລະຫັດຂອງມະນຸດຫຼາຍຂຶ້ນ, ໂດຍສະເພາະນັບຕັ້ງແຕ່ມັນເຫັນໄດ້ຊັດເຈນ. ໄດ້​ຫັນ​ອອກ​ວ່າ​ຈຸດ​ດຽວ​ທີ່​ເຂົ້າ​ໄປ​ໃນ​ຕັນ​ການ​ແປ​ພາ​ສາ​ແມ່ນ​ການ​ເລີ່ມ​ຕົ້ນ​ຂອງ​ຕົນ​. ບໍ່ມີການເວົ້າໄວກວ່າການເຮັດ, ຫຼັງຈາກເວລາໃດຫນຶ່ງພວກເຮົາມີເຄື່ອງກໍາເນີດລະຫັດທີ່ສ້າງລະຫັດທີ່ມີ ifs (ເຖິງແມ່ນວ່າບໍ່ມີ loops). ແຕ່ໂຊກບໍ່ດີ, ມັນໄດ້ລົ້ມລົງ, ໃຫ້ຂໍ້ຄວາມວ່າຄໍາແນະນໍາມີຄວາມຍາວທີ່ບໍ່ຖືກຕ້ອງ. ຍິ່ງໄປກວ່ານັ້ນ, ຄໍາແນະນໍາສຸດທ້າຍໃນລະດັບ recursion ນີ້ແມ່ນ brcond. ຕົກລົງ, ຂ້ອຍຈະເພີ່ມການກວດສອບແບບດຽວກັນກັບການສ້າງຄໍາແນະນໍານີ້ກ່ອນແລະຫຼັງຈາກການໂທ recursive ແລະ ... ບໍ່ແມ່ນອັນໃດອັນຫນຶ່ງທີ່ຖືກປະຕິບັດ, ແຕ່ຫຼັງຈາກສະຫຼັບຢືນຢັນພວກເຂົາຍັງລົ້ມເຫລວ. ໃນທີ່ສຸດ, ຫຼັງຈາກການສຶກສາລະຫັດທີ່ສ້າງຂຶ້ນ, ຂ້ອຍຮູ້ວ່າຫຼັງຈາກສະຫຼັບ, ຕົວຊີ້ໄປຫາຄໍາແນະນໍາໃນປະຈຸບັນຈະຖືກໂຫຼດຄືນຈາກ stack ແລະອາດຈະຖືກຂຽນທັບດ້ວຍລະຫັດ JavaScript ທີ່ສ້າງຂຶ້ນ. ແລະດັ່ງນັ້ນມັນໄດ້ຫັນອອກ. ການເພີ່ມ buffer ຈາກຫນຶ່ງ megabyte ເປັນສິບບໍ່ໄດ້ນໍາໄປສູ່ການຫຍັງ, ແລະມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າເຄື່ອງສ້າງລະຫັດແມ່ນແລ່ນເປັນວົງ. ພວກເຮົາຕ້ອງກວດເບິ່ງວ່າພວກເຮົາບໍ່ໄດ້ໄປເກີນຂອບເຂດຂອງວັນນະໂລກໃນປະຈຸບັນ, ແລະຖ້າພວກເຮົາເຮັດ, ຫຼັງຈາກນັ້ນອອກທີ່ຢູ່ຂອງ TB ຕໍ່ໄປດ້ວຍເຄື່ອງຫມາຍລົບເພື່ອໃຫ້ພວກເຮົາສາມາດດໍາເນີນການຕໍ່ໄປ. ນອກຈາກນັ້ນ, ນີ້ຈະແກ້ໄຂບັນຫາ "ຫນ້າທີ່ທີ່ສ້າງຂຶ້ນຄວນຈະບໍ່ຖືກຕ້ອງຖ້າຊິ້ນສ່ວນຂອງ bytecode ນີ້ມີການປ່ຽນແປງ?" — ພຽງ​ແຕ່​ຫນ້າ​ທີ່​ທີ່​ສອດ​ຄ້ອງ​ກັນ​ກັບ block ການ​ແປ​ພາ​ສາ​ນີ້​ຈໍາ​ເປັນ​ຕ້ອງ​ບໍ່​ຖືກ​ຕ້ອງ​. ໂດຍວິທີທາງການ, ເຖິງແມ່ນວ່າຂ້ອຍໄດ້ແກ້ໄຂທຸກສິ່ງທີ່ຢູ່ໃນ Chromium (ນັບຕັ້ງແຕ່ຂ້ອຍໃຊ້ Firefox ແລະມັນງ່າຍຂຶ້ນສໍາລັບຂ້ອຍທີ່ຈະໃຊ້ຕົວທ່ອງເວັບແຍກຕ່າງຫາກສໍາລັບການທົດລອງ), Firefox ໄດ້ຊ່ວຍຂ້ອຍແກ້ໄຂຄວາມບໍ່ເຂົ້າກັນກັບມາດຕະຖານ asm.js, ຫຼັງຈາກນັ້ນລະຫັດເລີ່ມເຮັດວຽກໄວຂຶ້ນ. Chromium.

ຕົວຢ່າງຂອງລະຫັດທີ່ສ້າງຂຶ້ນ

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 ໃນຮູບແບບ blog: ສໍາລັບແຕ່ລະ "ລະດັບ" ທີ່ໄດ້ຜ່ານຢ່າງນ້ອຍ, ຄໍາເຫັນລາຍລະອຽດໃນພາສາລັດເຊຍໄດ້ຖືກເພີ່ມ. ແທ້ຈິງແລ້ວ, ບົດຂຽນນີ້ແມ່ນເປັນການເລົ່າຄືນຂອງບົດສະຫຼຸບຢ່າງຫຼວງຫຼາຍ git log.

ທ່ານສາມາດລອງມັນທັງຫມົດ ທີ່ນີ້ (ລະວັງການສັນຈອນ).

ສິ່ງທີ່ເຮັດວຽກຢູ່ແລ້ວ:

• x86 ໂປເຊດເຊີ virtual ແລ່ນ
• ມີຕົ້ນແບບການເຮັດວຽກຂອງເຄື່ອງສ້າງລະຫັດ JIT ຈາກລະຫັດເຄື່ອງຈັກໄປຫາ JavaScript
• ມີແມ່ແບບສໍາລັບການປະກອບສະຖາປັດຕະຍະກໍາແຂກ 32-bit ອື່ນໆ: ໃນປັດຈຸບັນທ່ານສາມາດຊົມເຊີຍ Linux ສໍາລັບສະຖາປັດຕະ MIPS freezing ໃນຕົວທ່ອງເວັບໃນຂັ້ນຕອນການໂຫຼດ.

ເຈົ້າສາມາດເຮັດຫຍັງໄດ້ອີກ

• ເລັ່ງການ emulation. ແມ້ແຕ່ຢູ່ໃນໂຫມດ JIT ມັນເບິ່ງຄືວ່າຈະເຮັດວຽກຊ້າກວ່າ Virtual x86 (ແຕ່ວ່າມີ Qemu ທັງຫມົດທີ່ມີຮາດແວແລະສະຖາປັດຕະຍະກໍາທີ່ຈໍາລອງຫຼາຍ)
• ເພື່ອເຮັດໃຫ້ການໂຕ້ຕອບແບບປົກກະຕິ - ເວົ້າກົງໄປກົງມາ, ຂ້ອຍບໍ່ແມ່ນຜູ້ພັດທະນາເວັບທີ່ດີ, ສະນັ້ນສໍາລັບຕອນນີ້ຂ້ອຍໄດ້ remade ມາດຕະຖານ Emscripten shell ທີ່ດີທີ່ສຸດທີ່ຂ້ອຍສາມາດເຮັດໄດ້.
• ພະຍາຍາມເປີດຟັງຊັນ Qemu ທີ່ຊັບຊ້ອນ - ເຄືອຂ່າຍ, ການເຄື່ອນຍ້າຍ VM, ແລະອື່ນໆ.
• UPS: ທ່ານຈະຈໍາເປັນຕ້ອງໄດ້ສົ່ງບົດລາຍງານການພັດທະນາແລະຂໍ້ບົກພ່ອງຂອງທ່ານໄປໃຫ້ Emscripten ເທິງນ້ໍາ, ດັ່ງທີ່ຜູ້ຂົນສົ່ງຂອງ Qemu ແລະໂຄງການອື່ນໆໄດ້ເຮັດ. ຂອບໃຈເຂົາເຈົ້າທີ່ສາມາດໃຊ້ການປະກອບສ່ວນຂອງເຂົາເຈົ້າໃຫ້ກັບ Emscripten ເປັນສ່ວນຫນຶ່ງຂອງວຽກງານຂອງຂ້ອຍ.

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