થોડા વર્ષો પહેલા ફેબ્રિસ બેલાર્ડ jslinux દ્વારા લખાયેલ જાવાસ્ક્રિપ્ટમાં લખાયેલ પીસી ઇમ્યુલેટર છે. તે પછી ઓછામાં ઓછું વધુ હતું વર્ચ્યુઅલ x86. પરંતુ તે બધા, જ્યાં સુધી હું જાણું છું, દુભાષિયા હતા, જ્યારે Qemu, જે ખૂબ પહેલા સમાન ફેબ્રિસ બેલાર્ડ દ્વારા લખવામાં આવ્યું હતું, અને, કદાચ, કોઈપણ સ્વાભિમાની આધુનિક ઇમ્યુલેટર, હોસ્ટ સિસ્ટમ કોડમાં ગેસ્ટ કોડના JIT સંકલનનો ઉપયોગ કરે છે. મને એવું લાગતું હતું કે બ્રાઉઝર્સ જે હલ કરે છે તેના સંબંધમાં વિપરીત કાર્યને અમલમાં મૂકવાનો સમય આવી ગયો છે: JavaScript માં મશીન કોડનું JIT સંકલન, જેના માટે તે Qemu પોર્ટ કરવા માટે સૌથી વધુ તાર્કિક લાગતું હતું. એવું લાગે છે, કેમ કેમુ, ત્યાં સરળ અને વપરાશકર્તા મૈત્રીપૂર્ણ એમ્યુલેટર્સ છે - સમાન વર્ચ્યુઅલબોક્સ, ઉદાહરણ તરીકે - ઇન્સ્ટોલ કરેલું અને કાર્ય કરે છે. પરંતુ ક્યુમુમાં ઘણી રસપ્રદ સુવિધાઓ છે

• ખુલ્લા સ્ત્રોત
• કર્નલ ડ્રાઇવર વિના કામ કરવાની ક્ષમતા
• દુભાષિયા મોડમાં કામ કરવાની ક્ષમતા
• હોસ્ટ અને ગેસ્ટ આર્કિટેક્ચર બંને માટે મોટી સંખ્યામાં આધાર

ત્રીજા મુદ્દા વિશે, હું હવે સમજાવી શકું છું કે વાસ્તવમાં, TCI મોડમાં, તે ગેસ્ટ મશીનની સૂચનાઓ નથી જેનું અર્થઘટન કરવામાં આવે છે, પરંતુ તેમાંથી મેળવેલ બાઇટકોડ, પરંતુ આ સાર બદલતું નથી - બનાવવા અને ચલાવવા માટે. નવા આર્કિટેક્ચર પર Qemu, જો તમે નસીબદાર છો, તો A C કમ્પાઇલર પૂરતું છે - કોડ જનરેટર લખવાનું મુલતવી રાખી શકાય છે.

અને હવે, મારા ફ્રી ટાઇમમાં ક્યુમુ સોર્સ કોડ સાથે આરામથી ટિંકર કર્યાના બે વર્ષ પછી, એક કાર્યકારી પ્રોટોટાઇપ દેખાયો, જેમાં તમે પહેલેથી જ ચલાવી શકો છો, ઉદાહરણ તરીકે, કોલિબ્રી ઓએસ.

Emscripten શું છે

આજકાલ, ઘણા કમ્પાઇલર્સ દેખાયા છે, જેનું અંતિમ પરિણામ JavaScript છે. કેટલાક, જેમ કે ટાઈપ સ્ક્રિપ્ટ, મૂળ રીતે વેબ માટે લખવાની શ્રેષ્ઠ રીત બનવાનો હેતુ હતો. તે જ સમયે, Emscripten એ હાલના C અથવા C++ કોડ લેવા અને તેને બ્રાઉઝર-વાંચી શકાય તેવા સ્વરૂપમાં કમ્પાઇલ કરવાની એક રીત છે. ચાલુ આ પૃષ્ઠ અમે જાણીતા પ્રોગ્રામ્સના ઘણા બંદરો એકત્રિત કર્યા છે: અહીંઉદાહરણ તરીકે, તમે PyPy જોઈ શકો છો - માર્ગ દ્વારા, તેઓ પહેલેથી જ JIT હોવાનો દાવો કરે છે. વાસ્તવમાં, દરેક પ્રોગ્રામને ફક્ત બ્રાઉઝરમાં કમ્પાઇલ અને ચલાવી શકાતો નથી - ત્યાં એક નંબર છે વિશેષતા, જે તમારે મૂકવું પડશે, તેમ છતાં, તે જ પૃષ્ઠ પર શિલાલેખ કહે છે કે "Emscripten નો ઉપયોગ લગભગ કોઈપણ કમ્પાઈલ કરવા માટે થઈ શકે છે. પોર્ટેબલ JavaScript માટે C/C++ કોડ." એટલે કે, ત્યાં સંખ્યાબંધ ઑપરેશન્સ છે જે પ્રમાણભૂત અનુસાર અવ્યાખ્યાયિત વર્તન છે, પરંતુ સામાન્ય રીતે x86 પર કામ કરે છે - ઉદાહરણ તરીકે, ચલોની અસંબંધિત ઍક્સેસ, જે સામાન્ય રીતે કેટલાક આર્કિટેક્ચર પર પ્રતિબંધિત છે. સામાન્ય રીતે , Qemu એક ક્રોસ-પ્લેટફોર્મ પ્રોગ્રામ છે અને , હું માનવા માંગતો હતો, અને તેમાં પહેલેથી જ ઘણી બધી અવ્યાખ્યાયિત વર્તણૂક નથી - તેને લો અને કમ્પાઇલ કરો, પછી JIT સાથે થોડું ટિંકર કરો - અને તમે પૂર્ણ કરી લો! પરંતુ તે નથી કેસ...

પ્રથમ પ્રયાસ

સામાન્ય રીતે કહીએ તો, Qemu ને JavaScript પર પોર્ટ કરવાનો વિચાર સાથે આવનાર હું પ્રથમ વ્યક્તિ નથી. ReactOS ફોરમ પર એક પ્રશ્ન પૂછવામાં આવ્યો હતો કે શું Emscripten નો ઉપયોગ કરીને આ શક્ય હતું. અગાઉ પણ, એવી અફવાઓ હતી કે ફેબ્રિસ બેલાર્ડે આ વ્યક્તિગત રીતે કર્યું હતું, પરંતુ અમે jslinux વિશે વાત કરી રહ્યા હતા, જે, જ્યાં સુધી મને ખબર છે, JS માં મેન્યુઅલી પર્યાપ્ત પ્રદર્શન પ્રાપ્ત કરવાનો માત્ર એક પ્રયાસ છે, અને તે શરૂઆતથી લખવામાં આવ્યું હતું. પાછળથી, વર્ચ્યુઅલ x86 લખવામાં આવ્યું હતું - તેના માટે અસ્પષ્ટ સ્ત્રોતો પોસ્ટ કરવામાં આવ્યા હતા, અને, જણાવ્યા મુજબ, ઇમ્યુલેશનના મોટા "વાસ્તવિકવાદ" એ ફર્મવેર તરીકે SeaBIOS નો ઉપયોગ કરવાનું શક્ય બનાવ્યું. વધુમાં, Emscripten નો ઉપયોગ કરીને Qemu પોર્ટ કરવાનો ઓછામાં ઓછો એક પ્રયાસ હતો - મેં આ કરવાનો પ્રયાસ કર્યો સોકેટપેર, પરંતુ વિકાસ, જ્યાં સુધી હું સમજું છું, સ્થિર હતો.

તેથી, એવું લાગે છે કે, અહીં સ્ત્રોતો છે, અહીં Emscripten છે - તેને લો અને કમ્પાઇલ કરો. પરંતુ એવી લાઇબ્રેરીઓ પણ છે કે જેના પર ક્યુમુ આધાર રાખે છે, અને લાઇબ્રેરીઓ કે જેના પર તે લાઇબ્રેરીઓ આધાર રાખે છે, વગેરે, અને તેમાંથી એક છે. libffi, જેના પર આધાર રાખે છે. ઈન્ટરનેટ પર એવી અફવાઓ હતી કે એમસ્ક્રીપ્ટન માટે પુસ્તકાલયોના બંદરોના વિશાળ સંગ્રહમાં એક છે, પરંતુ તે માનવું કોઈક રીતે મુશ્કેલ હતું: પ્રથમ, તે એક નવું કમ્પાઈલર બનવાનો ઈરાદો નહોતો, બીજું, તે ખૂબ નીચા સ્તરનું હતું. લાઇબ્રેરી ફક્ત ઉપાડવા માટે, અને JS પર કમ્પાઇલ કરવા માટે. અને તે માત્ર એસેમ્બલી ઇન્સર્ટની બાબત નથી - કદાચ, જો તમે તેને ટ્વિસ્ટ કરો છો, તો કેટલાક કૉલિંગ સંમેલનો માટે તમે સ્ટેક પર જરૂરી દલીલો જનરેટ કરી શકો છો અને તેના વિના ફંક્શનને કૉલ કરી શકો છો. પરંતુ Emscripten એ એક મુશ્કેલ બાબત છે: બ્રાઉઝર JS એન્જિન ઑપ્ટિમાઇઝરને જનરેટ કરેલા કોડને પરિચિત બનાવવા માટે, કેટલીક યુક્તિઓનો ઉપયોગ કરવામાં આવે છે. ખાસ કરીને, કહેવાતા રીલૂપિંગ - અમુક અમૂર્ત સંક્રમણ સૂચનાઓ સાથે પ્રાપ્ત થયેલ LLVM IR નો ઉપયોગ કરીને કોડ જનરેટર બુદ્ધિગમ્ય ifs, લૂપ્સ વગેરેને ફરીથી બનાવવાનો પ્રયાસ કરે છે. સારું, ફંક્શનમાં દલીલો કેવી રીતે પસાર થાય છે? સ્વાભાવિક રીતે, JS ફંક્શન્સની દલીલો તરીકે, એટલે કે, જો શક્ય હોય તો, સ્ટેક દ્વારા નહીં.

શરૂઆતમાં ફક્ત JS સાથે libffi માટે રિપ્લેસમેન્ટ લખવાનો અને પ્રમાણભૂત પરીક્ષણો ચલાવવાનો વિચાર આવ્યો, પરંતુ અંતે હું મારી હેડર ફાઇલો કેવી રીતે બનાવવી તે અંગે મૂંઝવણમાં પડી ગયો જેથી તેઓ હાલના કોડ સાથે કામ કરે - હું શું કરી શકું, જેમ તેઓ કહે છે, "શું કાર્યો એટલા જટિલ છે "શું આપણે એટલા મૂર્ખ છીએ?" મારે લિબ્ફીને બીજા આર્કિટેક્ચરમાં પોર્ટ કરવું પડ્યું, તેથી વાત કરવા માટે - સદનસીબે, Emscripten પાસે ઇનલાઇન એસેમ્બલી માટે બંને મેક્રો છે (જાવાસ્ક્રિપ્ટમાં, હા - સારું, આર્કિટેક્ચર ગમે તે હોય, તો એસેમ્બલર), અને ફ્લાય પર જનરેટ થયેલ કોડ ચલાવવાની ક્ષમતા. સામાન્ય રીતે, કેટલાક સમય માટે પ્લેટફોર્મ-આધારિત લિબ્ફી ટુકડાઓ સાથે ટિંકરિંગ કર્યા પછી, મને કેટલાક સંકલન કરી શકાય તેવા કોડ મળ્યા અને તે પ્રથમ કસોટી પર ચલાવ્યો જે હું મળ્યો હતો. મારા આશ્ચર્ય માટે, પરીક્ષણ સફળ થયું. મારી પ્રતિભાથી દંગ રહી ગયો - કોઈ મજાક નહીં, તે પ્રથમ લોન્ચથી જ કામ કરે છે - હું, હજી પણ મારી આંખો પર વિશ્વાસ ન કરતો, પરિણામી કોડને ફરીથી જોવા ગયો, આગળ ક્યાં ખોદવું તેનું મૂલ્યાંકન કરવા ગયો. અહીં હું બીજી વાર નટખટ થઈ ગયો - મારા કાર્યમાં માત્ર એક જ વસ્તુ હતી ffi_call - આ એક સફળ કૉલની જાણ કરી. પોતે કોઈ કોલ નહોતો. તેથી મેં મારી પ્રથમ પુલ વિનંતી મોકલી, જેણે કોઈપણ ઓલિમ્પિયાડના વિદ્યાર્થી માટે સ્પષ્ટ હોય તેવા પરીક્ષણમાં ભૂલ સુધારી હતી - વાસ્તવિક સંખ્યાઓની સરખામણી આ રીતે થવી જોઈએ નહીં a == b અને કેવી રીતે પણ a - b < EPS - તમારે મોડ્યુલને પણ યાદ રાખવાની જરૂર છે, અન્યથા 0 1/3 ની બરાબર હશે... સામાન્ય રીતે, હું libffi ના ચોક્કસ પોર્ટ સાથે આવ્યો છું, જે સૌથી સરળ પરીક્ષણો પાસ કરે છે, અને જેની સાથે glib છે. સંકલિત - મેં નક્કી કર્યું કે તે જરૂરી છે, હું તેને પછીથી ઉમેરીશ. આગળ જોઈને, હું કહીશ કે, જેમ તે બહાર આવ્યું છે, કમ્પાઈલર એ અંતિમ કોડમાં libffi ફંક્શનનો પણ સમાવેશ કર્યો નથી.

પરંતુ, જેમ મેં પહેલેથી જ કહ્યું છે, ત્યાં કેટલીક મર્યાદાઓ છે, અને વિવિધ અવ્યાખ્યાયિત વર્તનના મફત ઉપયોગ વચ્ચે, એક વધુ અપ્રિય લક્ષણ છુપાયેલું છે - ડિઝાઇન દ્વારા JavaScript શેર કરેલી મેમરી સાથે મલ્ટિથ્રેડિંગને સપોર્ટ કરતું નથી. સૈદ્ધાંતિક રીતે, આને સામાન્ય રીતે એક સારો વિચાર પણ કહી શકાય, પરંતુ પોર્ટિંગ કોડ માટે નહીં જેનું આર્કિટેક્ચર C થ્રેડો સાથે જોડાયેલું છે. સામાન્ય રીતે કહીએ તો, ફાયરફોક્સ વહેંચાયેલ કામદારોને ટેકો આપવા સાથે પ્રયોગ કરી રહ્યું છે, અને એમસ્ક્રીપ્ટન પાસે તેમના માટે એક pthread અમલીકરણ છે, પરંતુ હું તેના પર આધાર રાખવા માંગતો ન હતો. મારે Qemu કોડમાંથી મલ્ટિથ્રેડિંગને ધીમે ધીમે રુટ આઉટ કરવું પડ્યું - એટલે કે, થ્રેડો ક્યાં ચાલી રહ્યા છે તે શોધો, આ થ્રેડમાં ચાલતા લૂપના મુખ્ય ભાગને એક અલગ ફંક્શનમાં ખસેડો, અને મુખ્ય લૂપમાંથી એક પછી એક આવા કાર્યોને કૉલ કરો.

બીજો પ્રયાસ

અમુક સમયે, તે સ્પષ્ટ થઈ ગયું કે સમસ્યા હજી પણ ત્યાં જ છે, અને કોડની આજુબાજુ આડેધડ રીતે હલાવવાથી કોઈ સારું થશે નહીં. નિષ્કર્ષ: આપણે કોઈક રીતે ક્રેચ ઉમેરવાની પ્રક્રિયાને વ્યવસ્થિત કરવાની જરૂર છે. તેથી, સંસ્કરણ 2.4.1, જે તે સમયે તાજું હતું, લેવામાં આવ્યું હતું (2.5.0 નહીં, કારણ કે, કોણ જાણે છે, નવા સંસ્કરણમાં એવી ભૂલો હશે જે હજી સુધી પકડાઈ નથી, અને મારી પાસે મારી પોતાની ભૂલો પૂરતી છે. ), અને પ્રથમ વસ્તુ તેને સુરક્ષિત રીતે ફરીથી લખવાનું હતું thread-posix.c. ઠીક છે, તે છે, સલામત છે: જો કોઈએ અવરોધ તરફ દોરીને ઑપરેશન કરવાનો પ્રયાસ કર્યો, તો ફંક્શનને તરત જ કૉલ કરવામાં આવ્યો હતો abort() - અલબત્ત, આનાથી બધી સમસ્યાઓ એક જ સમયે હલ થઈ નથી, પરંતુ ઓછામાં ઓછું તે શાંતિથી અસંગત ડેટા પ્રાપ્ત કરવા કરતાં કોઈક રીતે વધુ સુખદ હતું.

સામાન્ય રીતે, JS પર કોડ પોર્ટ કરવા માટે Emscripten વિકલ્પો ખૂબ જ મદદરૂપ થાય છે -s ASSERTIONS=1 -s SAFE_HEAP=1 - તેઓ અમુક પ્રકારના અવ્યાખ્યાયિત વર્તનને પકડે છે, જેમ કે અસંરેખિત સરનામાં પર કૉલ (જે ટાઇપ કરેલ એરે માટેના કોડ સાથે બિલકુલ સુસંગત નથી જેમ કે HEAP32[addr >> 2] = 1) અથવા દલીલોની ખોટી સંખ્યા સાથે ફંક્શનને કૉલ કરવું.

માર્ગ દ્વારા, સંરેખણ ભૂલો એ એક અલગ મુદ્દો છે. મેં પહેલેથી જ કહ્યું તેમ, કોડ જનરેશન TCI (નાના કોડ ઈન્ટરપ્રીટર) માટે Qemu પાસે "ડિજનરેટ" અર્થઘટનાત્મક બેકએન્ડ છે, અને નવા આર્કિટેક્ચર પર Qemu બનાવવા અને ચલાવવા માટે, જો તમે નસીબદાર છો, તો C કમ્પાઈલર પૂરતું છે. કીવર્ડ્સ "જો તમે નસીબદાર છો". હું કમનસીબ હતો, અને તે બહાર આવ્યું કે TCI તેના બાઇટકોડને પાર્સ કરતી વખતે અસંરેખિત ઍક્સેસનો ઉપયોગ કરે છે. એટલે કે, તમામ પ્રકારના એઆરએમ અને અન્ય આર્કિટેક્ચર્સ પર જરૂરી સ્તરીય ઍક્સેસ સાથે, ક્યુમુ કમ્પાઇલ કરે છે કારણ કે તેમની પાસે સામાન્ય TCG બેકએન્ડ છે જે મૂળ કોડ જનરેટ કરે છે, પરંતુ TCI તેમના પર કામ કરશે કે કેમ તે બીજો પ્રશ્ન છે. જો કે, તે બહાર આવ્યું તેમ, TCI દસ્તાવેજો સ્પષ્ટપણે કંઈક સમાન સૂચવે છે. પરિણામે, કોડમાં અસંરેખિત વાંચન માટે ફંક્શન કોલ્સ ઉમેરવામાં આવ્યા હતા, જે ક્યુમુના બીજા ભાગમાં જોવા મળ્યા હતા.

ઢગલો વિનાશ

પરિણામે, TCI ની અસંબંધિત ઍક્સેસને ઠીક કરવામાં આવી હતી, એક મુખ્ય લૂપ બનાવવામાં આવ્યો હતો જેને બદલામાં પ્રોસેસર, RCU અને અન્ય કેટલીક નાની વસ્તુઓ કહેવામાં આવે છે. અને તેથી હું વિકલ્પ સાથે Qemu લોન્ચ કરું છું -d exec,in_asm,out_asm, જેનો અર્થ છે કે તમારે કહેવાની જરૂર છે કે કોડના કયા બ્લોક્સ એક્ઝિક્યુટ થઈ રહ્યા છે, અને પ્રસારણ સમયે ગેસ્ટ કોડ કયો હતો, કયો હોસ્ટ કોડ બન્યો (આ કિસ્સામાં, બાયટેકોડ) લખવા માટે. તે શરૂ થાય છે, કેટલાક અનુવાદ બ્લોક્સને એક્ઝિક્યુટ કરે છે, ડિબગીંગ મેસેજ લખે છે જે મેં છોડ્યો હતો કે RCU હવે શરૂ થશે અને... ક્રેશ abort() કાર્યની અંદર free(). કાર્ય સાથે ટિંકરિંગ દ્વારા free() અમે એ શોધવામાં વ્યવસ્થાપિત થયા કે ઢગલા બ્લોકના હેડરમાં, જે ફાળવેલ મેમરીની પહેલાની આઠ બાઇટ્સમાં આવેલું છે, બ્લોકના કદને બદલે અથવા તેના જેવું કંઈક, ત્યાં કચરો હતો.

ઢગલાનો વિનાશ - કેટલો સુંદર... આવા કિસ્સામાં, એક ઉપયોગી ઉપાય છે - (જો શક્ય હોય તો) સમાન સ્ત્રોતોમાંથી, મૂળ દ્વિસંગી એસેમ્બલ કરો અને તેને Valgrind હેઠળ ચલાવો. થોડા સમય પછી, બાઈનરી તૈયાર થઈ ગઈ. હું તેને સમાન વિકલ્પો સાથે લૉન્ચ કરું છું - તે વાસ્તવમાં એક્ઝેક્યુશન સુધી પહોંચતા પહેલા, આરંભ દરમિયાન પણ ક્રેશ થાય છે. તે અપ્રિય છે, અલબત્ત - દેખીતી રીતે, સ્ત્રોતો બરાબર સમાન ન હતા, જે આશ્ચર્યજનક નથી, કારણ કે રૂપરેખાંકિતમાં થોડા અલગ વિકલ્પો છે, પરંતુ મારી પાસે Valgrind છે - પ્રથમ હું આ ભૂલને ઠીક કરીશ, અને પછી, જો હું નસીબદાર છું , મૂળ દેખાશે. હું તે જ વસ્તુ Valgrind હેઠળ ચલાવી રહ્યો છું... Y-y-y, y-y-y, ઉહ-ઉહ, તે શરૂ થયું, સામાન્ય રીતે આરંભમાંથી પસાર થયું અને ખોટી મેમરી એક્સેસ વિશે એક પણ ચેતવણી આપ્યા વિના મૂળ બગમાંથી આગળ વધ્યો, ફોલ્સ વિશે ઉલ્લેખ ન કરવો. જીવન, જેમ તેઓ કહે છે, મને આ માટે તૈયાર કર્યો નથી - જ્યારે વોલગ્રિન્ડ હેઠળ લોંચ કરવામાં આવે ત્યારે ક્રેશિંગ પ્રોગ્રામ ક્રેશ થવાનું બંધ કરે છે. તે શું હતું તે એક રહસ્ય છે. મારી પૂર્વધારણા એ છે કે એકવાર પ્રારંભ દરમિયાન ક્રેશ થયા પછી વર્તમાન સૂચનાની નજીકમાં, gdb એ કામ બતાવ્યું memset-એકનો ઉપયોગ કરીને માન્ય પોઇન્ટર સાથે mmx, અથવા xmm રજીસ્ટર કરે છે, તો કદાચ તે સંરેખણની કોઈ પ્રકારની ભૂલ હતી, જો કે તે હજુ પણ માનવું મુશ્કેલ છે.

ઠીક છે, Valgrind અહીં મદદ કરશે એવું લાગતું નથી. અને અહીં સૌથી ઘૃણાસ્પદ વસ્તુ શરૂ થઈ - બધું જ શરૂ થયું હોય તેવું લાગે છે, પરંતુ લાખો સૂચનાઓ પહેલા બની શકે તેવી ઘટનાને કારણે એકદમ અજાણ્યા કારણોસર ક્રેશ થાય છે. લાંબા સમય સુધી, કેવી રીતે સંપર્ક કરવો તે પણ સ્પષ્ટ ન હતું. અંતે, મારે હજી બેસીને ડીબગ કરવું પડ્યું. હેડરને જે સાથે ફરીથી લખવામાં આવ્યું હતું તે છાપવાથી તે દર્શાવે છે કે તે સંખ્યા જેવો દેખાતો નથી, પરંતુ અમુક પ્રકારનો બાઈનરી ડેટા છે. અને, જુઓ અને જુઓ, આ દ્વિસંગી શબ્દમાળા BIOS ફાઇલમાં મળી હતી - એટલે કે, હવે વાજબી વિશ્વાસ સાથે કહેવું શક્ય હતું કે તે બફર ઓવરફ્લો છે, અને તે સ્પષ્ટ છે કે તે આ બફર પર લખવામાં આવ્યું હતું. ઠીક છે, તો પછી કંઈક આના જેવું - Emscripten માં, સદભાગ્યે, સરનામાંની જગ્યાનું કોઈ રેન્ડમાઇઝેશન નથી, તેમાં કોઈ છિદ્રો પણ નથી, તેથી તમે છેલ્લી લોન્ચથી પોઇન્ટર દ્વારા ડેટા આઉટપુટ કરવા માટે કોડની મધ્યમાં ક્યાંક લખી શકો છો, ડેટા જુઓ, નિર્દેશક જુઓ અને, જો તે બદલાયો નથી, તો વિચાર માટે ખોરાક મેળવો. સાચું, કોઈપણ ફેરફાર પછી લિંક કરવામાં થોડી મિનિટો લાગે છે, પરંતુ તમે શું કરી શકો? પરિણામે, એક ચોક્કસ લાઇન મળી આવી હતી જેણે BIOS ને અસ્થાયી બફરમાંથી ગેસ્ટ મેમરીમાં કૉપિ કરી હતી - અને, ખરેખર, બફરમાં પૂરતી જગ્યા નહોતી. તે વિચિત્ર બફર સરનામાંનો સ્ત્રોત શોધવાનું કાર્ય પરિણમ્યું qemu_anon_ram_alloc ફાઇલમાં oslib-posix.c - ત્યાં તર્ક આ હતો: કેટલીકવાર તે 2 MB કદના વિશાળ પૃષ્ઠ પર સરનામાંને સંરેખિત કરવા માટે ઉપયોગી થઈ શકે છે, આ માટે અમે પૂછીશું mmap પહેલા થોડી વધુ, અને પછી અમે મદદ સાથે વધારાની રકમ પરત કરીશું munmap. અને જો આવા સંરેખણની જરૂર નથી, તો અમે 2 MB ને બદલે પરિણામ સૂચવીશું getpagesize() - mmap તે હજુ પણ સંરેખિત સરનામું આપશે... તેથી એમ્સ્ક્રીપ્ટનમાં mmap માત્ર કોલ કરે છે malloc, પરંતુ અલબત્ત તે પૃષ્ઠ પર સંરેખિત થતું નથી. સામાન્ય રીતે, એક બગ કે જેણે મને થોડા મહિનાઓ માટે નિરાશ કર્યો હતો તેમાં ફેરફાર દ્વારા સુધારાઈ હતી двух રેખાઓ

કૉલિંગ કાર્યોની સુવિધાઓ

અને હવે પ્રોસેસર કંઈક ગણી રહ્યું છે, ક્યુમુ ક્રેશ થતું નથી, પરંતુ સ્ક્રીન ચાલુ થતી નથી, અને પ્રોસેસર આઉટપુટ દ્વારા નક્કી કરીને ઝડપથી લૂપ્સમાં જાય છે. -d exec,in_asm,out_asm. એક પૂર્વધારણા ઉભરી આવી છે: ટાઈમર વિક્ષેપો (અથવા, સામાન્ય રીતે, બધા વિક્ષેપો) આવતા નથી. અને ખરેખર, જો તમે મૂળ એસેમ્બલીમાંથી વિક્ષેપોને સ્ક્રૂ કાઢી નાખો, જે કોઈ કારણોસર કામ કરે છે, તો તમને સમાન ચિત્ર મળશે. પરંતુ આ બિલકુલ જવાબ ન હતો: ઉપરોક્ત વિકલ્પ સાથે જારી કરાયેલા નિશાનોની સરખામણી દર્શાવે છે કે અમલના માર્ગો ખૂબ જ વહેલા અલગ થઈ ગયા હતા. અહીં તે કહેવું આવશ્યક છે કે લૉન્ચરનો ઉપયોગ કરીને શું રેકોર્ડ કરવામાં આવ્યું હતું તેની સરખામણી emrun નેટીવ એસેમ્બલીના આઉટપુટ સાથે ડીબગીંગ આઉટપુટ એ સંપૂર્ણપણે યાંત્રિક પ્રક્રિયા નથી. મને બરાબર ખબર નથી કે બ્રાઉઝરમાં ચાલતો પ્રોગ્રામ કેવી રીતે કનેક્ટ થાય છે emrun, પરંતુ આઉટપુટમાં કેટલીક રેખાઓ ફરીથી ગોઠવવામાં આવે છે, તેથી તફાવતમાં તફાવત હજુ સુધી એવું માની લેવાનું કારણ નથી કે ટ્રેજેકટ્રીઝ અલગ થઈ ગઈ છે. સામાન્ય રીતે, તે સ્પષ્ટ થઈ ગયું કે સૂચનાઓ અનુસાર ljmpl અલગ-અલગ સરનામાંઓ પર સંક્રમણ છે, અને જનરેટ થયેલ બાઈટકોડ મૂળભૂત રીતે અલગ છે: એકમાં હેલ્પર ફંક્શનને કૉલ કરવાની સૂચના છે, બીજામાં નથી. સૂચનાઓને ગૂગલ કર્યા પછી અને આ સૂચનાઓનો અનુવાદ કરતા કોડનો અભ્યાસ કર્યા પછી, તે સ્પષ્ટ થઈ ગયું કે, સૌ પ્રથમ, રજિસ્ટરમાં તેની પહેલાં તરત જ cr0 એક રેકોર્ડિંગ કરવામાં આવ્યું હતું - સહાયકનો ઉપયોગ કરીને પણ - જેણે પ્રોસેસરને સુરક્ષિત મોડ પર સ્વિચ કર્યું, અને બીજું, કે જેએસ સંસ્કરણ ક્યારેય સુરક્ષિત મોડ પર સ્વિચ કર્યું નથી. પરંતુ હકીકત એ છે કે એમ્સ્ક્રીપ્ટનની બીજી વિશેષતા એ છે કે સૂચનાઓના અમલીકરણ જેવા કોડને સહન કરવામાં તેની અનિચ્છા 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+ નેટીવ એસેમ્બલીમાં ચલાવવા માટે સક્ષમ હતું. અહીં એ સ્પષ્ટ કરવું જરૂરી છે કે Qemu બ્લોક I/O કોડ કોરોટીનમાં લખાયેલો છે. Emscriptenનું પોતાનું ખૂબ જ મુશ્કેલ અમલીકરણ છે, પરંતુ તે હજુ પણ Qemu કોડમાં સમર્થિત હોવું જરૂરી છે, અને તમે હવે પ્રોસેસરને ડીબગ કરી શકો છો: Qemu વિકલ્પોને સપોર્ટ કરે છે -kernel, -initrd, -append, જેની સાથે તમે Linux ને બુટ કરી શકો છો અથવા, ઉદાહરણ તરીકે, memtest86+, બ્લોક ઉપકરણોનો ઉપયોગ કર્યા વિના. પરંતુ અહીં સમસ્યા છે: મૂળ એસેમ્બલીમાં તમે વિકલ્પ સાથે કન્સોલ પર Linux કર્નલ આઉટપુટ જોઈ શકો છો. -nographic, અને બ્રાઉઝરથી ટર્મિનલ પર કોઈ આઉટપુટ નથી જ્યાંથી તે લોન્ચ કરવામાં આવ્યું હતું emrun, આવ્યો નથી. એટલે કે, તે સ્પષ્ટ નથી: પ્રોસેસર કામ કરી રહ્યું નથી અથવા ગ્રાફિક્સ આઉટપુટ કામ કરી રહ્યું નથી. અને પછી મને થોડી રાહ જોવાનું મન થયું. તે બહાર આવ્યું છે કે "પ્રોસેસર સૂઈ રહ્યું નથી, પરંતુ ધીમે ધીમે ઝબકતું હતું," અને લગભગ પાંચ મિનિટ પછી કર્નલએ કન્સોલ પર સંદેશાઓનો સમૂહ ફેંકી દીધો અને અટકવાનું ચાલુ રાખ્યું. તે સ્પષ્ટ થઈ ગયું કે પ્રોસેસર, સામાન્ય રીતે, કામ કરે છે, અને અમને SDL2 સાથે કામ કરવા માટે કોડમાં ડિગ કરવાની જરૂર છે. કમનસીબે, મને આ લાઇબ્રેરીનો ઉપયોગ કેવી રીતે કરવો તે ખબર નથી, તેથી કેટલીક જગ્યાએ મારે રેન્ડમ રીતે કાર્ય કરવું પડ્યું. અમુક સમયે, વાદળી પૃષ્ઠભૂમિ પર સ્ક્રીન પર સમાંતર0 રેખા ચમકતી હતી, જેણે કેટલાક વિચારો સૂચવ્યા હતા. અંતે, તે બહાર આવ્યું કે સમસ્યા એ હતી કે Qemu એક ભૌતિક વિંડોમાં ઘણી વર્ચ્યુઅલ વિન્ડો ખોલે છે, જેની વચ્ચે તમે Ctrl-Alt-n નો ઉપયોગ કરીને સ્વિચ કરી શકો છો: તે મૂળ બિલ્ડમાં કામ કરે છે, પરંતુ Emscripten માં નહીં. વિકલ્પોનો ઉપયોગ કરીને બિનજરૂરી વિંડોઝથી છુટકારો મેળવ્યા પછી -monitor none -parallel none -serial none અને દરેક ફ્રેમ પર આખી સ્ક્રીનને બળપૂર્વક ફરીથી દોરવાની સૂચનાઓ, બધું અચાનક કામ કરી ગયું.

કોરોટીન્સ

તેથી, બ્રાઉઝરમાં ઇમ્યુલેશન કાર્ય કરે છે, પરંતુ તમે તેમાં કંઈપણ રસપ્રદ સિંગલ-ફ્લોપી ચલાવી શકતા નથી, કારણ કે ત્યાં કોઈ બ્લોક I/O નથી - તમારે કોરોટીન માટે સપોર્ટ લાગુ કરવાની જરૂર છે. Qemu પાસે પહેલાથી જ ઘણા કોરોટીન બેકએન્ડ છે, પરંતુ JavaScript અને Emscripten કોડ જનરેટરની પ્રકૃતિને લીધે, તમે માત્ર જાદુગરી સ્ટેક્સ શરૂ કરી શકતા નથી. એવું લાગે છે કે "બધું જતું રહ્યું છે, પ્લાસ્ટર દૂર કરવામાં આવી રહ્યું છે," પરંતુ Emscripten વિકાસકર્તાઓએ પહેલેથી જ બધું સંભાળી લીધું છે. આ તદ્દન રમુજી અમલમાં મૂકવામાં આવ્યું છે: ચાલો આ શંકાસ્પદ જેવા ફંક્શન કૉલને કૉલ કરીએ emscripten_sleep અને અન્ય ઘણા લોકો Asyncify મિકેનિઝમનો ઉપયોગ કરે છે, તેમજ પોઈન્ટર કોલ્સ અને કોઈપણ ફંક્શન માટે કોલ્સ જ્યાં પહેલાના બે કેસમાંથી એક સ્ટેકની નીચે આવી શકે છે. અને હવે, દરેક શંકાસ્પદ કૉલ પહેલાં, અમે એક અસિંક સંદર્ભ પસંદ કરીશું, અને કૉલ પછી તરત જ, અમે તપાસ કરીશું કે અસુમેળ કૉલ આવ્યો છે કે કેમ, અને જો તે હશે, તો અમે આ અસિંક સંદર્ભમાં તમામ સ્થાનિક ચલોને સાચવીશું, જે સૂચવે છે કે કયું કાર્ય જ્યારે અમને એક્ઝેક્યુશન ચાલુ રાખવાની જરૂર હોય ત્યારે નિયંત્રણ સ્થાનાંતરિત કરવા અને વર્તમાન કાર્યમાંથી બહાર નીકળવા માટે. આ તે છે જ્યાં અસરનો અભ્યાસ કરવાનો અવકાશ છે ગુમાવવુ અસુમેળ કૉલમાંથી પાછા ફર્યા પછી કોડ એક્ઝિક્યુશન ચાલુ રાખવાની જરૂરિયાતો માટે, કમ્પાઇલર શંકાસ્પદ કૉલ પછી શરૂ થતા ફંક્શનના "સ્ટબ્સ" જનરેટ કરે છે — જેમ કે: જો ત્યાં n શંકાસ્પદ કૉલ્સ હોય, તો ફંક્શનને ક્યાંક n/2 માં વિસ્તૃત કરવામાં આવશે. વખત — આ હજુ પણ છે, જો નહીં તો ધ્યાનમાં રાખો કે દરેક સંભવિત અસુમેળ કૉલ પછી, તમારે મૂળ કાર્યમાં કેટલાક સ્થાનિક ચલોને સાચવવાની જરૂર છે. ત્યારબાદ, મારે પાયથોનમાં એક સરળ સ્ક્રિપ્ટ પણ લખવી પડી, જે, ખાસ કરીને વધુ પડતા ઉપયોગમાં લેવાતા કાર્યોના આપેલ સેટ પર આધારિત છે જે માનવામાં આવે છે કે "અસુમેળને પોતાને પસાર થવા દેતા નથી" (એટલે ​​​​કે, સ્ટેક પ્રમોશન અને મેં હમણાં જ વર્ણવેલ બધું નથી. તેમાં કામ કરે છે), પોઇંટર્સ દ્વારા કોલ્સ સૂચવે છે જેમાં કમ્પાઇલર દ્વારા ફંક્શન્સને અવગણવા જોઈએ જેથી આ ફંક્શન્સને અસિંક્રોનસ ગણવામાં ન આવે. અને પછી 60 MB હેઠળની JS ફાઈલો સ્પષ્ટપણે ખૂબ વધારે છે - ચાલો કહીએ કે ઓછામાં ઓછી 30. જોકે, એકવાર હું એસેમ્બલી સ્ક્રિપ્ટ સેટ કરી રહ્યો હતો, અને આકસ્મિક રીતે લિંકર વિકલ્પો ફેંકી દીધા, જેમાંથી -O3. હું જનરેટ કરેલ કોડ ચલાવું છું, અને ક્રોમિયમ મેમરી અને ક્રેશને ખાઈ જાય છે. પછી મેં આકસ્મિક રીતે જોયું કે તે શું ડાઉનલોડ કરવાનો પ્રયાસ કરી રહ્યો હતો... સારું, હું શું કહી શકું, જો મને 500+ MB Javascript વિચારપૂર્વક અભ્યાસ કરવા અને ઑપ્ટિમાઇઝ કરવાનું કહેવામાં આવ્યું હોત તો હું પણ સ્થિર થઈ ગયો હોત.

કમનસીબે, Asyncify સપોર્ટ લાઇબ્રેરી કોડમાંના ચેક સંપૂર્ણપણે મૈત્રીપૂર્ણ ન હતા longjmp-s જેનો ઉપયોગ વર્ચ્યુઅલ પ્રોસેસર કોડમાં થાય છે, પરંતુ નાના પેચ કે જે આ તપાસને અક્ષમ કરે છે અને સંદર્ભોને બળપૂર્વક પુનઃસ્થાપિત કરે છે તે પછી બધું બરાબર હતું, કોડ કામ કરે છે. અને પછી એક વિચિત્ર વસ્તુ શરૂ થઈ: કેટલીકવાર સિંક્રનાઇઝેશન કોડમાં તપાસો ટ્રિગર કરવામાં આવી હતી - તે જ જે કોડને ક્રેશ કરે છે જો, એક્ઝેક્યુશન લોજિક અનુસાર, તેને અવરોધિત કરવો જોઈએ - કોઈએ પહેલેથી જ કેપ્ચર કરેલ મ્યુટેક્સને પકડવાનો પ્રયાસ કર્યો. સદભાગ્યે, સીરીયલાઈઝ્ડ કોડમાં આ કોઈ તાર્કિક સમસ્યા ન હોવાનું બહાર આવ્યું - હું ફક્ત Emscripten દ્વારા પૂરી પાડવામાં આવેલ માનક મુખ્ય લૂપ કાર્યક્ષમતાનો ઉપયોગ કરી રહ્યો હતો, પરંતુ કેટલીકવાર અસુમેળ કૉલ સ્ટેકને સંપૂર્ણપણે ખોલી નાખે છે, અને તે ક્ષણે તે નિષ્ફળ જશે. setTimeout મુખ્ય લૂપમાંથી - આમ, કોડ અગાઉના પુનરાવર્તનને છોડ્યા વિના મુખ્ય લૂપ પુનરાવર્તનમાં દાખલ થયો. અનંત લૂપ પર ફરીથી લખો અને emscripten_sleep, અને મ્યુટેક્સ સાથેની સમસ્યાઓ બંધ થઈ ગઈ. કોડ વધુ તાર્કિક બની ગયો છે - છેવટે, હકીકતમાં, મારી પાસે કોઈ કોડ નથી જે આગામી એનિમેશન ફ્રેમ તૈયાર કરે છે - પ્રોસેસર ફક્ત કંઈક ગણતરી કરે છે અને સ્ક્રીન સમયાંતરે અપડેટ થાય છે. જો કે, સમસ્યાઓ ત્યાં અટકી ન હતી: કેટલીકવાર Qemu એક્ઝેક્યુશન કોઈપણ અપવાદો અથવા ભૂલો વિના શાંતિથી સમાપ્ત થઈ જાય છે. તે ક્ષણે મેં તેને છોડી દીધું, પરંતુ, આગળ જોતાં, હું કહીશ કે સમસ્યા આ હતી: કોરોટીન કોડ, હકીકતમાં, ઉપયોગ કરતું નથી setTimeout (અથવા ઓછામાં ઓછું તમે જેટલી વાર વિચારી શકો તેટલી વાર નહીં): કાર્ય emscripten_yield ફક્ત અસુમેળ કોલ ધ્વજ સેટ કરે છે. સમગ્ર મુદ્દો એ છે કે emscripten_coroutine_next અસુમેળ કાર્ય નથી: આંતરિક રીતે તે ધ્વજને તપાસે છે, તેને ફરીથી સેટ કરે છે અને જ્યાં તેની જરૂર હોય ત્યાં નિયંત્રણ સ્થાનાંતરિત કરે છે. એટલે કે, સ્ટેકનું પ્રમોશન ત્યાં સમાપ્ત થાય છે. સમસ્યા એ હતી કે ઉપયોગ-આફ્ટર-ફ્રી હોવાને કારણે, જે દેખાય છે જ્યારે કોરોટીન પૂલ અક્ષમ કરવામાં આવ્યો હતો તે હકીકતને કારણે કે મેં વર્તમાન કોરોટીન બેકએન્ડમાંથી કોડની મહત્વપૂર્ણ લાઇનની નકલ કરી નથી, કાર્ય qemu_in_coroutine સાચું પાછું આવ્યું જ્યારે હકીકતમાં તે ખોટું પાછું આવવું જોઈએ. જેના કારણે ફોન આવ્યો હતો emscripten_yield, જેની ઉપર સ્ટેક પર કોઈ નહોતું emscripten_coroutine_next, સ્ટેક ખૂબ ટોચ પર unfolded, પરંતુ ના setTimeout, મેં પહેલેથી જ કહ્યું તેમ, પ્રદર્શિત કરવામાં આવ્યું ન હતું.

JavaScript કોડ જનરેશન

અને અહીં, હકીકતમાં, "નાજુકાઈના માંસને પાછું ફેરવવાનું" વચન આપવામાં આવ્યું છે. ખરેખર નથી. અલબત્ત, જો આપણે બ્રાઉઝરમાં Qemu અને તેમાં Node.js ચલાવીએ, તો સ્વાભાવિક રીતે, Qemuમાં કોડ જનરેશન પછી આપણને સંપૂર્ણપણે ખોટી JavaScript મળશે. પરંતુ હજુ પણ, અમુક પ્રકારનું વિપરીત પરિવર્તન.

પ્રથમ, ક્યુમુ કેવી રીતે કાર્ય કરે છે તે વિશે થોડું. કૃપા કરીને મને તરત જ માફ કરો: હું વ્યાવસાયિક Qemu ડેવલપર નથી અને મારા તારણો કેટલીક જગ્યાએ ભૂલભરેલા હોઈ શકે છે. જેમ તેઓ કહે છે, "વિદ્યાર્થીનો અભિપ્રાય શિક્ષકના અભિપ્રાય, પીઆનોના સ્વતઃશાસ્ત્ર અને સામાન્ય જ્ઞાન સાથે સુસંગત હોવો જરૂરી નથી." Qemu પાસે ચોક્કસ સંખ્યામાં સમર્થિત ગેસ્ટ આર્કિટેક્ચર છે અને દરેક માટે ડિરેક્ટરી જેવી છે target-i386. બિલ્ડીંગ કરતી વખતે, તમે કેટલાક ગેસ્ટ આર્કિટેક્ચરો માટે સપોર્ટનો ઉલ્લેખ કરી શકો છો, પરંતુ પરિણામ ફક્ત કેટલાક દ્વિસંગી હશે. ગેસ્ટ આર્કિટેક્ચરને ટેકો આપવા માટેનો કોડ, બદલામાં, કેટલાક આંતરિક Qemu ઑપરેશન્સ જનરેટ કરે છે, જે TCG (નાના કોડ જનરેટર) પહેલેથી જ હોસ્ટ આર્કિટેક્ચર માટે મશીન કોડમાં ફેરવે છે. tcg ડિરેક્ટરીમાં સ્થિત રીડમી ફાઇલમાં જણાવ્યા મુજબ, આ મૂળરૂપે નિયમિત C કમ્પાઇલરનો ભાગ હતો, જે પાછળથી JIT માટે સ્વીકારવામાં આવ્યો હતો. તેથી, ઉદાહરણ તરીકે, આ દસ્તાવેજની દ્રષ્ટિએ લક્ષ્ય આર્કિટેક્ચર હવે ગેસ્ટ આર્કિટેક્ચર નથી, પરંતુ હોસ્ટ આર્કિટેક્ચર છે. અમુક સમયે, અન્ય ઘટક દેખાયો - નાનો કોડ ઈન્ટરપ્રીટર (TCI), જે ચોક્કસ હોસ્ટ આર્કિટેક્ચર માટે કોડ જનરેટરની ગેરહાજરીમાં કોડ (લગભગ સમાન આંતરિક કામગીરી) ચલાવવો જોઈએ. વાસ્તવમાં, તેના દસ્તાવેજો જણાવે છે તેમ, આ દુભાષિયા હંમેશા JIT કોડ જનરેટર તરીકે સારી કામગીરી કરી શકતું નથી, માત્ર ગતિના સંદર્ભમાં જ નહીં, પણ ગુણાત્મક રીતે પણ. તેમ છતાં મને ખાતરી નથી કે તેનું વર્ણન સંપૂર્ણપણે સુસંગત છે.

શરૂઆતમાં મેં સંપૂર્ણ સુવિધાયુક્ત TCG બેકએન્ડ બનાવવાનો પ્રયાસ કર્યો, પરંતુ સોર્સ કોડ અને બાઇટકોડ સૂચનાઓનું સંપૂર્ણ સ્પષ્ટ વર્ણન ન હોવાથી ઝડપથી મૂંઝવણમાં પડી ગયો, તેથી મેં TCI દુભાષિયાને લપેટવાનું નક્કી કર્યું. આનાથી ઘણા ફાયદા થયા:

• કોડ જનરેટરને અમલમાં મૂકતી વખતે, તમે સૂચનાઓના વર્ણનને નહીં, પરંતુ દુભાષિયા કોડને જોઈ શકો છો
• તમે અનુભવેલા દરેક અનુવાદ બ્લોક માટે ફંક્શન્સ જનરેટ કરી શકતા નથી, પરંતુ, ઉદાહરણ તરીકે, સોમા અમલ પછી જ
• જો જનરેટ કરેલ કોડ બદલાય છે (અને આ શક્ય લાગે છે, શબ્દ પેચ ધરાવતા નામો સાથેના કાર્યોને આધારે), મારે જનરેટ કરેલ JS કોડને અમાન્ય કરવાની જરૂર પડશે, પરંતુ ઓછામાં ઓછું મારી પાસે તેને ફરીથી જનરેટ કરવા માટે કંઈક હશે.

ત્રીજા મુદ્દા વિશે, મને ખાતરી નથી કે કોડ પ્રથમ વખત એક્ઝિક્યુટ થયા પછી પેચિંગ શક્ય છે, પરંતુ પ્રથમ બે પોઈન્ટ પૂરતા છે.

શરૂઆતમાં, મૂળ બાઈટકોડ સૂચનાના સરનામા પર કોડ મોટા સ્વિચના રૂપમાં જનરેટ કરવામાં આવ્યો હતો, પરંતુ પછી, Emscripten, જનરેટેડ JSનું ઑપ્ટિમાઇઝેશન અને રિલૂપિંગ વિશેના લેખને યાદ રાખીને, મેં વધુ માનવ કોડ જનરેટ કરવાનું નક્કી કર્યું, ખાસ કરીને કારણ કે તે અનુભવાત્મક રીતે બહાર આવ્યું છે કે અનુવાદ બ્લોકમાં એકમાત્ર પ્રવેશ બિંદુ તેની શરૂઆત છે. જલદી કહ્યું કે થઈ ગયું, થોડા સમય પછી અમારી પાસે કોડ જનરેટર હતો જે ifs (લૂપ્સ વિના હોવા છતાં) સાથે કોડ જનરેટ કરે છે. પરંતુ દુર્ભાગ્ય, તે ક્રેશ થઈ ગયું, અને સંદેશ આપ્યો કે સૂચનાઓ કેટલીક ખોટી લંબાઈની હતી. વધુમાં, આ પુનરાવર્તિત સ્તર પર છેલ્લી સૂચના હતી brcond. ઠીક છે, હું પુનરાવર્તિત કૉલ પહેલાં અને પછી આ સૂચનાની જનરેશનમાં એક સરખો ચેક ઉમેરીશ અને... તેમાંથી એક પણ અમલમાં આવ્યો ન હતો, પરંતુ ભારપૂર્વક સ્વિચ કર્યા પછી પણ તેઓ નિષ્ફળ ગયા. અંતે, જનરેટ કરેલા કોડનો અભ્યાસ કર્યા પછી, મને સમજાયું કે સ્વીચ કર્યા પછી, વર્તમાન સૂચના તરફનો નિર્દેશક સ્ટેકમાંથી ફરીથી લોડ થાય છે અને કદાચ જનરેટ કરેલા JavaScript કોડ દ્વારા ઓવરરાઈટ થઈ જાય છે. અને તેથી તે બહાર આવ્યું. બફરને એક મેગાબાઇટથી દસ સુધી વધારવું કંઈપણ તરફ દોરી ગયું નહીં, અને તે સ્પષ્ટ થઈ ગયું કે કોડ જનરેટર વર્તુળોમાં ચાલી રહ્યું છે. અમારે તપાસ કરવાની હતી કે અમે વર્તમાન ટીબીની સીમાઓથી આગળ તો નથી ગયા, અને જો અમે તેમ કરીએ, તો પછીના ટીબીનું સરનામું માઈનસ ચિહ્ન સાથે જારી કરો જેથી અમે અમલ ચાલુ રાખી શકીએ. વધુમાં, આ સમસ્યાનું નિરાકરણ લાવે છે "જો બાઈટકોડનો આ ભાગ બદલાઈ ગયો હોય તો કયા જનરેટ કરેલા કાર્યોને અમાન્ય કરવા જોઈએ?" — માત્ર ફંક્શન કે જે આ અનુવાદ બ્લોકને અનુરૂપ છે તેને અમાન્ય કરવાની જરૂર છે. જો કે, મેં ક્રોમિયમમાં બધું ડીબગ કર્યું હોવા છતાં (હું ફાયરફોક્સનો ઉપયોગ કરું છું અને પ્રયોગો માટે અલગ બ્રાઉઝરનો ઉપયોગ કરવો મારા માટે સરળ છે), ફાયરફોક્સે મને 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"]

નિષ્કર્ષ

તેથી, કામ હજી પૂર્ણ થયું નથી, પરંતુ હું ગુપ્ત રીતે આ લાંબા ગાળાના બાંધકામને પૂર્ણતામાં લાવવાથી કંટાળી ગયો છું. તેથી, મેં હમણાં માટે મારી પાસે જે છે તે પ્રકાશિત કરવાનું નક્કી કર્યું. કોડ સ્થળોએ થોડો ડરામણો છે, કારણ કે આ એક પ્રયોગ છે, અને શું કરવાની જરૂર છે તે અગાઉથી સ્પષ્ટ નથી. સંભવતઃ, તે પછી ક્યુમુના કેટલાક વધુ આધુનિક સંસ્કરણની ટોચ પર સામાન્ય અણુ કમિટ્સ જારી કરવા યોગ્ય છે. આ દરમિયાન, ગીતામાં એક બ્લોગ ફોર્મેટમાં એક થ્રેડ છે: દરેક "સ્તર" માટે જે ઓછામાં ઓછું કોઈક રીતે પસાર થઈ ગયું છે, રશિયનમાં વિગતવાર ભાષ્ય ઉમેરવામાં આવ્યું છે. વાસ્તવમાં, આ લેખ મહદઅંશે નિષ્કર્ષની પુનઃસંગ્રહ છે git log.

તમે તે બધું અજમાવી શકો છો અહીં (ટ્રાફિકથી સાવધ રહો).

પહેલેથી શું કામ કરી રહ્યું છે:

• x86 વર્ચ્યુઅલ પ્રોસેસર ચાલી રહ્યું છે
• મશીન કોડથી JavaScript સુધી JIT કોડ જનરેટરનો વર્કિંગ પ્રોટોટાઇપ છે
• અન્ય 32-બીટ ગેસ્ટ આર્કિટેક્ચરને એસેમ્બલ કરવા માટે એક ટેમ્પલેટ છે: અત્યારે તમે લોડિંગ સ્ટેજ પર બ્રાઉઝરમાં MIPS આર્કિટેક્ચર ફ્રીઝિંગ માટે Linux ની પ્રશંસા કરી શકો છો.

તમે બીજું શું કરી શકો

• ઇમ્યુલેશનને વેગ આપો. JIT મોડમાં પણ તે વર્ચ્યુઅલ x86 કરતાં ધીમું ચાલે છે (પરંતુ સંભવતઃ ઘણા બધા ઇમ્યુલેટેડ હાર્ડવેર અને આર્કિટેક્ચર્સ સાથે સંપૂર્ણ Qemu છે)
• સામાન્ય ઈન્ટરફેસ બનાવવા માટે - સાચું કહું તો, હું સારો વેબ ડેવલપર નથી, તેથી હમણાં માટે મેં સ્ટાન્ડર્ડ Emscripten શેલને શક્ય તેટલું શ્રેષ્ઠ બનાવ્યું છે.
• વધુ જટિલ Qemu કાર્યો - નેટવર્કિંગ, VM સ્થળાંતર, વગેરે શરૂ કરવાનો પ્રયાસ કરો.
• યુપીડી: તમારે તમારા થોડા વિકાસ અને બગ રિપોર્ટ્સ Emscripten અપસ્ટ્રીમ પર સબમિટ કરવાની જરૂર પડશે, જેમ કે Qemu અને અન્ય પ્રોજેક્ટના અગાઉના પોર્ટર્સે કર્યું હતું. મારા કાર્યના ભાગ રૂપે Emscripten માં તેમના યોગદાનનો ગર્ભિત ઉપયોગ કરવામાં સક્ષમ થવા બદલ તેમનો આભાર.

સોર્સ: www.habr.com