កាលពីប៉ុន្មានឆ្នាំមុន Fabrice Bellard សរសេរដោយ jslinux គឺជាកម្មវិធីត្រាប់តាមកុំព្យូទ័រដែលសរសេរក្នុង JavaScript ។ បន្ទាប់ពីនោះយ៉ាងហោចណាស់មានច្រើនទៀត និម្មិត x86. ប៉ុន្តែពួកគេទាំងអស់ តាមដែលខ្ញុំដឹង គឺជាអ្នកបកប្រែ ខណៈដែល Qemu ដែលបានសរសេរមុននេះច្រើនដោយ Fabrice Bellard ដូចគ្នា ហើយប្រហែលជាកម្មវិធីត្រាប់តាមទំនើបដែលគោរពដោយខ្លួនឯង ប្រើការចងក្រង JIT នៃកូដភ្ញៀវចូលទៅក្នុងកូដប្រព័ន្ធម៉ាស៊ីន។ វាហាក់ដូចជាខ្ញុំថាវាដល់ពេលដែលត្រូវអនុវត្តកិច្ចការផ្ទុយគ្នាដែលទាក់ទងនឹងកម្មវិធីរុករកដែលដោះស្រាយ៖ ការចងក្រង JIT នៃកូដម៉ាស៊ីនទៅក្នុង JavaScript ដែលវាហាក់ដូចជាសមហេតុផលបំផុតក្នុងការច្រក Qemu ។ វានឹងហាក់បីដូចជា ហេតុអ្វីបានជា Qemu មានកម្មវិធីត្រាប់តាមដែលងាយស្រួលជាង និងងាយស្រួលប្រើ - ឧទាហរណ៍ VirtualBox ដូចគ្នា - បានដំឡើង និងដំណើរការ។ ប៉ុន្តែ Qemu មានលក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍ជាច្រើន។

• ប្រភព​បើក​ចំហ
• សមត្ថភាពក្នុងការធ្វើការដោយគ្មានកម្មវិធីបញ្ជាខឺណែល។
• សមត្ថភាពក្នុងការធ្វើការនៅក្នុងរបៀបអ្នកបកប្រែ
• ការគាំទ្រសម្រាប់ស្ថាបត្យកម្មម្ចាស់ផ្ទះ និងភ្ញៀវមួយចំនួនធំ

ទាក់ទងនឹងចំណុចទី 3 ឥឡូវនេះខ្ញុំអាចពន្យល់បានថាតាមពិតនៅក្នុងរបៀប TCI វាមិនមែនជាការណែនាំរបស់ម៉ាស៊ីនភ្ញៀវដែលត្រូវបានបកស្រាយនោះទេប៉ុន្តែ bytecode ដែលទទួលបានពីពួកគេប៉ុន្តែនេះមិនផ្លាស់ប្តូរខ្លឹមសារទេ - ដើម្បីបង្កើតនិងដំណើរការ។ Qemu នៅលើស្ថាបត្យកម្មថ្មី ប្រសិនបើអ្នកមានសំណាង អ្នកចងក្រង C គឺគ្រប់គ្រាន់ហើយ ការសរសេរកូដបង្កើតកូដអាចត្រូវបានពន្យារពេល។

ហើយឥឡូវនេះ បន្ទាប់ពីរយៈពេលពីរឆ្នាំនៃការសម្រាកលំហែជាមួយកូដប្រភព Qemu ក្នុងពេលទំនេររបស់ខ្ញុំ គំរូការងារមួយបានលេចចេញមក ដែលអ្នកអាចដំណើរការបានហើយ ឧទាហរណ៍ Kolibri OS ។

Emscripten គឺជាអ្វី

សព្វថ្ងៃនេះ អ្នកចងក្រងជាច្រើនបានបង្ហាញខ្លួន ដែលលទ្ធផលចុងក្រោយគឺ JavaScript ។ មួយចំនួនដូចជា Type Script ដើមឡើយមានបំណងជាវិធីល្អបំផុតក្នុងការសរសេរសម្រាប់គេហទំព័រ។ ក្នុងពេលជាមួយគ្នានោះ Emscripten គឺជាវិធីមួយដើម្បីយកកូដ C ឬ C++ ដែលមានស្រាប់ ហើយចងក្រងវាទៅជាទម្រង់ browser ដែលអាចអានបាន។ បើក ទំព័រនេះ យើងបានប្រមូលច្រកជាច្រើននៃកម្មវិធីល្បីៗ៖ នៅទីនេះឧទាហរណ៍អ្នកអាចមើល PyPy - ដោយវិធីនេះពួកគេអះអាងថាមាន JIT រួចហើយ។ តាមការពិត មិនមែនគ្រប់កម្មវិធីទាំងអស់អាចត្រូវបានចងក្រងដោយសាមញ្ញ និងដំណើរការនៅក្នុងកម្មវិធីរុករកនោះទេ - មានលេខ លក្ខណៈទោះយ៉ាងណាក៏ដោយ ដែលអ្នកត្រូវធ្វើដូចដែលសិលាចារឹកនៅលើទំព័រដូចគ្នានិយាយថា “Emscripten អាចត្រូវបានប្រើដើម្បីចងក្រងស្ទើរតែគ្រប់ទាំងអស់។ ចល័ត កូដ C/C++ ទៅជា JavaScript"។ នោះគឺមានប្រតិបត្តិការមួយចំនួនដែលមិនត្រូវបានកំណត់តាមស្តង់ដារ ប៉ុន្តែជាធម្មតាដំណើរការលើ x86 - ឧទាហរណ៍ ការចូលប្រើអថេរដែលមិនតម្រឹម ដែលជាទូទៅត្រូវបានហាមឃាត់លើស្ថាបត្យកម្មមួយចំនួន។ , Qemu គឺជាកម្មវិធីឆ្លងវេទិកា ហើយខ្ញុំចង់ជឿ ហើយវាមិនមានឥរិយាបទដែលមិនបានកំណត់ច្រើនទេ - យកវាមកចងក្រង បន្ទាប់មកដាក់បញ្ចូលបន្តិចជាមួយ JIT - ហើយអ្នករួចរាល់ហើយ! ប៉ុន្តែនោះមិនមែនជា ករណី...

សាកល្បងដំបូង

និយាយជាទូទៅ ខ្ញុំមិនមែនជាមនុស្សដំបូងដែលបង្កើតគំនិតនៃការបញ្ជូន Qemu ទៅកាន់ JavaScript នោះទេ។ មានសំណួរមួយត្រូវបានសួរនៅលើវេទិកា ReactOS ប្រសិនបើវាអាចធ្វើទៅបានដោយប្រើ Emscripten ។ សូម្បីតែមុននេះ មានពាក្យចចាមអារ៉ាមថា Fabrice Bellard បានធ្វើរឿងនេះដោយផ្ទាល់ ប៉ុន្តែយើងកំពុងនិយាយអំពី jslinux ដែលតាមខ្ញុំដឹងគឺគ្រាន់តែជាការប៉ុនប៉ងដើម្បីសម្រេចបាននូវដំណើរការគ្រប់គ្រាន់នៅក្នុង JS ដោយដៃ ហើយត្រូវបានសរសេរពីទទេ។ ក្រោយមក និម្មិត x86 ត្រូវបានសរសេរ - ប្រភពដែលមិនមានភាពច្របូកច្របល់ត្រូវបានបង្ហោះសម្រាប់វា ហើយដូចដែលបានបញ្ជាក់ "ភាពប្រាកដនិយម" កាន់តែច្រើននៃការត្រាប់តាមធ្វើឱ្យវាអាចប្រើ SeaBIOS ជាកម្មវិធីបង្កប់។ លើសពីនេះទៀត យ៉ាងហោចណាស់មានការប៉ុនប៉ងមួយដើម្បីច្រក Qemu ដោយប្រើ Emscripten - ខ្ញុំបានព្យាយាមធ្វើវា គូរន្ធប៉ុន្តែការអភិវឌ្ឍន៍ តាមដែលខ្ញុំយល់ គឺត្រូវបានជាប់គាំង។

ដូច្នេះ វានឹងហាក់បីដូចជា នេះគឺជាប្រភព នេះគឺជា Emscripten - យកវា ហើយចងក្រង។ ប៉ុន្តែក៏មានបណ្ណាល័យដែល Qemu អាស្រ័យ និងបណ្ណាល័យដែលបណ្ណាល័យទាំងនោះអាស្រ័យ។ល។ ហើយមួយក្នុងចំណោមនោះគឺ លីបហ្វីដែល glib អាស្រ័យលើ។ មានពាក្យចចាមអារ៉ាមនៅលើអ៊ីនធឺណិតថាមានមួយនៅក្នុងការប្រមូលដ៏ធំនៃច្រកនៃបណ្ណាល័យសម្រាប់ Emscripten ប៉ុន្តែវាពិបាកក្នុងការជឿខ្លះ៖ ដំបូងវាមិនមានបំណងក្លាយជាអ្នកចងក្រងថ្មីទេ ទីពីរវាមានកម្រិតទាបពេក។ បណ្ណាល័យ​ដើម្បី​គ្រាន់​តែ​យក​ឡើង​ហើយ​ចងក្រង​ទៅ JS ។ ហើយវាមិនមែនគ្រាន់តែជាបញ្ហានៃការបញ្ចូលការជួបប្រជុំគ្នានោះទេ - ប្រហែលជាប្រសិនបើអ្នកបង្វិលវា សម្រាប់ការហៅទូរសព្ទមួយចំនួន អ្នកអាចបង្កើតអាគុយម៉ង់ចាំបាច់នៅលើជង់ ហើយហៅមុខងារដោយគ្មានពួកវា។ ប៉ុន្តែ Emscripten គឺជារឿងដ៏ពិបាកមួយ៖ ដើម្បីធ្វើឱ្យកូដដែលបានបង្កើតមើលទៅស៊ាំនឹងកម្មវិធីរុករកតាមអ៊ីនធឺណិត JS engine optimizer ល្បិចមួយចំនួនត្រូវបានប្រើប្រាស់។ ជាពិសេស អ្វី​ដែល​ហៅ​ថា​ការ​បង្វិល​ឡើងវិញ - ម៉ាស៊ីន​បង្កើត​កូដ​ដោយ​ប្រើ LLVM IR ដែល​ទទួល​បាន​ជាមួយ​នឹង​សេចក្តី​ណែនាំ​អំពី​ការ​ផ្លាស់​ប្តូរ​អរូបី​មួយ​ចំនួន​ព្យាយាម​បង្កើត​ឡើង​វិញ​នូវ ifs, loops ជាដើម។ ជាការប្រសើរណាស់, តើអាគុយម៉ង់ត្រូវបានបញ្ជូនទៅមុខងារយ៉ាងដូចម្តេច? តាមធម្មជាតិ ជាអាគុយម៉ង់ចំពោះមុខងារ JS នោះគឺប្រសិនបើអាចធ្វើទៅបាន មិនមែនតាមរយៈជង់ទេ។

នៅដើមដំបូងមានគំនិតមួយដើម្បីគ្រាន់តែសរសេរជំនួស libffi ជាមួយ JS ហើយដំណើរការតេស្តស្តង់ដារ ប៉ុន្តែនៅទីបញ្ចប់ខ្ញុំមានការភ័ន្តច្រឡំអំពីរបៀបបង្កើតឯកសារបឋមកថារបស់ខ្ញុំដើម្បីឱ្យពួកគេអាចធ្វើការជាមួយកូដដែលមានស្រាប់ តើខ្ញុំអាចធ្វើអ្វីបាន? ដូចដែលពួកគេនិយាយថា "តើកិច្ចការស្មុគស្មាញណាស់ "តើយើងល្ងង់ណាស់មែនទេ?" ខ្ញុំត្រូវភ្ជាប់ libffi ទៅកាន់ស្ថាបត្យកម្មមួយផ្សេងទៀត ដូច្នេះដើម្បីនិយាយ - ជាសំណាងល្អ Emscripten មានម៉ាក្រូទាំងពីរសម្រាប់ការជួបប្រជុំគ្នាក្នុងជួរ (នៅក្នុង Javascript បាទ - ល្អ ស្ថាបត្យកម្មអ្វីក៏ដោយ ដូច្នេះអ្នកដំឡើង) និងសមត្ថភាពក្នុងការដំណើរការកូដដែលបានបង្កើតភ្លាមៗ។ ជាទូទៅ បន្ទាប់ពីធ្វើការសាកល្បងជាមួយនឹងបំណែក libffi ដែលពឹងផ្អែកលើវេទិកាមួយរយៈមក ខ្ញុំទទួលបានកូដដែលអាចចងក្រងបានខ្លះ ហើយដំណើរការវានៅលើការសាកល្បងដំបូងដែលខ្ញុំបានឆ្លងកាត់។ ជាការភ្ញាក់ផ្អើលរបស់ខ្ញុំ ការធ្វើតេស្តបានជោគជ័យ។ ស្រឡាំងកាំងដោយភាពប៉ិនប្រសប់របស់ខ្ញុំ - មិនលេងសើចទេ វាដំណើរការតាំងពីការចាប់ផ្តើមដំបូង - ខ្ញុំនៅតែមិនជឿភ្នែករបស់ខ្ញុំ បានទៅមើលកូដលទ្ធផលម្តងទៀត ដើម្បីវាយតម្លៃកន្លែងដែលត្រូវជីកបន្ទាប់ទៀត។ នេះជាលើកទី២ដែលខ្ញុំធ្វើខុស - រឿងតែមួយគត់ដែលខ្ញុំធ្វើគឺ ffi_call - នេះបានរាយការណ៍ពីការហៅជោគជ័យ។ មិនមានការហៅខ្លួនឯងទេ។ ដូច្នេះខ្ញុំបានផ្ញើសំណើរទាញដំបូងរបស់ខ្ញុំ ដែលបានកែកំហុសក្នុងការធ្វើតេស្តដែលច្បាស់លាស់ចំពោះសិស្ស Olympiad ណាមួយ - ចំនួនពិតមិនគួរប្រៀបធៀបជា a == b និងសូម្បីតែរបៀប a - b < EPS - អ្នកក៏ត្រូវចងចាំម៉ូឌុលដែរ បើមិនដូច្នេះទេ 0 នឹងប្រែទៅជាខ្លាំងស្មើនឹង 1/3... ជាទូទៅ ខ្ញុំបានភ្ជាប់មកជាមួយនូវច្រកណាមួយនៃ libffi ដែលឆ្លងកាត់ការសាកល្បងដ៏សាមញ្ញបំផុត ហើយតើ glib មួយណា។ ចងក្រង - ខ្ញុំបានសម្រេចចិត្តថាវាចាំបាច់ ខ្ញុំនឹងបន្ថែមវានៅពេលក្រោយ។ សម្លឹងទៅមុខ ខ្ញុំនឹងនិយាយថា ដូចដែលវាបានប្រែក្លាយ អ្នកចងក្រងមិនបានបញ្ចូលមុខងារ libffi នៅក្នុងកូដចុងក្រោយទេ។

ប៉ុន្តែដូចដែលខ្ញុំបាននិយាយរួចមកហើយថា មានដែនកំណត់មួយចំនួន ហើយក្នុងចំណោមការប្រើប្រាស់ដោយមិនគិតថ្លៃនៃឥរិយាបទដែលមិនបានកំណត់ផ្សេងៗ លក្ខណៈពិសេសដែលមិនល្អជាងនេះទៀតសោតត្រូវបានលាក់ - JavaScript តាមការរចនាមិនគាំទ្រ multithreading ជាមួយអង្គចងចាំរួមទេ។ ជាគោលការណ៍ ជាធម្មតាវាអាចត្រូវបានគេហៅថាជាគំនិតដ៏ល្អ ប៉ុន្តែមិនមែនសម្រាប់ការបញ្ជូនកូដដែលស្ថាបត្យកម្មរបស់ពួកគេត្រូវបានចងភ្ជាប់ជាមួយខ្សែស្រឡាយ C នោះទេ។ និយាយជាទូទៅ Firefox កំពុងពិសោធជាមួយការគាំទ្រដល់កម្មករដែលបានចែករំលែក ហើយ Emscripten មានការអនុវត្ត pthread សម្រាប់ពួកគេ ប៉ុន្តែខ្ញុំមិនចង់ពឹងផ្អែកលើវាទេ។ ខ្ញុំត្រូវចាក់ឬសបន្តិចម្តងៗនូវ multithreading ពីកូដ Qemu - នោះគឺស្វែងរកកន្លែងដែលខ្សែស្រឡាយកំពុងដំណើរការ ផ្លាស់ទីតួនៃរង្វិលជុំដែលកំពុងដំណើរការក្នុងខ្សែស្រឡាយនេះទៅជាមុខងារដាច់ដោយឡែក ហើយហៅមុខងារបែបនេះម្តងមួយៗពីរង្វិលជុំមេ។

ការប៉ុនប៉ងលើកទីពីរ

នៅចំណុចខ្លះ វាច្បាស់ណាស់ថាបញ្ហានៅតែមាន ហើយការរុញឈើច្រត់ជុំវិញកូដដោយចៃដន្យនឹងមិននាំទៅរកផលល្អទេ។ សេចក្តីសន្និដ្ឋាន៖ យើងត្រូវរៀបចំប្រព័ន្ធដំណើរការបន្ថែមឈើច្រត់។ ដូច្នេះហើយ កំណែ 2.4.1 ដែលថ្មីនៅពេលនោះ ត្រូវបានគេយក (មិនមែន 2.5.0 ទេ ព្រោះអ្នកណាដឹង វានឹងមានកំហុសនៅក្នុងកំណែថ្មីដែលមិនទាន់ចាប់បាន ហើយខ្ញុំមានកំហុសផ្ទាល់ខ្លួនរបស់ខ្ញុំគ្រប់គ្រាន់។ ) ហើយរឿងដំបូងគឺត្រូវសរសេរវាឡើងវិញដោយសុវត្ថិភាព thread-posix.c. ជាការប្រសើរណាស់ ដែលមានសុវត្ថិភាព៖ ប្រសិនបើនរណាម្នាក់ព្យាយាមធ្វើប្រតិបត្តិការដែលនាំទៅដល់ការទប់ស្កាត់ មុខងារត្រូវបានហៅភ្លាមៗ abort() - ជាការពិតណាស់ នេះមិនបានដោះស្រាយបញ្ហាទាំងអស់ក្នុងពេលតែមួយនោះទេ ប៉ុន្តែយ៉ាងហោចណាស់ វាពិតជារីករាយជាងការទទួលទិន្នន័យមិនស៊ីសង្វាក់គ្នាដោយស្ងាត់ស្ងៀម។

ជាទូទៅ ជម្រើស Emscripten មានប្រយោជន៍ខ្លាំងណាស់ក្នុងការបញ្ជូនកូដទៅកាន់ JS -s ASSERTIONS=1 -s SAFE_HEAP=1 - ពួកគេចាប់បានប្រភេទមួយចំនួននៃឥរិយាបទដែលមិនបានកំណត់ ដូចជាការហៅទៅកាន់អាសយដ្ឋានដែលមិនតម្រឹម (ដែលមិនស៊ីគ្នាជាមួយនឹងកូដសម្រាប់អារេដែលបានវាយបញ្ចូលដូចជា HEAP32[addr >> 2] = 1) ឬហៅមុខងារដែលមានចំនួនអាគុយម៉ង់ខុស។

ដោយវិធីនេះ កំហុសក្នុងការតម្រឹមគឺជាបញ្ហាដាច់ដោយឡែក។ ដូចដែលខ្ញុំបាននិយាយរួចមកហើយថា Qemu មានផ្នែកខាងក្រោយនៃការបកស្រាយ "ខូច" សម្រាប់ការបង្កើតកូដ TCI (អ្នកបកប្រែកូដតូច) ហើយដើម្បីបង្កើត និងដំណើរការ Qemu លើស្ថាបត្យកម្មថ្មី ប្រសិនបើអ្នកមានសំណាង អ្នកចងក្រង C គឺគ្រប់គ្រាន់ហើយ។ ពាក្យគន្លឹះ "ប្រសិនបើអ្នកមានសំណាង". ខ្ញុំមានសំណាងមិនល្អ ហើយវាបានប្រែក្លាយថា TCI ប្រើការចូលដំណើរការដែលមិនតម្រឹមនៅពេលញែកកូដបៃរបស់វា។ នោះគឺនៅលើគ្រប់ប្រភេទនៃ ARM និងស្ថាបត្យកម្មផ្សេងទៀតជាមួយនឹងការចូលប្រើកម្រិតចាំបាច់ Qemu ចងក្រងដោយសារតែពួកគេមានកម្មវិធីខាងក្រោយ TCG ធម្មតាដែលបង្កើតកូដដើមប៉ុន្តែថាតើ TCI នឹងដំណើរការលើពួកវាគឺជាសំណួរមួយទៀត។ ទោះជាយ៉ាងណាក៏ដោយ ដូចដែលវាបានប្រែក្លាយ ឯកសារ TCI បានបង្ហាញយ៉ាងច្បាស់នូវអ្វីដែលស្រដៀងគ្នា។ ជាលទ្ធផល ការហៅមុខងារសម្រាប់ការអានមិនតម្រឹមត្រូវបានបន្ថែមទៅកូដ ដែលត្រូវបានរកឃើញនៅក្នុងផ្នែកផ្សេងទៀតនៃ Qemu ។

ការបំផ្លិចបំផ្លាញ

ជាលទ្ធផល ការចូលទៅកាន់ TCI ដែលមិនស្របគ្នាត្រូវបានកែតម្រូវ រង្វិលជុំសំខាន់មួយត្រូវបានបង្កើតឡើង ដែលនៅក្នុងវេនហៅថា processor, RCU និងរបស់តូចៗមួយចំនួនទៀត។ ដូច្នេះហើយ ខ្ញុំបើកដំណើរការ Qemu ជាមួយនឹងជម្រើស -d exec,in_asm,out_asmដែលមានន័យថាអ្នកត្រូវនិយាយថាប្លុកនៃកូដណាមួយកំពុងត្រូវបានប្រតិបត្តិ ហើយនៅពេលចាក់ផ្សាយផងដែរ ដើម្បីសរសេរកូដភ្ញៀវ អ្វីទៅជាកូដម៉ាស៊ីន (ក្នុងករណីនេះ bytecode)។ វាចាប់ផ្តើម ប្រតិបត្តិប្លុកបកប្រែជាច្រើន សរសេរសារបំបាត់កំហុសដែលខ្ញុំបានទុកថា RCU នឹងចាប់ផ្តើម ហើយ... គាំង abort() នៅខាងក្នុងមុខងារមួយ។ free(). ដោយ tinkering ជាមួយមុខងារ free() យើងបានគ្រប់គ្រងដើម្បីដឹងថានៅក្នុងបឋមកថានៃប្លុក heap ដែលស្ថិតនៅក្នុងប្រាំបីបៃមុនអង្គចងចាំដែលបានបែងចែកជំនួសឱ្យទំហំប្លុកឬអ្វីមួយដែលស្រដៀងគ្នាមានសំរាម។

ការបំផ្លិចបំផ្លាញនៃគំនរ - គួរឱ្យស្រលាញ់ ... ក្នុងករណីបែបនេះមានមធ្យោបាយដោះស្រាយដ៏មានប្រយោជន៍ - ពី (ប្រសិនបើអាចធ្វើទៅបាន) ប្រភពដូចគ្នាប្រមូលផ្តុំប្រព័ន្ធគោលពីរដើមហើយដំណើរការវានៅក្រោម Valgrind ។ បន្ទាប់ពីពេលខ្លះប្រព័ន្ធគោលពីរបានត្រៀមរួចរាល់។ ខ្ញុំបើកដំណើរការវាជាមួយនឹងជម្រើសដូចគ្នា - វាគាំងសូម្បីតែក្នុងអំឡុងពេលចាប់ផ្តើម មុនពេលឈានដល់ការប្រតិបត្តិ។ វាជាការមិនសប្បាយចិត្ត ជាការពិតណាស់ ប្រភពមិនដូចគ្នាទេ ដែលមិនមែនជារឿងគួរឱ្យភ្ញាក់ផ្អើលនោះទេ ព្រោះការកំណត់រចនាសម្ព័ន្ធបានជ្រើសរើសជម្រើសខុសគ្នាបន្តិចបន្តួច ប៉ុន្តែខ្ញុំមាន Valgrind - ដំបូងខ្ញុំនឹងជួសជុលកំហុសនេះ ហើយបន្ទាប់មក ប្រសិនបើខ្ញុំមានសំណាង ដើមនឹងលេចចេញមក។ ខ្ញុំកំពុងដំណើរការរឿងដដែលក្រោម Valgrind... Y-y-y, y-y-y, uh-uh, វាបានចាប់ផ្តើម, ឆ្លងកាត់ការចាប់ផ្តើមជាធម្មតា ហើយបានផ្លាស់ប្តូរនៅលើអតីតកាលនៃកំហុសដើមដោយគ្មានការព្រមានតែមួយអំពីការចូលប្រើអង្គចងចាំមិនត្រឹមត្រូវ មិននិយាយអំពីការធ្លាក់។ ជីវិត ដូចដែលពួកគេបាននិយាយថា មិនបានរៀបចំខ្ញុំសម្រាប់រឿងនេះទេ - កម្មវិធីគាំងឈប់គាំងនៅពេលបើកដំណើរការនៅក្រោម Walgrind ។ អ្វីដែលវាជាអាថ៌កំបាំង។ សម្មតិកម្មរបស់ខ្ញុំគឺថានៅពេលដែលនៅជិតការណែនាំបច្ចុប្បន្នបន្ទាប់ពីការគាំងកំឡុងពេលចាប់ផ្តើម gdb បានបង្ហាញការងារ memset-a ជាមួយនឹងទ្រនិចត្រឹមត្រូវដោយប្រើទាំង mmx, ឬ xmm ចុះឈ្មោះ បន្ទាប់មកប្រហែលជាវាជាប្រភេទនៃកំហុសក្នុងការតម្រឹម បើទោះបីជាវានៅតែពិបាកក្នុងការជឿក៏ដោយ។

មិនអីទេ Valgrind ហាក់ដូចជាមិនជួយនៅទីនេះទេ។ ហើយនៅទីនេះអ្វីដែលគួរឱ្យស្អប់ខ្ពើមបំផុតបានចាប់ផ្តើម - អ្វីគ្រប់យ៉ាងហាក់ដូចជាចាប់ផ្តើមប៉ុន្តែគាំងដោយមិនដឹងមូលហេតុពិតប្រាកដដោយសារតែព្រឹត្តិការណ៍ដែលអាចកើតឡើងរាប់លានការណែនាំមុន។ ជា​យូរ​មក​ហើយ​មិន​ច្បាស់​ថា​ត្រូវ​ចូល​ទៅ​ខាង​ណា​ទេ។ នៅទីបញ្ចប់ ខ្ញុំនៅតែត្រូវអង្គុយ ហើយបំបាត់កំហុស។ ការបោះពុម្ពអ្វីដែលបឋមកថាត្រូវបានសរសេរឡើងវិញដោយបង្ហាញថាវាមិនមើលទៅដូចជាលេខទេ ប៉ុន្តែជាប្រភេទនៃទិន្នន័យគោលពីរ។ ហើយមើលចុះ ហើយមើល ខ្សែអក្សរគោលពីរនេះត្រូវបានរកឃើញនៅក្នុងឯកសារ BIOS - នោះគឺឥឡូវនេះគេអាចនិយាយដោយទំនុកចិត្តសមហេតុផលថាវាជាការលើសសតិបណ្ដោះអាសន្ន ហើយវាច្បាស់ណាស់ថាវាត្រូវបានសរសេរទៅសតិបណ្ដោះអាសន្ននេះ។ ជាការប្រសើរណាស់, បន្ទាប់មកអ្វីមួយដូចនេះ - នៅក្នុង Emscripten ជាសំណាងល្អមិនមានចៃដន្យនៃទំហំអាសយដ្ឋានមិនមានរន្ធនៅក្នុងវាទេដូច្នេះអ្នកអាចសរសេរកន្លែងណាមួយនៅកណ្តាលនៃកូដដើម្បីបញ្ចេញទិន្នន័យដោយទ្រនិចពីការបើកដំណើរការចុងក្រោយ។ មើល​ទិន្នន័យ មើល​ទ្រនិច ហើយ​បើ​វា​មិន​បាន​ផ្លាស់​ប្តូរ យក​អាហារ​សម្រាប់​គិត។ ពិត វាចំណាយពេលពីរបីនាទីដើម្បីភ្ជាប់បន្ទាប់ពីការផ្លាស់ប្តូរណាមួយ ប៉ុន្តែតើអ្នកអាចធ្វើអ្វីបាន? ជាលទ្ធផល បន្ទាត់ជាក់លាក់មួយត្រូវបានរកឃើញដែលចម្លង BIOS ពីសតិបណ្ដោះអាសន្នទៅអង្គចងចាំភ្ញៀវ - ហើយជាការពិត វាមិនមានទំហំគ្រប់គ្រាន់នៅក្នុងសតិបណ្ដោះអាសន្នទេ។ ការស្វែងរកប្រភពនៃអាស័យដ្ឋានសតិបណ្ដោះអាសន្ននោះ បណ្តាលឱ្យមានមុខងារមួយ។ qemu_anon_ram_alloc នៅក្នុងឯកសារ oslib-posix.c - តក្កវិជ្ជានៅទីនោះ៖ ពេលខ្លះវាអាចមានប្រយោជន៍ក្នុងការតម្រឹមអាសយដ្ឋានទៅទំព័រដ៏ធំនៃទំហំ 2 MB សម្រាប់បញ្ហានេះយើងនឹងសួរ mmap ដំបូងបន្តិច ហើយបន្ទាប់មក យើងនឹងសងប្រាក់ដែលលើសដោយមានជំនួយ munmap. ហើយប្រសិនបើការតម្រឹមបែបនេះមិនត្រូវបានទាមទារ នោះយើងនឹងបង្ហាញលទ្ធផលជំនួសឱ្យ 2 MB getpagesize() - mmap វានៅតែផ្តល់ឱ្យចេញនូវអាសយដ្ឋានដែលបានតម្រឹម... ដូច្នេះនៅក្នុង Emscripten mmap គ្រាន់តែហៅ mallocប៉ុន្តែជាការពិតណាស់ វាមិនតម្រឹមនៅលើទំព័រនោះទេ។ ជាទូទៅ កំហុស​ដែល​ធ្វើ​ឱ្យ​ខ្ញុំ​ខក​ចិត្ត​ក្នុង​រយៈ​ពេល​ពីរ​ខែ​ត្រូវ​បាន​កែ​តម្រូវ​ដោយ​ការ​ផ្លាស់​ប្តូរ двух បន្ទាត់។

លក្ខណៈពិសេសនៃមុខងារហៅ

ហើយឥឡូវនេះខួរក្បាលកំពុងរាប់អ្វីមួយ Qemu មិនគាំងទេប៉ុន្តែអេក្រង់មិនបើកទេហើយខួរក្បាលដំណើរការយ៉ាងលឿនចូលទៅក្នុងរង្វិលជុំដោយវិនិច្ឆ័យដោយលទ្ធផល។ -d exec,in_asm,out_asm. សម្មតិកម្មមួយបានកើតឡើង៖ កម្មវិធីកំណត់ម៉ោងរំខាន (ឬជាទូទៅការរំខានទាំងអស់) មិនមកដល់ទេ។ ហើយជាការពិតណាស់ ប្រសិនបើអ្នកដកការរអាក់រអួលចេញពីសភាដើម ដែលសម្រាប់ហេតុផលមួយចំនួនបានដំណើរការ អ្នកនឹងទទួលបានរូបភាពស្រដៀងគ្នា។ ប៉ុន្តែនេះមិនមែនជាចម្លើយទាល់តែសោះ៖ ការប្រៀបធៀបនៃដានដែលបានចេញជាមួយជម្រើសខាងលើបានបង្ហាញថាគន្លងប្រតិបត្តិបានខុសគ្នាខ្លាំង។ នៅទីនេះវាត្រូវតែនិយាយថាការប្រៀបធៀបនៃអ្វីដែលត្រូវបានកត់ត្រាដោយប្រើកម្មវិធីបើកដំណើរការ emrun ការបំបាត់កំហុសជាមួយនឹងលទ្ធផលនៃការដំឡើងដើមមិនមែនជាដំណើរការមេកានិកទាំងស្រុងនោះទេ។ ខ្ញុំ​មិន​ដឹង​ច្បាស់​ពី​របៀប​ដែល​កម្មវិធី​ដែល​ដំណើរការ​ក្នុង​ browser ភ្ជាប់​ទៅ emrunប៉ុន្តែបន្ទាត់មួយចំនួននៅក្នុងទិន្នផលប្រែទៅជាត្រូវបានរៀបចំឡើងវិញ ដូច្នេះភាពខុសគ្នានៅក្នុង diff មិនទាន់ជាហេតុផលដើម្បីសន្មត់ថាគន្លងបានបង្វែរទេ។ ជាទូទៅវាច្បាស់ណាស់ថាយោងទៅតាមការណែនាំ ljmpl មានការផ្លាស់ប្តូរទៅអាសយដ្ឋានផ្សេងគ្នា ហើយ bytecode ដែលបានបង្កើតគឺខុសគ្នាជាមូលដ្ឋាន៖ មួយមានការណែនាំដើម្បីហៅមុខងារជំនួយ មួយទៀតមិនមាន។ បន្ទាប់ពីហ្គូហ្គលការណែនាំ និងសិក្សាកូដដែលបកប្រែការណែនាំទាំងនេះ វាច្បាស់ថាជាដំបូង ភ្លាមៗមុនពេលវានៅក្នុងការចុះឈ្មោះ cr0 ការថតសំឡេងត្រូវបានធ្វើឡើង - ដោយប្រើជំនួយការផងដែរ - ដែលបានប្តូរខួរក្បាលទៅជារបៀបការពារ ហើយទីពីរ កំណែ js មិនដែលប្តូរទៅរបៀបការពារទេ។ ប៉ុន្តែការពិតគឺថាលក្ខណៈពិសេសមួយទៀតរបស់ Emscripten គឺការស្ទាក់ស្ទើរក្នុងការអត់ឱនចំពោះកូដដូចជាការអនុវត្តការណែនាំ។ call នៅក្នុង TCI ដែលទ្រនិចមុខងារណាមួយជាលទ្ធផលនៅក្នុងប្រភេទ long long f(int arg0, .. int arg9) - មុខងារត្រូវតែត្រូវបានហៅជាមួយនឹងចំនួនអាគុយម៉ង់ត្រឹមត្រូវ។ ប្រសិនបើច្បាប់នេះត្រូវបានបំពាន អាស្រ័យលើការកំណត់ការបំបាត់កំហុស កម្មវិធីនឹងគាំង (ដែលល្អ) ឬហៅមុខងារខុសទាំងស្រុង (ដែលគួរឱ្យស្តាយក្នុងការបំបាត់កំហុស)។ វាក៏មានជម្រើសទីបីផងដែរ - បើកដំណើរការនៃការបង្កើតរុំដែលបន្ថែម / ដកចេញអាគុយម៉ង់ប៉ុន្តែសរុបមករុំទាំងនេះយកកន្លែងច្រើនទោះបីជាការពិតខ្ញុំត្រូវការតែជាងមួយរយរុំប៉ុណ្ណោះ។ នេះតែម្នាក់ឯងគឺសោកសៅខ្លាំងណាស់ ប៉ុន្តែវាបានក្លាយទៅជាបញ្ហាធ្ងន់ធ្ងរជាងនេះទៅទៀត៖ នៅក្នុងកូដដែលបានបង្កើតនៃមុខងាររុំ អាគុយម៉ង់ត្រូវបានបំប្លែង និងបំប្លែង ប៉ុន្តែពេលខ្លះមុខងារជាមួយអាគុយម៉ង់ដែលបានបង្កើតមិនត្រូវបានគេហៅថា - ល្អដូចនៅក្នុង ការអនុវត្ត libffi របស់ខ្ញុំ។ នោះគឺអ្នកជំនួយខ្លះមិនត្រូវបានគេសម្លាប់ទេ។

ជាសំណាងល្អ Qemu មានបញ្ជីជំនួយដែលម៉ាស៊ីនអាចអានបានក្នុងទម្រង់ជាឯកសារបឋមកថាដូចជា

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

ពួកវាត្រូវបានប្រើគួរឱ្យអស់សំណើចណាស់៖ ដំបូង ម៉ាក្រូត្រូវបានកំណត់ឡើងវិញតាមរបៀបដ៏ចម្លែកបំផុត។ DEF_HELPER_nហើយបន្ទាប់មកបើក helper.h. ចំពោះវិសាលភាពដែលម៉ាក្រូត្រូវបានពង្រីកទៅជាធាតុចាប់ផ្តើមរចនាសម្ព័ន្ធ និងសញ្ញាក្បៀស ហើយបន្ទាប់មកអារេត្រូវបានកំណត់ ហើយជំនួសឱ្យធាតុ - #include <helper.h> ជាលទ្ធផល ទីបំផុតខ្ញុំមានឱកាសសាកល្បងបណ្ណាល័យនៅកន្លែងធ្វើការ pyparsingហើយស្គ្រីបមួយត្រូវបានសរសេរដែលបង្កើតកញ្ចប់រុំទាំងនោះយ៉ាងពិតប្រាកដសម្រាប់មុខងារដែលពួកវាត្រូវការ។

ហើយដូច្នេះបន្ទាប់ពីនោះខួរក្បាលហាក់ដូចជាដំណើរការ។ វាហាក់ដូចជាដោយសារតែអេក្រង់មិនដែលត្រូវបានចាប់ផ្តើមទេ ទោះបីជា memtest86+ អាចដំណើរការនៅក្នុងសភាដើមក៏ដោយ។ នៅទីនេះវាចាំបាច់ដើម្បីបញ្ជាក់ឱ្យច្បាស់ថាកូដ I/O ប្លុក Qemu ត្រូវបានសរសេរនៅក្នុង coroutines ។ Emscripten មានការអនុវត្តដ៏លំបាករបស់វា ប៉ុន្តែវានៅតែត្រូវការដើម្បីត្រូវបានគាំទ្រនៅក្នុងកូដ Qemu ហើយអ្នកអាចបំបាត់កំហុសខួរក្បាលឥឡូវនេះ៖ Qemu គាំទ្រជម្រើស -kernel, -initrd, -appendដែលអ្នកអាចចាប់ផ្ដើមលីនុច ឬឧទាហរណ៍ memtest86+ ដោយមិនប្រើឧបករណ៍ទប់ស្កាត់ទាល់តែសោះ។ ប៉ុន្តែនេះគឺជាបញ្ហា៖ នៅក្នុងការជួបប្រជុំដើមគេអាចមើលឃើញលទ្ធផលខឺណែលលីនុចទៅកាន់កុងសូលជាមួយនឹងជម្រើស -nographicហើយគ្មានលទ្ធផលពីកម្មវិធីរុករកទៅស្ថានីយពីកន្លែងដែលវាត្រូវបានបើកដំណើរការទេ។ emrun, មិនបានមក។ នោះគឺវាមិនច្បាស់ទេ: ខួរក្បាលមិនដំណើរការឬលទ្ធផលក្រាហ្វិកមិនដំណើរការ។ ហើយបន្ទាប់មកវាបានកើតឡើងដើម្បីឱ្យខ្ញុំរង់ចាំបន្តិច។ វាប្រែថា "ខួរក្បាលមិនដេកទេ ប៉ុន្តែគ្រាន់តែព្រិចភ្នែកយឺតៗ" ហើយបន្ទាប់ពីប្រហែលប្រាំនាទី ខឺណែលបានបោះសារជាច្រើនទៅលើកុងសូល ហើយបន្តព្យួរ។ វាច្បាស់ណាស់ថា processor ជាទូទៅដំណើរការ ហើយយើងត្រូវស្វែងយល់ពីកូដសម្រាប់ធ្វើការជាមួយ SDL2។ ជាអកុសល ខ្ញុំមិនដឹងពីរបៀបប្រើបណ្ណាល័យនេះទេ ដូច្នេះនៅកន្លែងខ្លះខ្ញុំត្រូវធ្វើដោយចៃដន្យ។ នៅចំណុចខ្លះ បន្ទាត់ប៉ារ៉ាឡែល 0 បានភ្លឺនៅលើអេក្រង់នៅលើផ្ទៃខាងក្រោយពណ៌ខៀវ ដែលបង្ហាញពីគំនិតមួយចំនួន។ នៅទីបញ្ចប់ វាបានប្រែក្លាយថាបញ្ហាគឺថា Qemu បើកបង្អួចនិម្មិតជាច្រើននៅក្នុងបង្អួចរូបវន្តមួយ រវាងដែលអ្នកអាចប្តូរដោយប្រើ Ctrl-Alt-n: វាដំណើរការនៅក្នុងការបង្កើតដើម ប៉ុន្តែមិនមែននៅក្នុង Emscripten ទេ។ បន្ទាប់ពីកម្ចាត់បង្អួចដែលមិនចាំបាច់ដោយប្រើជម្រើស -monitor none -parallel none -serial none និងការណែនាំដើម្បីគូរអេក្រង់ទាំងមូលឡើងវិញដោយបង្ខំនៅលើស៊ុមនីមួយៗ អ្វីគ្រប់យ៉ាងស្រាប់តែដំណើរការ។

ទម្លាប់

ដូច្នេះ ការធ្វើត្រាប់តាមក្នុងកម្មវិធីរុករកតាមអ៊ីនធឺណិតដំណើរការ ប៉ុន្តែអ្នកមិនអាចដំណើរការអ្វីដែលគួរឱ្យចាប់អារម្មណ៍មួយផ្ទាំងនៅក្នុងវាបានទេ ព្រោះមិនមានប្លុក I/O ទេ អ្នកត្រូវអនុវត្តការគាំទ្រសម្រាប់ទម្លាប់។ Qemu មាន backend coroutine ជាច្រើនរួចហើយ ប៉ុន្តែដោយសារតែធម្មជាតិនៃ JavaScript និងកម្មវិធីបង្កើតកូដ Emscripten អ្នកមិនអាចគ្រាន់តែចាប់ផ្តើម juggling stacks បានទេ។ វាហាក់ដូចជាថា "អ្វីគ្រប់យ៉ាងបានរលត់ទៅ ម្នាងសិលាកំពុងត្រូវបានដកចេញ" ប៉ុន្តែអ្នកអភិវឌ្ឍន៍ Emscripten បានថែរក្សាអ្វីៗគ្រប់យ៉ាងរួចហើយ។ នេះ​ត្រូវ​បាន​អនុវត្ត​គួរ​ឱ្យ​អស់​សំណើច​ណាស់​: ចូរ​ហៅ​ការ​ហៅ​មុខងារ​ដូច​ជា​គួរ​ឱ្យ​សង្ស័យ​នេះ​ emscripten_sleep និងមួយចំនួនផ្សេងទៀតដោយប្រើយន្តការ Asyncify ក៏ដូចជាការហៅទូរសព្ទ និងការហៅទៅកាន់មុខងារណាមួយ ដែលករណីមួយក្នុងចំណោមករណីពីរមុនអាចកើតឡើងបន្ថែមទៀតនៅក្នុងជង់។ ហើយឥឡូវនេះ មុនពេលការហៅគួរឱ្យសង្ស័យនីមួយៗ យើងនឹងជ្រើសរើសបរិបទអសមកាល ហើយភ្លាមៗបន្ទាប់ពីការហៅទូរសព្ទ យើងនឹងពិនិត្យមើលថាតើការហៅអសមកាលបានកើតឡើងឬអត់ ហើយប្រសិនបើវាមាន យើងនឹងរក្សាទុកអថេរក្នុងស្រុកទាំងអស់នៅក្នុងបរិបទអសមកាលនេះ បង្ហាញថាមុខងារណាមួយ ដើម្បីផ្ទេរការគ្រប់គ្រងទៅពេលដែលយើងត្រូវបន្តការប្រតិបត្តិ ហើយចេញពីមុខងារបច្ចុប្បន្ន។ នេះគឺជាកន្លែងដែលមានវិសាលភាពសម្រាប់សិក្សាពីឥទ្ធិពល ការ​ខ្ជះខ្ជាយ - សម្រាប់តម្រូវការនៃការបន្តការប្រតិបត្តិកូដបន្ទាប់ពីត្រលប់ពីការហៅអសមកាល កម្មវិធីចងក្រងបង្កើត "stubs" នៃមុខងារដែលចាប់ផ្តើមបន្ទាប់ពីការហៅគួរឱ្យសង្ស័យ - ដូចនេះ៖ ប្រសិនបើមានការហៅទូរសព្ទដែលគួរឱ្យសង្ស័យ នោះមុខងារនឹងត្រូវបានពង្រីកនៅកន្លែងណាមួយ n/2 ដង — វានៅតែដដែល ប្រសិនបើមិនចាំថាបន្ទាប់ពីការហៅអសមកាលដែលមានសក្តានុពលនីមួយៗ អ្នកត្រូវបន្ថែមការរក្សាទុកអថេរក្នុងស្រុកមួយចំនួនទៅមុខងារដើម។ ក្រោយមកទៀត ខ្ញុំថែមទាំងត្រូវសរសេរស្គ្រីបសាមញ្ញមួយនៅក្នុង Python ដែលផ្អែកលើសំណុំនៃមុខងារពិសេសដែលប្រើហួសកម្រិត ដែលសន្មតថា "មិនអនុញ្ញាតឱ្យអសមកាលឆ្លងកាត់ខ្លួនគេ" (នោះគឺការផ្សព្វផ្សាយជង់ និងអ្វីៗទាំងអស់ដែលខ្ញុំទើបតែពណ៌នាមិនធ្វើ ធ្វើការនៅក្នុងពួកវា) បង្ហាញពីការហៅតាមរយៈទ្រនិចដែលមុខងារគួរតែត្រូវបានមិនអើពើដោយអ្នកចងក្រង ដូច្នេះមុខងារទាំងនេះមិនត្រូវបានចាត់ទុកថាអសមកាលទេ។ ហើយបន្ទាប់មកឯកសារ JS ក្រោម 60 មេកាបៃគឺច្បាស់ណាស់ - ឧបមាថាយ៉ាងហោចណាស់ 30 ។ ទោះបីជានៅពេលដែលខ្ញុំកំពុងរៀបចំស្គ្រីបជួបប្រជុំគ្នា ហើយបានបោះចោលជម្រើសតំណភ្ជាប់ដោយចៃដន្យ ដែលក្នុងនោះមាន -O3. ខ្ញុំដំណើរការកូដដែលបានបង្កើត ហើយ Chromium ស៊ីអង្គចងចាំ ហើយគាំង។ បន្ទាប់មកខ្ញុំបានក្រឡេកមើលអ្វីដែលគាត់កំពុងព្យាយាមទាញយកដោយចៃដន្យ... អញ្ចឹងតើខ្ញុំអាចនិយាយអ្វីបាន ខ្ញុំនឹងបង្កកផងដែរ ប្រសិនបើខ្ញុំត្រូវបានគេស្នើសុំឱ្យសិក្សាដោយគិតគូរ និងបង្កើនប្រសិទ្ធភាព Javascript 500+ MB។

ជាអកុសល ការត្រួតពិនិត្យនៅក្នុងកូដបណ្ណាល័យជំនួយ Asyncify មិនមានភាពរួសរាយរាក់ទាក់ទាំងស្រុងជាមួយទេ។ longjmp-s ដែលត្រូវបានប្រើនៅក្នុងកូដដំណើរការនិម្មិត ប៉ុន្តែបន្ទាប់ពីបំណះតូចមួយដែលបិទការត្រួតពិនិត្យទាំងនេះ និងបង្ខំឱ្យស្ដារបរិបទឡើងវិញដូចជាប្រសិនបើអ្វីៗទាំងអស់ល្អ កូដដំណើរការ។ ហើយបន្ទាប់មករឿងចម្លែកមួយបានចាប់ផ្តើម៖ ពេលខ្លះការឆែកឆេរក្នុងកូដធ្វើសមកាលកម្មត្រូវបានបង្កឡើង - ដូចគ្នាដែលគាំងកូដ ប្រសិនបើយោងទៅតាមតក្កវិជ្ជាប្រតិបត្តិវាគួរតែត្រូវបានរារាំង - នរណាម្នាក់បានព្យាយាមចាប់យក mutex ដែលបានចាប់យករួចហើយ។ ជាសំណាងល្អ វាមិនមែនជាបញ្ហាឡូជីខលនៅក្នុងកូដសៀរៀលទេ - ខ្ញុំគ្រាន់តែប្រើមុខងាររង្វិលជុំចម្បងស្តង់ដារដែលផ្តល់ដោយ Emscripten ប៉ុន្តែពេលខ្លះការហៅអសមកាលនឹងស្រាយជង់ទាំងស្រុង ហើយនៅពេលនោះវានឹងបរាជ័យ។ setTimeout ពីរង្វិលជុំមេ - ដូច្នេះ កូដបានបញ្ចូលរង្វិលជុំមេដោយមិនបន្សល់ទុកការធ្វើឡើងវិញពីមុន។ សរសេរឡើងវិញនៅលើរង្វិលជុំគ្មានកំណត់និង emscripten_sleepហើយបញ្ហាជាមួយ mutexes បានឈប់។ កូដកាន់តែមានភាពឡូជីខល - តាមពិតទៅ ខ្ញុំមិនមានកូដមួយចំនួនដែលរៀបចំស៊ុមចលនាបន្ទាប់ទេ - ខួរក្បាលគ្រាន់តែគណនាអ្វីមួយ ហើយអេក្រង់ត្រូវបានធ្វើបច្ចុប្បន្នភាពតាមកាលកំណត់។ ទោះជាយ៉ាងណាក៏ដោយបញ្ហាមិនបានបញ្ឈប់នៅទីនោះទេ: ជួនកាលការប្រតិបត្តិ Qemu នឹងបញ្ចប់ដោយស្ងៀមស្ងាត់ដោយគ្មានករណីលើកលែងឬកំហុស។ នៅពេលនោះ ខ្ញុំបានបោះបង់វាចោល ប៉ុន្តែសម្លឹងទៅមុខ ខ្ញុំនឹងនិយាយថាបញ្ហាគឺនេះ៖ តាមពិតលេខកូដ coroutine មិនប្រើទេ។ setTimeout (ឬយ៉ាងហោចណាស់មិនញឹកញាប់ដូចដែលអ្នកគិត): មុខងារ emscripten_yield គ្រាន់តែកំណត់ទង់ហៅអសមកាល។ ចំណុចទាំងមូលគឺថា emscripten_coroutine_next មិនមែនជាមុខងារអសមកាលទេ៖ នៅខាងក្នុងវាពិនិត្យទង់ កំណត់វាឡើងវិញ និងផ្ទេរការគ្រប់គ្រងទៅកន្លែងដែលវាត្រូវការ។ នោះគឺការផ្សព្វផ្សាយជង់បញ្ចប់នៅទីនោះ។ បញ្ហាគឺថាដោយសារតែការប្រើប្រាស់បន្ទាប់ពីមិនគិតថ្លៃ ដែលបានលេចឡើងនៅពេលដែល coroutine pool ត្រូវបានបិទដោយសារតែការពិតដែលថាខ្ញុំមិនបានចម្លងបន្ទាត់សំខាន់នៃកូដពី backend coroutine ដែលមានស្រាប់ មុខងារ qemu_in_coroutine ត្រឡប់ពិត នៅពេលដែលការពិត វាគួរតែត្រលប់មកវិញមិនពិត។ នេះបាននាំឱ្យមានការហៅទូរស័ព្ទ emscripten_yieldខាងលើដែលមិនមាននរណាម្នាក់នៅលើជង់ emscripten_coroutine_nextជង់លាតទៅកំពូល ប៉ុន្តែទេ។ setTimeoutដូចដែលខ្ញុំបាននិយាយរួចហើយ គឺមិនត្រូវបានបង្ហាញទេ។

ការបង្កើតកូដ JavaScript

ហើយតាមពិតនៅទីនេះ គឺជាការសន្យាថា "បង្វែរសាច់ minced មកវិញ"។ មិន​ប្រាកដ​ទេ។ ជាការពិតណាស់ ប្រសិនបើយើងដំណើរការ Qemu នៅក្នុងកម្មវិធីរុករក និង Node.js នៅក្នុងវា នោះតាមធម្មជាតិ បន្ទាប់ពីការបង្កើតកូដនៅក្នុង Qemu យើងនឹងទទួលបាន JavaScript ខុសទាំងស្រុង។ ប៉ុន្តែនៅតែជាប្រភេទនៃការផ្លាស់ប្តូរបញ្ច្រាសមួយចំនួន។

ដំបូងបន្តិចអំពីរបៀបដែល Qemu ធ្វើការ។ សូមអភ័យទោសឱ្យខ្ញុំភ្លាមៗ៖ ខ្ញុំមិនមែនជាអ្នកអភិវឌ្ឍន៍ Qemu ដែលមានជំនាញវិជ្ជាជីវៈទេ ហើយការសន្និដ្ឋានរបស់ខ្ញុំអាចនឹងខុសនៅកន្លែងខ្លះ។ ដូចដែលពួកគេនិយាយថា "គំនិតរបស់សិស្សមិនត្រូវស្របនឹងគំនិតរបស់គ្រូទេ axiomatics និងសុភវិនិច្ឆ័យរបស់ Peano" ។ Qemu មានចំនួនជាក់លាក់នៃស្ថាបត្យកម្មភ្ញៀវដែលគាំទ្រ ហើយសម្រាប់នីមួយៗមានថតដូច target-i386. នៅពេលសាងសង់ អ្នកអាចបញ្ជាក់ការគាំទ្រសម្រាប់ស្ថាបត្យកម្មភ្ញៀវជាច្រើន ប៉ុន្តែលទ្ធផលនឹងគ្រាន់តែជាប្រព័ន្ធគោលពីរប៉ុណ្ណោះ។ កូដដើម្បីគាំទ្រស្ថាបត្យកម្មភ្ញៀវ បង្កើតប្រតិបត្តិការខាងក្នុងមួយចំនួនរបស់ Qemu ដែល TCG (Tiny Code Generator) ប្រែទៅជាកូដម៉ាស៊ីនសម្រាប់ស្ថាបត្យកម្មម៉ាស៊ីនរួចហើយ។ ដូចដែលបានបញ្ជាក់នៅក្នុងឯកសារ readme ដែលមានទីតាំងនៅក្នុងថត tcg ដើមឡើយនេះគឺជាផ្នែកនៃកម្មវិធីចងក្រង C ធម្មតា ដែលក្រោយមកត្រូវបានកែសម្រួលសម្រាប់ JIT ។ ដូច្នេះ ជាឧទាហរណ៍ ស្ថាបត្យកម្មគោលដៅនៅក្នុងលក្ខខណ្ឌនៃឯកសារនេះមិនមែនជាស្ថាបត្យកម្មភ្ញៀវទៀតទេ ប៉ុន្តែជាស្ថាបត្យកម្មម៉ាស៊ីន។ នៅចំណុចខ្លះ សមាសភាគមួយផ្សេងទៀតបានបង្ហាញខ្លួន - អ្នកបកប្រែកូដតូច (TCI) ដែលគួរតែប្រតិបត្តិកូដ (ស្ទើរតែប្រតិបត្តិការខាងក្នុងដូចគ្នា) ក្នុងករណីដែលគ្មានម៉ាស៊ីនបង្កើតកូដសម្រាប់ស្ថាបត្យកម្មម៉ាស៊ីនជាក់លាក់មួយ។ តាមការពិត ដូចដែលឯកសាររបស់វាចែង អ្នកបកប្រែនេះប្រហែលជាមិនតែងតែដំណើរការក៏ដូចជាម៉ាស៊ីនបង្កើតកូដ JIT មិនត្រឹមតែបរិមាណក្នុងន័យល្បឿនប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានគុណភាពផងដែរ។ ទោះបីជាខ្ញុំមិនប្រាកដថាការពិពណ៌នារបស់គាត់ពាក់ព័ន្ធទាំងស្រុងក៏ដោយ។

ដំបូងឡើយ ខ្ញុំបានព្យាយាមបង្កើតកម្មវិធីខាងក្រោយ TCG ពេញលេញ ប៉ុន្តែមានការភាន់ច្រឡំយ៉ាងឆាប់រហ័សនៅក្នុងកូដប្រភព និងការពិពណ៌នាមិនច្បាស់លាស់ទាំងស្រុងនៃការណែនាំអំពី bytecode ដូច្នេះខ្ញុំសម្រេចចិត្តរុំអ្នកបកប្រែ TCI ។ នេះបានផ្តល់អត្ថប្រយោជន៍ជាច្រើន៖

• នៅពេលអនុវត្តកម្មវិធីបង្កើតកូដ អ្នកមិនអាចមើលការពិពណ៌នានៃការណែនាំនោះទេ ប៉ុន្តែនៅលេខកូដអ្នកបកប្រែ
• អ្នក​អាច​បង្កើត​មុខងារ​មិន​មែន​សម្រាប់​រាល់​ប្លុក​ការ​បកប្រែ​ដែល​បាន​ជួប​នោះ​ទេ ប៉ុន្តែ​ជា​ឧទាហរណ៍​បន្ទាប់​ពី​ការ​ប្រតិបត្តិ​មួយ​រយ​ប៉ុណ្ណោះ។
• ប្រសិនបើលេខកូដដែលបានបង្កើតផ្លាស់ប្តូរ (ហើយនេះហាក់ដូចជាអាចធ្វើទៅបានដោយវិនិច្ឆ័យដោយមុខងារដែលមានឈ្មោះដែលមានបំណះពាក្យ) ខ្ញុំនឹងត្រូវធ្វើឱ្យកូដ JS ដែលបានបង្កើតមិនត្រឹមត្រូវ ប៉ុន្តែយ៉ាងហោចណាស់ខ្ញុំនឹងមានអ្វីដែលត្រូវបង្កើតវាឡើងវិញពី

ទាក់ទងនឹងចំណុចទីបី ខ្ញុំមិនប្រាកដថា patching អាចធ្វើទៅបានទេ បន្ទាប់ពីកូដត្រូវបានប្រតិបត្តិជាលើកដំបូង ប៉ុន្តែពីរចំណុចដំបូងគឺគ្រប់គ្រាន់ហើយ។

ដំបូង កូដត្រូវបានបង្កើតក្នុងទម្រង់ជាកុងតាក់ធំមួយនៅអាសយដ្ឋាននៃការណែនាំកូដបៃដើម ប៉ុន្តែបន្ទាប់មកដោយចងចាំអត្ថបទអំពី Emscripten ការបង្កើនប្រសិទ្ធភាពនៃ JS ដែលបានបង្កើត និងដំណើរការឡើងវិញ ខ្ញុំបានសម្រេចចិត្តបង្កើតកូដមនុស្សបន្ថែមទៀត ជាពិសេសចាប់តាំងពីវាមានលក្ខណៈជាក់ស្តែង។ បានប្រែក្លាយថាចំណុចចូលតែមួយគត់នៅក្នុងប្លុកបកប្រែគឺការចាប់ផ្តើមរបស់វា។ មិនយូរមិនឆាប់និយាយជាងធ្វើទេ បន្ទាប់ពីមួយរយៈយើងមានម៉ាស៊ីនបង្កើតកូដដែលបង្កើតកូដជាមួយ ifs (ទោះបីជាគ្មានរង្វិលជុំក៏ដោយ) ។ ប៉ុន្តែ​សំណាង​អាក្រក់ វា​បាន​គាំង ដោយ​ផ្តល់​សារ​ថា​ការណែនាំ​មាន​ប្រវែង​ខុស​ខ្លះ។ លើស​ពី​នេះ​ទៅ​ទៀត ការ​ណែនាំ​ចុង​ក្រោយ​នៅ​កម្រិត​បង្កើត​ឡើង​វិញ​គឺ​ brcond. មិនអីទេ ខ្ញុំនឹងបន្ថែមការត្រួតពិនិត្យដូចគ្នាទៅនឹងជំនាន់នៃការណែនាំនេះមុន និងក្រោយការហៅឡើងវិញ ហើយ... មិនមែនមួយក្នុងចំណោមពួកគេត្រូវបានប្រតិបត្តិទេ ប៉ុន្តែបន្ទាប់ពីការប្តូរអះអាង ពួកគេនៅតែបរាជ័យ។ នៅទីបញ្ចប់ បន្ទាប់ពីសិក្សាកូដដែលបានបង្កើត ខ្ញុំបានដឹងថាបន្ទាប់ពីការប្តូរ ទ្រនិចទៅការណែនាំបច្ចុប្បន្នត្រូវបានផ្ទុកឡើងវិញពីជង់ ហើយប្រហែលជាត្រូវបានសរសេរជាន់លើដោយកូដ JavaScript ដែលបានបង្កើត។ ហើយដូច្នេះវាបានប្រែក្លាយ។ ការបង្កើនសតិបណ្ដោះអាសន្នពីមួយមេហ្គាបៃដល់ដប់មិននាំទៅរកអ្វីនោះទេ ហើយវាច្បាស់ណាស់ថាម៉ាស៊ីនបង្កើតកូដកំពុងដំណើរការជារង្វង់។ យើងត្រូវពិនិត្យមើលថាយើងមិនបានហួសពីព្រំដែននៃជំងឺរបេងបច្ចុប្បន្នទេ ហើយប្រសិនបើយើងធ្វើបាន នោះសូមចេញអាសយដ្ឋានរបស់ជំងឺរបេងបន្ទាប់ជាមួយនឹងសញ្ញាដក ដើម្បីយើងអាចបន្តការប្រតិបត្តិបាន។ លើសពីនេះ វាដោះស្រាយបញ្ហា "មុខងារដែលបានបង្កើតគួរតែមិនត្រឹមត្រូវ ប្រសិនបើបំណែកនៃ bytecode នេះបានផ្លាស់ប្តូរ?" - មានតែមុខងារដែលត្រូវគ្នានឹងប្លុកបកប្រែនេះប៉ុណ្ណោះដែលត្រូវតែមានសុពលភាព។ ដោយវិធីនេះ ទោះបីជាខ្ញុំបានបំបាត់កំហុសគ្រប់យ៉ាងនៅក្នុង 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"]

សេចក្តីសន្និដ្ឋាន

ដូច្នេះហើយ ការងារនៅតែមិនទាន់បញ្ចប់នៅឡើយ ប៉ុន្តែខ្ញុំធុញទ្រាន់នឹងការលួចលាក់ទុកការសាងសង់រយៈពេលវែងនេះឱ្យល្អឥតខ្ចោះ។ ដូច្នេះហើយ ទើប​ខ្ញុំ​សម្រេចចិត្ត​ផ្សព្វផ្សាយ​អ្វីដែល​ខ្ញុំ​មាន​នៅពេលនេះ​។ កូដគឺគួរឱ្យខ្លាចបន្តិចនៅកន្លែង ព្រោះនេះគឺជាការពិសោធន៍ ហើយវាមិនច្បាស់ជាមុននូវអ្វីដែលត្រូវធ្វើ។ ប្រហែលជា, បន្ទាប់មកវាមានតម្លៃក្នុងការចេញ commits អាតូមធម្មតានៅលើកំពូលនៃកំណែទំនើបមួយចំនួននៃ Qemu ។ ក្នុងពេលជាមួយគ្នានេះដែរ មានខ្សែស្រឡាយមួយនៅក្នុង Gita នៅក្នុងទម្រង់ប្លក់មួយ៖ សម្រាប់ "កម្រិត" នីមួយៗដែលយ៉ាងហោចណាស់បានឆ្លងកាត់ការអត្ថាធិប្បាយលម្អិតជាភាសារុស្សីត្រូវបានបន្ថែម។ តាមពិតទៅ អត្ថបទនេះគឺសំដៅលើវិសាលភាពធំនៃការនិយាយឡើងវិញនៃការសន្និដ្ឋាន git log.

អ្នកអាចសាកល្បងវាបានទាំងអស់។ នៅទីនេះ (ប្រយ័ត្នចរាចរណ៍)។

អ្វីដែលដំណើរការរួចហើយ៖

• x86 ដំណើរការនិម្មិត
• មានគំរូដំណើរការនៃម៉ាស៊ីនបង្កើតកូដ JIT ពីកូដម៉ាស៊ីនទៅ JavaScript
• មានគំរូសម្រាប់ដំឡើងស្ថាបត្យកម្មភ្ញៀវ 32 ប៊ីតផ្សេងទៀត៖ ឥឡូវនេះអ្នកអាចសរសើរលីនុចសម្រាប់ការបង្កកស្ថាបត្យកម្ម MIPS នៅក្នុងកម្មវិធីរុករកតាមអ៊ីនធឺណិតនៅដំណាក់កាលផ្ទុក

តើមានអ្វីទៀតដែលអ្នកអាចធ្វើបាន

• បង្កើនល្បឿននៃការត្រាប់តាម។ សូម្បីតែនៅក្នុងរបៀប JIT វាហាក់ដូចជាដំណើរការយឺតជាង Virtual x86 (ប៉ុន្តែមានសក្តានុពល Qemu ទាំងមូលជាមួយនឹងផ្នែករឹង និងស្ថាបត្យកម្មជាច្រើន)
• ដើម្បីបង្កើតចំណុចប្រទាក់ធម្មតា - និយាយដោយត្រង់ទៅ ខ្ញុំមិនមែនជាអ្នកបង្កើតគេហទំព័រល្អទេ ដូច្នេះសម្រាប់ពេលនេះខ្ញុំបានបង្កើតសែល Emscripten ស្តង់ដារឡើងវិញតាមដែលខ្ញុំអាចធ្វើបាន
• ព្យាយាមបើកដំណើរការមុខងារ Qemu ដ៏ស្មុគស្មាញ - បណ្តាញ ការធ្វើចំណាកស្រុក VM ជាដើម។
• UPS៖ អ្នកនឹងត្រូវបញ្ជូនរបាយការណ៍អំពីការអភិវឌ្ឍន៍ និងបញ្ហាមួយចំនួនរបស់អ្នកទៅកាន់ Emscripten upstream ដូចដែលអ្នកដឹកជញ្ជូនពីមុនរបស់ Qemu និងគម្រោងផ្សេងទៀតបានធ្វើ។ សូមអរគុណដល់ពួកគេសម្រាប់លទ្ធភាពប្រើប្រាស់ការរួមចំណែករបស់ពួកគេចំពោះ Emscripten ជាផ្នែកនៃកិច្ចការរបស់ខ្ញុំ។

ប្រភព: www.habr.com