ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ ਫੈਬਰਿਸ ਬੇਲਾਰਡ jslinux ਦੁਆਰਾ ਲਿਖਿਆ ਗਿਆ JavaScript ਵਿੱਚ ਲਿਖਿਆ ਇੱਕ PC ਈਮੂਲੇਟਰ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਘੱਟੋ-ਘੱਟ ਹੋਰ ਸੀ ਵਰਚੁਅਲ x86. ਪਰ ਉਹ ਸਾਰੇ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਨੂੰ ਪਤਾ ਹੈ, ਦੁਭਾਸ਼ੀਏ ਸਨ, ਜਦੋਂ ਕਿ ਕਿਮੂ, ਉਸੇ ਫੈਬਰਿਸ ਬੇਲਾਰਡ ਦੁਆਰਾ ਬਹੁਤ ਪਹਿਲਾਂ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ, ਸ਼ਾਇਦ, ਕੋਈ ਵੀ ਸਵੈ-ਮਾਣ ਵਾਲਾ ਆਧੁਨਿਕ ਇਮੂਲੇਟਰ, ਹੋਸਟ ਸਿਸਟਮ ਕੋਡ ਵਿੱਚ ਗੈਸਟ ਕੋਡ ਦੇ JIT ਸੰਕਲਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਸੀ ਕਿ ਬ੍ਰਾਉਜ਼ਰ ਦੁਆਰਾ ਹੱਲ ਕੀਤੇ ਗਏ ਇੱਕ ਦੇ ਸਬੰਧ ਵਿੱਚ ਉਲਟ ਕੰਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ: JavaScript ਵਿੱਚ ਮਸ਼ੀਨ ਕੋਡ ਦਾ JIT ਸੰਕਲਨ, ਜਿਸ ਲਈ ਇਹ ਕਿਮੂ ਪੋਰਟ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਤਰਕਪੂਰਨ ਜਾਪਦਾ ਸੀ। ਇਹ ਜਾਪਦਾ ਹੈ, ਕਿਉਂ ਕਿਮੂ, ਇੱਥੇ ਸਰਲ ਅਤੇ ਉਪਭੋਗਤਾ-ਅਨੁਕੂਲ ਇਮੂਲੇਟਰ ਹਨ - ਉਹੀ ਵਰਚੁਅਲ ਬਾਕਸ, ਉਦਾਹਰਨ ਲਈ - ਸਥਾਪਿਤ ਅਤੇ ਕੰਮ ਕਰਦਾ ਹੈ. ਪਰ ਕਿਮੂ ਦੀਆਂ ਕਈ ਦਿਲਚਸਪ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ

• ਓਪਨ ਸੋਰਸ
• ਕਰਨਲ ਡਰਾਈਵਰ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਦੀ ਯੋਗਤਾ
• ਦੁਭਾਸ਼ੀਏ ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰਨ ਦੀ ਯੋਗਤਾ
• ਹੋਸਟ ਅਤੇ ਗੈਸਟ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵੱਡੀ ਗਿਣਤੀ ਲਈ ਸਮਰਥਨ

ਤੀਜੇ ਬਿੰਦੂ ਦੇ ਸੰਬੰਧ ਵਿੱਚ, ਮੈਂ ਹੁਣ ਇਹ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ ਹਾਂ ਕਿ ਅਸਲ ਵਿੱਚ, ਟੀਸੀਆਈ ਮੋਡ ਵਿੱਚ, ਇਹ ਗੈਸਟ ਮਸ਼ੀਨ ਦੀਆਂ ਹਦਾਇਤਾਂ ਨਹੀਂ ਹਨ ਜੋ ਖੁਦ ਵਿਆਖਿਆ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਬਾਈਟਕੋਡ, ਪਰ ਇਹ ਤੱਤ ਨਹੀਂ ਬਦਲਦਾ - ਬਣਾਉਣ ਅਤੇ ਚਲਾਉਣ ਲਈ. ਇੱਕ ਨਵੇਂ ਆਰਕੀਟੈਕਚਰ 'ਤੇ Qemu, ਜੇਕਰ ਤੁਸੀਂ ਖੁਸ਼ਕਿਸਮਤ ਹੋ, ਤਾਂ A C ਕੰਪਾਈਲਰ ਕਾਫ਼ੀ ਹੈ - ਇੱਕ ਕੋਡ ਜਨਰੇਟਰ ਲਿਖਣਾ ਮੁਲਤਵੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਅਤੇ ਹੁਣ, ਮੇਰੇ ਖਾਲੀ ਸਮੇਂ ਵਿੱਚ ਕਿਮੂ ਸਰੋਤ ਕੋਡ ਨਾਲ ਦੋ ਸਾਲਾਂ ਦੇ ਆਰਾਮ ਨਾਲ ਟਿੰਕਰ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਪ੍ਰੋਟੋਟਾਈਪ ਪ੍ਰਗਟ ਹੋਇਆ, ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਚਲਾ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਕੋਲੀਬਰੀ OS.

Emscripten ਕੀ ਹੈ

ਅੱਜ ਕੱਲ੍ਹ, ਬਹੁਤ ਸਾਰੇ ਕੰਪਾਈਲਰ ਪ੍ਰਗਟ ਹੋਏ ਹਨ, ਜਿਸਦਾ ਅੰਤਮ ਨਤੀਜਾ JavaScript ਹੈ. ਕੁਝ, ਜਿਵੇਂ ਕਿ ਟਾਈਪ ਸਕ੍ਰਿਪਟ, ਅਸਲ ਵਿੱਚ ਵੈੱਬ ਲਈ ਲਿਖਣ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਹੋਣ ਦਾ ਇਰਾਦਾ ਸੀ। ਇਸ ਦੇ ਨਾਲ ਹੀ, Emscripten ਮੌਜੂਦਾ C ਜਾਂ C++ ਕੋਡ ਲੈਣ ਅਤੇ ਇਸਨੂੰ ਬ੍ਰਾਊਜ਼ਰ-ਪੜ੍ਹਨ ਯੋਗ ਰੂਪ ਵਿੱਚ ਕੰਪਾਇਲ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ। 'ਤੇ ਇਹ ਸਫ਼ਾ ਅਸੀਂ ਮਸ਼ਹੂਰ ਪ੍ਰੋਗਰਾਮਾਂ ਦੇ ਬਹੁਤ ਸਾਰੇ ਪੋਰਟ ਇਕੱਠੇ ਕੀਤੇ ਹਨ: ਇੱਥੇਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ PyPy ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ - ਤਰੀਕੇ ਨਾਲ, ਉਹ ਪਹਿਲਾਂ ਹੀ JIT ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ. ਵਾਸਤਵ ਵਿੱਚ, ਹਰ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਸਿਰਫ਼ ਕੰਪਾਇਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ - ਇੱਥੇ ਇੱਕ ਨੰਬਰ ਹਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਜਿਸ ਨੂੰ ਤੁਹਾਨੂੰ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ, ਹਾਲਾਂਕਿ, ਉਸੇ ਪੰਨੇ 'ਤੇ ਸ਼ਿਲਾਲੇਖ ਦੇ ਅਨੁਸਾਰ "ਐਮਸਕ੍ਰਿਪਟਨ ਨੂੰ ਲਗਭਗ ਕਿਸੇ ਵੀ ਕੰਪਾਇਲ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ. ਪੋਰਟੇਬਲ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਲਈ C/C++ ਕੋਡ। ਭਾਵ, ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਓਪਰੇਸ਼ਨ ਹਨ ਜੋ ਸਟੈਂਡਰਡ ਦੇ ਅਨੁਸਾਰ ਪਰਿਭਾਸ਼ਿਤ ਵਿਵਹਾਰ ਹਨ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ x86 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ - ਉਦਾਹਰਨ ਲਈ, ਵੇਰੀਏਬਲਾਂ ਲਈ ਅਣ-ਅਲਾਈਨ ਪਹੁੰਚ, ਜੋ ਕਿ ਕੁਝ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਮਨਾਹੀ ਹੈ। , Qemu ਇੱਕ ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਪ੍ਰੋਗਰਾਮ ਹੈ ਅਤੇ , ਮੈਂ ਵਿਸ਼ਵਾਸ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ, ਅਤੇ ਇਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪਰਿਭਾਸ਼ਿਤ ਵਿਵਹਾਰ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ - ਇਸਨੂੰ ਲਓ ਅਤੇ ਕੰਪਾਇਲ ਕਰੋ, ਫਿਰ JIT ਨਾਲ ਥੋੜਾ ਜਿਹਾ ਟਿੰਕਰ ਕਰੋ - ਅਤੇ ਤੁਸੀਂ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ! ਪਰ ਇਹ ਨਹੀਂ ਹੈ ਕੇਸ...

ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼

ਆਮ ਤੌਰ 'ਤੇ, ਮੈਂ ਪਹਿਲਾ ਵਿਅਕਤੀ ਨਹੀਂ ਹਾਂ ਜੋ ਕਿਮੂ ਨੂੰ ਜਾਵਾ ਸਕ੍ਰਿਪਟ 'ਤੇ ਪੋਰਟ ਕਰਨ ਦੇ ਵਿਚਾਰ ਨਾਲ ਆਇਆ ਹਾਂ. ReactOS ਫੋਰਮ 'ਤੇ ਇੱਕ ਸਵਾਲ ਪੁੱਛਿਆ ਗਿਆ ਸੀ ਕਿ ਕੀ ਇਹ Emscripten ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਭਵ ਸੀ। ਪਹਿਲਾਂ ਵੀ, ਅਫਵਾਹਾਂ ਸਨ ਕਿ ਫੈਬਰਿਸ ਬੇਲਾਰਡ ਨੇ ਇਹ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਕੀਤਾ ਸੀ, ਪਰ ਅਸੀਂ jslinux ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਸੀ, ਜੋ ਕਿ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਨੂੰ ਪਤਾ ਹੈ, JS ਵਿੱਚ ਹੱਥੀਂ ਕਾਫ਼ੀ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇੱਕ ਕੋਸ਼ਿਸ਼ ਹੈ, ਅਤੇ ਸਕ੍ਰੈਚ ਤੋਂ ਲਿਖਿਆ ਗਿਆ ਸੀ। ਬਾਅਦ ਵਿੱਚ, ਵਰਚੁਅਲ x86 ਲਿਖਿਆ ਗਿਆ ਸੀ - ਇਸਦੇ ਲਈ ਅਪ੍ਰਤੱਖ ਸਰੋਤ ਪੋਸਟ ਕੀਤੇ ਗਏ ਸਨ, ਅਤੇ, ਜਿਵੇਂ ਕਿਹਾ ਗਿਆ ਹੈ, ਇਮੂਲੇਸ਼ਨ ਦੇ ਵੱਡੇ "ਯਥਾਰਥਵਾਦ" ਨੇ SeaBIOS ਨੂੰ ਫਰਮਵੇਅਰ ਵਜੋਂ ਵਰਤਣਾ ਸੰਭਵ ਬਣਾਇਆ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਐਮਸਕ੍ਰਿਪਟਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਮੂ ਨੂੰ ਪੋਰਟ ਕਰਨ ਦੀ ਘੱਟੋ ਘੱਟ ਇੱਕ ਕੋਸ਼ਿਸ਼ ਸੀ - ਮੈਂ ਅਜਿਹਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਸਾਕਟ ਜੋੜਾ, ਪਰ ਵਿਕਾਸ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, ਜੰਮ ਗਿਆ ਸੀ।

ਇਸ ਲਈ, ਇਹ ਜਾਪਦਾ ਹੈ, ਇੱਥੇ ਸਰੋਤ ਹਨ, ਇੱਥੇ Emscripten ਹੈ - ਇਸਨੂੰ ਲਓ ਅਤੇ ਕੰਪਾਇਲ ਕਰੋ. ਪਰ ਅਜਿਹੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵੀ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਕਿਮੂ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਜਿਨ੍ਹਾਂ 'ਤੇ ਉਹ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ, ਆਦਿ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ libffi, ਕਿਸ glib 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ. ਇੰਟਰਨੈੱਟ 'ਤੇ ਅਫਵਾਹਾਂ ਸਨ ਕਿ ਐਮਸਕ੍ਰਿਪਟਨ ਲਈ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਪੋਰਟਾਂ ਦੇ ਵੱਡੇ ਸੰਗ੍ਰਹਿ ਵਿੱਚ ਇੱਕ ਸੀ, ਪਰ ਇਹ ਵਿਸ਼ਵਾਸ ਕਰਨਾ ਕਿਸੇ ਤਰ੍ਹਾਂ ਔਖਾ ਸੀ: ਪਹਿਲੀ ਗੱਲ, ਇਹ ਇੱਕ ਨਵਾਂ ਕੰਪਾਈਲਰ ਬਣਨ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਸੀ, ਦੂਜਾ, ਇਹ ਬਹੁਤ ਘੱਟ ਪੱਧਰ ਦਾ ਸੀ। ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਹੁਣੇ ਚੁੱਕਣ ਲਈ, ਅਤੇ JS ਨੂੰ ਕੰਪਾਇਲ ਕਰਨ ਲਈ. ਅਤੇ ਇਹ ਸਿਰਫ਼ ਅਸੈਂਬਲੀ ਇਨਸਰਟਸ ਦਾ ਮਾਮਲਾ ਨਹੀਂ ਹੈ - ਸ਼ਾਇਦ, ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਨੂੰ ਮੋੜਦੇ ਹੋ, ਤਾਂ ਕੁਝ ਕਾਲਿੰਗ ਸੰਮੇਲਨਾਂ ਲਈ ਤੁਸੀਂ ਸਟੈਕ 'ਤੇ ਜ਼ਰੂਰੀ ਆਰਗੂਮੈਂਟਸ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਤੋਂ ਬਿਨਾਂ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ Emscripten ਇੱਕ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ ਹੈ: ਤਿਆਰ ਕੀਤੇ ਕੋਡ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ JS ਇੰਜਨ ਔਪਟੀਮਾਈਜ਼ਰ ਨੂੰ ਜਾਣੂ ਦਿਖਣ ਲਈ, ਕੁਝ ਚਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਅਖੌਤੀ ਰੀਲੂਪਿੰਗ - ਕੁਝ ਐਬਸਟ੍ਰੈਕਟ ਪਰਿਵਰਤਨ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਨਾਲ ਪ੍ਰਾਪਤ ਹੋਏ LLVM IR ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਕੋਡ ਜਨਰੇਟਰ ਪ੍ਰਸ਼ੰਸਾਯੋਗ ifs, ਲੂਪਸ, ਆਦਿ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਖੈਰ, ਫੰਕਸ਼ਨ ਨੂੰ ਆਰਗੂਮੈਂਟਸ ਕਿਵੇਂ ਪਾਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ? ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਜੇਐਸ ਫੰਕਸ਼ਨਾਂ ਲਈ ਆਰਗੂਮੈਂਟ ਦੇ ਤੌਰ ਤੇ, ਜੋ ਕਿ, ਜੇ ਸੰਭਵ ਹੋਵੇ, ਸਟੈਕ ਦੁਆਰਾ ਨਹੀਂ।

ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਜੇਐਸ ਦੇ ਨਾਲ libffi ਲਈ ਇੱਕ ਬਦਲਾਵ ਲਿਖਣ ਅਤੇ ਸਟੈਂਡਰਡ ਟੈਸਟ ਚਲਾਉਣ ਦਾ ਇੱਕ ਵਿਚਾਰ ਸੀ, ਪਰ ਅੰਤ ਵਿੱਚ ਮੈਂ ਇਸ ਬਾਰੇ ਉਲਝਣ ਵਿੱਚ ਪੈ ਗਿਆ ਕਿ ਆਪਣੀਆਂ ਹੈਡਰ ਫਾਈਲਾਂ ਨੂੰ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਤਾਂ ਜੋ ਉਹ ਮੌਜੂਦਾ ਕੋਡ ਨਾਲ ਕੰਮ ਕਰਨ - ਮੈਂ ਕੀ ਕਰ ਸਕਦਾ ਹਾਂ, ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ, "ਕੀ ਕੰਮ ਇੰਨੇ ਗੁੰਝਲਦਾਰ ਹਨ "ਕੀ ਅਸੀਂ ਇੰਨੇ ਮੂਰਖ ਹਾਂ?" ਮੈਨੂੰ libffi ਨੂੰ ਕਿਸੇ ਹੋਰ ਆਰਕੀਟੈਕਚਰ ਲਈ ਪੋਰਟ ਕਰਨਾ ਪਿਆ, ਇਸ ਲਈ ਬੋਲਣ ਲਈ - ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, Emscripten ਕੋਲ ਇਨਲਾਈਨ ਅਸੈਂਬਲੀ ਲਈ ਦੋਵੇਂ ਮੈਕਰੋ ਹਨ (ਜਾਵਾਸਕ੍ਰਿਪਟ ਵਿੱਚ, ਹਾਂ - ਖੈਰ, ਜੋ ਵੀ ਆਰਕੀਟੈਕਚਰ, ਇਸ ਲਈ ਅਸੈਂਬਲਰ), ਅਤੇ ਫਲਾਈ 'ਤੇ ਤਿਆਰ ਕੋਡ ਨੂੰ ਚਲਾਉਣ ਦੀ ਯੋਗਤਾ। ਆਮ ਤੌਰ 'ਤੇ, ਕੁਝ ਸਮੇਂ ਲਈ ਪਲੇਟਫਾਰਮ-ਨਿਰਭਰ ਲਿਬਫੀ ਦੇ ਟੁਕੜਿਆਂ ਨਾਲ ਟਿੰਕਰ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ ਕੁਝ ਕੰਪਾਇਲ ਕਰਨ ਯੋਗ ਕੋਡ ਮਿਲਿਆ ਅਤੇ ਇਸ ਨੂੰ ਪਹਿਲੇ ਟੈਸਟ 'ਤੇ ਚਲਾਇਆ ਜੋ ਮੈਂ ਸਾਹਮਣੇ ਆਇਆ ਸੀ। ਮੇਰੇ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਟੈਸਟ ਸਫਲ ਰਿਹਾ। ਮੇਰੀ ਪ੍ਰਤਿਭਾ ਤੋਂ ਹੈਰਾਨ - ਕੋਈ ਮਜ਼ਾਕ ਨਹੀਂ, ਇਹ ਪਹਿਲੀ ਲਾਂਚ ਤੋਂ ਕੰਮ ਕਰਦਾ ਸੀ - ਮੈਂ, ਅਜੇ ਵੀ ਮੇਰੀਆਂ ਅੱਖਾਂ 'ਤੇ ਵਿਸ਼ਵਾਸ ਨਹੀਂ ਕਰ ਰਿਹਾ, ਨਤੀਜਾ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਵੇਖਣ ਗਿਆ, ਇਹ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਕਿ ਅੱਗੇ ਕਿੱਥੇ ਖੋਦਣਾ ਹੈ. ਇੱਥੇ ਮੈਂ ਦੂਜੀ ਵਾਰ ਬੇਹੋਸ਼ ਹੋ ਗਿਆ - ਮੇਰੇ ਫੰਕਸ਼ਨ ਨੇ ਸਿਰਫ ਉਹੀ ਕੰਮ ਕੀਤਾ ਸੀ ffi_call - ਇਸ ਨੇ ਇੱਕ ਸਫਲ ਕਾਲ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ। ਆਪ ਕੋਈ ਕਾਲ ਨਹੀਂ ਸੀ। ਇਸ ਲਈ ਮੈਂ ਆਪਣੀ ਪਹਿਲੀ ਪੁੱਲ ਬੇਨਤੀ ਭੇਜੀ, ਜਿਸ ਨੇ ਟੈਸਟ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਨੂੰ ਠੀਕ ਕੀਤਾ ਜੋ ਕਿਸੇ ਵੀ ਓਲੰਪੀਆਡ ਵਿਦਿਆਰਥੀ ਲਈ ਸਪੱਸ਼ਟ ਹੈ - ਅਸਲ ਨੰਬਰਾਂ ਦੀ ਤੁਲਨਾ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ a == b ਅਤੇ ਕਿਵੇਂ ਵੀ a - b < EPS - ਤੁਹਾਨੂੰ ਮੋਡੀਊਲ ਨੂੰ ਵੀ ਯਾਦ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ, ਨਹੀਂ ਤਾਂ 0 ਬਹੁਤ ਜ਼ਿਆਦਾ 1/3 ਦੇ ਬਰਾਬਰ ਹੋ ਜਾਵੇਗਾ... ਆਮ ਤੌਰ 'ਤੇ, ਮੈਂ libffi ਦੀ ਇੱਕ ਖਾਸ ਪੋਰਟ ਲੈ ਕੇ ਆਇਆ ਹਾਂ, ਜੋ ਸਭ ਤੋਂ ਸਰਲ ਟੈਸਟ ਪਾਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਿਸ ਨਾਲ glib ਹੈ ਸੰਕਲਿਤ - ਮੈਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਇਹ ਜ਼ਰੂਰੀ ਹੋਵੇਗਾ, ਮੈਂ ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਜੋੜਾਂਗਾ। ਅੱਗੇ ਦੇਖਦੇ ਹੋਏ, ਮੈਂ ਕਹਾਂਗਾ ਕਿ, ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, ਕੰਪਾਈਲਰ ਨੇ ਅੰਤਮ ਕੋਡ ਵਿੱਚ libffi ਫੰਕਸ਼ਨ ਨੂੰ ਵੀ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ।

ਪਰ, ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ, ਕੁਝ ਸੀਮਾਵਾਂ ਹਨ, ਅਤੇ ਵੱਖ-ਵੱਖ ਪਰਿਭਾਸ਼ਿਤ ਵਿਵਹਾਰ ਦੀ ਮੁਫਤ ਵਰਤੋਂ ਦੇ ਵਿਚਕਾਰ, ਇੱਕ ਹੋਰ ਕੋਝਾ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਲੁਕਾਇਆ ਗਿਆ ਹੈ - ਡਿਜ਼ਾਈਨ ਦੁਆਰਾ JavaScript ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ. ਸਿਧਾਂਤ ਵਿੱਚ, ਇਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਵੀ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਪੋਰਟਿੰਗ ਕੋਡ ਲਈ ਨਹੀਂ ਜਿਸਦਾ ਆਰਕੀਟੈਕਚਰ C ਥਰਿੱਡਾਂ ਨਾਲ ਬੰਨ੍ਹਿਆ ਹੋਇਆ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਫਾਇਰਫਾਕਸ ਸ਼ੇਅਰਡ ਵਰਕਰਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਪ੍ਰਯੋਗ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਐਮਸਕ੍ਰਿਪਟਨ ਨੇ ਉਹਨਾਂ ਲਈ ਇੱਕ pthread ਲਾਗੂ ਕੀਤਾ ਹੈ, ਪਰ ਮੈਂ ਇਸ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੁੰਦਾ ਸੀ। ਮੈਨੂੰ ਕਿਮੂ ਕੋਡ ਤੋਂ ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਰੂਟ ਆਊਟ ਕਰਨਾ ਪਿਆ - ਯਾਨੀ ਇਹ ਪਤਾ ਲਗਾਓ ਕਿ ਥਰਿੱਡ ਕਿੱਥੇ ਚੱਲ ਰਹੇ ਹਨ, ਇਸ ਥ੍ਰੈਡ ਵਿੱਚ ਚੱਲ ਰਹੇ ਲੂਪ ਦੇ ਸਰੀਰ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਫੰਕਸ਼ਨ ਵਿੱਚ ਮੂਵ ਕਰੋ, ਅਤੇ ਅਜਿਹੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਮੁੱਖ ਲੂਪ ਤੋਂ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਕਾਲ ਕਰੋ।

ਦੂਜੀ ਕੋਸ਼ਿਸ਼

ਕੁਝ ਬਿੰਦੂ 'ਤੇ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਸਮੱਸਿਆ ਅਜੇ ਵੀ ਉੱਥੇ ਸੀ, ਅਤੇ ਕੋਡ ਦੇ ਦੁਆਲੇ ਬੇਹੋਸ਼ੀ ਨਾਲ ਹਿਲਾਉਣ ਵਾਲੀਆਂ ਬੈਸਾਖੀਆਂ ਦਾ ਕੋਈ ਭਲਾ ਨਹੀਂ ਹੋਵੇਗਾ। ਸਿੱਟਾ: ਸਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਬੈਸਾਖੀਆਂ ਨੂੰ ਜੋੜਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਲਈ, ਸੰਸਕਰਣ 2.4.1, ਜੋ ਉਸ ਸਮੇਂ ਤਾਜ਼ਾ ਸੀ, ਲਿਆ ਗਿਆ ਸੀ (2.5.0 ਨਹੀਂ, ਕਿਉਂਕਿ, ਕੌਣ ਜਾਣਦਾ ਹੈ, ਨਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ ਅਜਿਹੇ ਬੱਗ ਹੋਣਗੇ ਜੋ ਅਜੇ ਤੱਕ ਫੜੇ ਨਹੀਂ ਗਏ ਹਨ, ਅਤੇ ਮੇਰੇ ਕੋਲ ਮੇਰੇ ਆਪਣੇ ਬੱਗ ਕਾਫ਼ੀ ਹਨ ), ਅਤੇ ਪਹਿਲੀ ਗੱਲ ਇਹ ਸੀ ਕਿ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਦੁਬਾਰਾ ਲਿਖਣਾ thread-posix.c. ਖੈਰ, ਇਹ ਸੁਰੱਖਿਅਤ ਹੈ: ਜੇ ਕਿਸੇ ਨੇ ਬਲੌਕ ਕਰਨ ਲਈ ਇੱਕ ਓਪਰੇਸ਼ਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਤਾਂ ਫੰਕਸ਼ਨ ਨੂੰ ਤੁਰੰਤ ਬੁਲਾਇਆ ਗਿਆ ਸੀ abort() - ਬੇਸ਼ੱਕ, ਇਸ ਨੇ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਹੱਲ ਨਹੀਂ ਕੀਤਾ, ਪਰ ਘੱਟੋ ਘੱਟ ਇਹ ਚੁੱਪਚਾਪ ਅਸੰਗਤ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਸੁਹਾਵਣਾ ਸੀ.

ਆਮ ਤੌਰ 'ਤੇ, ਐਮਸਕ੍ਰਿਪਟਨ ਵਿਕਲਪ JS ਨੂੰ ਕੋਡ ਪੋਰਟ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ -s ASSERTIONS=1 -s SAFE_HEAP=1 - ਉਹ ਕੁਝ ਕਿਸਮਾਂ ਦੇ ਪਰਿਭਾਸ਼ਿਤ ਵਿਵਹਾਰ ਨੂੰ ਫੜਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਅਲਾਈਨ ਪਤੇ 'ਤੇ ਕਾਲਾਂ (ਜੋ ਕਿ ਟਾਈਪ ਕੀਤੇ ਐਰੇ ਲਈ ਕੋਡ ਨਾਲ ਬਿਲਕੁਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਹੈ HEAP32[addr >> 2] = 1) ਜਾਂ ਆਰਗੂਮੈਂਟਾਂ ਦੀ ਗਲਤ ਸੰਖਿਆ ਦੇ ਨਾਲ ਇੱਕ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਨਾ।

ਤਰੀਕੇ ਨਾਲ, ਅਲਾਈਨਮੈਂਟ ਗਲਤੀਆਂ ਇੱਕ ਵੱਖਰਾ ਮੁੱਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ, Qemu ਕੋਲ ਕੋਡ ਜਨਰੇਸ਼ਨ TCI (ਛੋਟੇ ਕੋਡ ਇੰਟਰਪ੍ਰੇਟਰ) ਲਈ "ਡਿਜਨਰੇਟ" ਵਿਆਖਿਆਤਮਕ ਬੈਕਐਂਡ ਹੈ, ਅਤੇ ਇੱਕ ਨਵੇਂ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਕਿਮੂ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਚਲਾਉਣ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਖੁਸ਼ਕਿਸਮਤ ਹੋ, ਤਾਂ ਇੱਕ C ਕੰਪਾਈਲਰ ਕਾਫ਼ੀ ਹੈ। ਕੀਵਰਡ "ਜੇ ਤੁਸੀਂ ਖੁਸ਼ਕਿਸਮਤ ਹੋ". ਮੈਂ ਬਦਕਿਸਮਤ ਸੀ, ਅਤੇ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ TCI ਆਪਣੇ ਬਾਈਟਕੋਡ ਨੂੰ ਪਾਰਸ ਕਰਨ ਵੇਲੇ ਅਲਾਈਨ ਐਕਸੈਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਭਾਵ, ਹਰ ਤਰ੍ਹਾਂ ਦੇ ਏਆਰਐਮ ਅਤੇ ਹੋਰ ਢਾਂਚਿਆਂ 'ਤੇ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਪੱਧਰੀ ਪਹੁੰਚ ਦੇ ਨਾਲ, ਕਿਮੂ ਕੰਪਾਇਲ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਕੋਲ ਇੱਕ ਆਮ TCG ਬੈਕਐਂਡ ਹੈ ਜੋ ਨੇਟਿਵ ਕੋਡ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਪਰ ਕੀ TCI ਉਹਨਾਂ 'ਤੇ ਕੰਮ ਕਰੇਗਾ ਜਾਂ ਨਹੀਂ ਇਹ ਇੱਕ ਹੋਰ ਸਵਾਲ ਹੈ। ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, TCI ਦਸਤਾਵੇਜ਼ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕੁਝ ਅਜਿਹਾ ਹੀ ਸੰਕੇਤ ਕਰਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਅਣ-ਅਲਾਈਨ ਰੀਡਿੰਗ ਲਈ ਫੰਕਸ਼ਨ ਕਾਲਾਂ ਨੂੰ ਕੋਡ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਸੀ, ਜੋ ਕਿ ਕਿਮੂ ਦੇ ਇੱਕ ਹੋਰ ਹਿੱਸੇ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਸੀ।

ਢੇਰ ਤਬਾਹੀ

ਨਤੀਜੇ ਵਜੋਂ, TCI ਤੱਕ ਅਸੰਗਠਿਤ ਪਹੁੰਚ ਨੂੰ ਠੀਕ ਕੀਤਾ ਗਿਆ ਸੀ, ਇੱਕ ਮੁੱਖ ਲੂਪ ਬਣਾਇਆ ਗਿਆ ਸੀ ਜਿਸਨੂੰ ਬਦਲੇ ਵਿੱਚ ਪ੍ਰੋਸੈਸਰ, RCU ਅਤੇ ਕੁਝ ਹੋਰ ਛੋਟੀਆਂ ਚੀਜ਼ਾਂ ਕਿਹਾ ਜਾਂਦਾ ਸੀ। ਅਤੇ ਇਸ ਲਈ ਮੈਂ ਵਿਕਲਪ ਦੇ ਨਾਲ ਕਿਮੂ ਨੂੰ ਲਾਂਚ ਕਰਦਾ ਹਾਂ -d exec,in_asm,out_asm, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਕੋਡ ਦੇ ਕਿਹੜੇ ਬਲਾਕਾਂ ਨੂੰ ਚਲਾਇਆ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਪ੍ਰਸਾਰਣ ਦੇ ਸਮੇਂ ਇਹ ਵੀ ਲਿਖਣ ਲਈ ਕਿ ਗੈਸਟ ਕੋਡ ਕੀ ਸੀ, ਕੀ ਹੋਸਟ ਕੋਡ ਬਣ ਗਿਆ (ਇਸ ਕੇਸ ਵਿੱਚ, ਬਾਈਟਕੋਡ)। ਇਹ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਕਈ ਅਨੁਵਾਦ ਬਲਾਕਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ, ਡੀਬਗਿੰਗ ਸੁਨੇਹਾ ਲਿਖਦਾ ਹੈ ਜੋ ਮੈਂ ਛੱਡਿਆ ਸੀ ਕਿ RCU ਹੁਣ ਸ਼ੁਰੂ ਹੋਵੇਗਾ ਅਤੇ... ਕਰੈਸ਼ abort() ਇੱਕ ਫੰਕਸ਼ਨ ਦੇ ਅੰਦਰ free(). ਫੰਕਸ਼ਨ ਨਾਲ ਛੇੜਛਾੜ ਕਰਕੇ free() ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ ਕਿ ਹੀਪ ਬਲਾਕ ਦੇ ਸਿਰਲੇਖ ਵਿੱਚ, ਜੋ ਕਿ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਮੈਮੋਰੀ ਤੋਂ ਪਹਿਲਾਂ ਅੱਠ ਬਾਈਟਾਂ ਵਿੱਚ ਸਥਿਤ ਹੈ, ਬਲਾਕ ਦੇ ਆਕਾਰ ਜਾਂ ਕੁਝ ਸਮਾਨ ਦੀ ਬਜਾਏ, ਕੂੜਾ ਸੀ।

ਢੇਰ ਦਾ ਵਿਨਾਸ਼ - ਕਿੰਨਾ ਪਿਆਰਾ... ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਕ ਉਪਯੋਗੀ ਉਪਾਅ ਹੈ - (ਜੇ ਸੰਭਵ ਹੋਵੇ) ਉਸੇ ਸਰੋਤਾਂ ਤੋਂ, ਇੱਕ ਮੂਲ ਬਾਈਨਰੀ ਨੂੰ ਇਕੱਠਾ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਵਾਲਗ੍ਰਿੰਡ ਦੇ ਅਧੀਨ ਚਲਾਓ। ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਬਾਈਨਰੀ ਤਿਆਰ ਸੀ। ਮੈਂ ਇਸਨੂੰ ਉਸੇ ਵਿਕਲਪਾਂ ਨਾਲ ਲਾਂਚ ਕਰਦਾ ਹਾਂ - ਇਹ ਅਸਲ ਵਿੱਚ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ, ਸ਼ੁਰੂਆਤ ਦੇ ਦੌਰਾਨ ਵੀ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ. ਇਹ ਕੋਝਾ ਹੈ, ਬੇਸ਼ੱਕ - ਜ਼ਾਹਰ ਤੌਰ 'ਤੇ, ਸਰੋਤ ਬਿਲਕੁਲ ਇੱਕੋ ਜਿਹੇ ਨਹੀਂ ਸਨ, ਜੋ ਕਿ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਕੌਂਫਿਗਰ ਨੇ ਥੋੜੇ ਵੱਖਰੇ ਵਿਕਲਪਾਂ ਨੂੰ ਖੋਜਿਆ ਹੈ, ਪਰ ਮੇਰੇ ਕੋਲ ਵੈਲਗ੍ਰਿੰਡ ਹੈ - ਪਹਿਲਾਂ ਮੈਂ ਇਸ ਬੱਗ ਨੂੰ ਠੀਕ ਕਰਾਂਗਾ, ਅਤੇ ਫਿਰ, ਜੇ ਮੈਂ ਖੁਸ਼ਕਿਸਮਤ ਹਾਂ , ਅਸਲੀ ਦਿਖਾਈ ਦੇਵੇਗਾ। ਮੈਂ Valgrind ਦੇ ਅਧੀਨ ਉਹੀ ਚੀਜ਼ ਚਲਾ ਰਿਹਾ ਹਾਂ... Y-y-y, y-y-y, uh-uh, ਇਹ ਸ਼ੁਰੂ ਹੋਇਆ, ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂਆਤ ਤੋਂ ਲੰਘਿਆ ਅਤੇ ਗਲਤ ਮੈਮੋਰੀ ਪਹੁੰਚ ਬਾਰੇ ਇੱਕ ਵੀ ਚੇਤਾਵਨੀ ਦੇ ਬਿਨਾਂ ਮੂਲ ਬੱਗ ਨੂੰ ਪਿੱਛੇ ਛੱਡ ਦਿੱਤਾ, ਡਿੱਗਣ ਦਾ ਜ਼ਿਕਰ ਨਾ ਕਰਨਾ। ਜੀਵਨ, ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ, ਨੇ ਮੈਨੂੰ ਇਸ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕੀਤਾ - ਇੱਕ ਕਰੈਸ਼ਿੰਗ ਪ੍ਰੋਗਰਾਮ ਜਦੋਂ ਵਾਲਗ੍ਰਿੰਡ ਦੇ ਅਧੀਨ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਤਾਂ ਕਰੈਸ਼ ਹੋਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਕੀ ਸੀ ਇੱਕ ਰਹੱਸ ਹੈ। ਮੇਰੀ ਪਰਿਕਲਪਨਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਸ਼ੁਰੂਆਤ ਦੇ ਦੌਰਾਨ ਇੱਕ ਕਰੈਸ਼ ਤੋਂ ਬਾਅਦ ਮੌਜੂਦਾ ਨਿਰਦੇਸ਼ ਦੇ ਨੇੜੇ-ਤੇੜੇ, 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, ਪਰ ਬੇਸ਼ੱਕ ਇਹ ਪੰਨੇ 'ਤੇ ਇਕਸਾਰ ਨਹੀਂ ਹੁੰਦਾ। ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਬੱਗ ਜਿਸ ਨੇ ਮੈਨੂੰ ਕੁਝ ਮਹੀਨਿਆਂ ਲਈ ਨਿਰਾਸ਼ ਕੀਤਾ ਸੀ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਦੁਆਰਾ ਠੀਕ ਕੀਤਾ ਗਿਆ ਸੀ двух ਲਾਈਨਾਂ

ਕਾਲਿੰਗ ਫੰਕਸ਼ਨਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਅਤੇ ਹੁਣ ਪ੍ਰੋਸੈਸਰ ਕੁਝ ਗਿਣ ਰਿਹਾ ਹੈ, ਕਿਮੂ ਕ੍ਰੈਸ਼ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਸਕ੍ਰੀਨ ਚਾਲੂ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਪ੍ਰੋਸੈਸਰ ਤੇਜ਼ੀ ਨਾਲ ਲੂਪ ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਆਉਟਪੁੱਟ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦਾ ਹੈ -d exec,in_asm,out_asm. ਇੱਕ ਪਰਿਕਲਪਨਾ ਸਾਹਮਣੇ ਆਈ ਹੈ: ਟਾਈਮਰ ਰੁਕਾਵਟਾਂ (ਜਾਂ, ਆਮ ਤੌਰ 'ਤੇ, ਸਾਰੇ ਰੁਕਾਵਟਾਂ) ਨਹੀਂ ਪਹੁੰਚਦੀਆਂ। ਅਤੇ ਵਾਸਤਵ ਵਿੱਚ, ਜੇ ਤੁਸੀਂ ਮੂਲ ਅਸੈਂਬਲੀ ਤੋਂ ਰੁਕਾਵਟਾਂ ਨੂੰ ਖੋਲ੍ਹਦੇ ਹੋ, ਜੋ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਸਮਾਨ ਤਸਵੀਰ ਮਿਲਦੀ ਹੈ. ਪਰ ਇਹ ਬਿਲਕੁਲ ਜਵਾਬ ਨਹੀਂ ਸੀ: ਉਪਰੋਕਤ ਵਿਕਲਪ ਦੇ ਨਾਲ ਜਾਰੀ ਕੀਤੇ ਟਰੇਸ ਦੀ ਤੁਲਨਾ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟ੍ਰੈਜੈਕਟਰੀਜ਼ ਬਹੁਤ ਜਲਦੀ ਵੱਖ ਹੋ ਗਏ ਸਨ। ਇੱਥੇ ਇਹ ਕਿਹਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਲਾਂਚਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰਿਕਾਰਡ ਕੀਤੇ ਗਏ ਦੀ ਤੁਲਨਾ emrun ਮੂਲ ਅਸੈਂਬਲੀ ਦੇ ਆਉਟਪੁੱਟ ਨਾਲ ਡੀਬੱਗਿੰਗ ਆਉਟਪੁੱਟ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਕੈਨੀਕਲ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਹੈ। ਮੈਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਪਤਾ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਕਿਵੇਂ ਜੁੜਦਾ ਹੈ emrun, ਪਰ ਆਉਟਪੁੱਟ ਵਿੱਚ ਕੁਝ ਲਾਈਨਾਂ ਮੁੜ ਵਿਵਸਥਿਤ ਹੋਣ ਲਈ ਨਿਕਲਦੀਆਂ ਹਨ, ਇਸਲਈ ਡਿਫ ਵਿੱਚ ਅੰਤਰ ਅਜੇ ਇਹ ਮੰਨਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੈ ਕਿ ਟ੍ਰੈਜੈਕਟਰੀਆਂ ਵੱਖ ਹੋ ਗਈਆਂ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਨਿਰਦੇਸ਼ਾਂ ਅਨੁਸਾਰ ljmpl ਵੱਖ-ਵੱਖ ਪਤਿਆਂ 'ਤੇ ਇੱਕ ਤਬਦੀਲੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਬਾਈਟਕੋਡ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਵਿੱਚ ਸਹਾਇਕ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਇੱਕ ਹਦਾਇਤ ਹੁੰਦੀ ਹੈ, ਦੂਜੇ ਵਿੱਚ ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ। ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਗੂਗਲ ਕਰਨ ਅਤੇ ਕੋਡ ਦਾ ਅਧਿਐਨ ਕਰਨ ਤੋਂ ਬਾਅਦ ਜੋ ਇਹਨਾਂ ਹਦਾਇਤਾਂ ਦਾ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਰਜਿਸਟਰ ਵਿੱਚ ਇਸ ਤੋਂ ਤੁਰੰਤ ਪਹਿਲਾਂ cr0 ਇੱਕ ਰਿਕਾਰਡਿੰਗ ਕੀਤੀ ਗਈ ਸੀ - ਇੱਕ ਸਹਾਇਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ - ਜਿਸ ਨੇ ਪ੍ਰੋਸੈਸਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਮੋਡ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ, ਅਤੇ ਦੂਜਾ, ਇਹ ਕਿ js ਸੰਸਕਰਣ ਕਦੇ ਵੀ ਸੁਰੱਖਿਅਤ ਮੋਡ ਵਿੱਚ ਨਹੀਂ ਬਦਲਿਆ। ਪਰ ਤੱਥ ਇਹ ਹੈ ਕਿ ਐਮਸਕ੍ਰਿਪਟਨ ਦੀ ਇਕ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾ ਕੋਡ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰਨ ਲਈ ਇਸਦੀ ਝਿਜਕ ਹੈ ਜਿਵੇਂ ਕਿ ਹਦਾਇਤਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ call TCI ਵਿੱਚ, ਜੋ ਕਿਸੇ ਵੀ ਫੰਕਸ਼ਨ ਪੁਆਇੰਟਰ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਟਾਈਪ ਹੁੰਦਾ ਹੈ long long f(int arg0, .. int arg9) - ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਆਰਗੂਮੈਂਟਾਂ ਦੀ ਸਹੀ ਸੰਖਿਆ ਨਾਲ ਬੁਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਇਸ ਨਿਯਮ ਦੀ ਉਲੰਘਣਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਡੀਬੱਗਿੰਗ ਸੈਟਿੰਗਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਪ੍ਰੋਗਰਾਮ ਜਾਂ ਤਾਂ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਵੇਗਾ (ਜੋ ਕਿ ਚੰਗਾ ਹੈ) ਜਾਂ ਗਲਤ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ (ਜੋ ਡੀਬੱਗ ਕਰਨ ਲਈ ਉਦਾਸ ਹੋਵੇਗਾ)। ਇੱਕ ਤੀਜਾ ਵਿਕਲਪ ਵੀ ਹੈ - ਰੈਪਰਾਂ ਦੀ ਪੀੜ੍ਹੀ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ ਜੋ ਆਰਗੂਮੈਂਟਾਂ ਨੂੰ ਜੋੜਦੇ/ਹਟਾਉਂਦੇ ਹਨ, ਪਰ ਕੁੱਲ ਮਿਲਾ ਕੇ ਇਹ ਰੈਪਰ ਬਹੁਤ ਸਾਰੀ ਥਾਂ ਲੈਂਦੇ ਹਨ, ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਅਸਲ ਵਿੱਚ ਮੈਨੂੰ ਸਿਰਫ ਸੌ ਤੋਂ ਵੱਧ ਰੈਪਰਾਂ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਇਕੱਲਾ ਬਹੁਤ ਦੁਖਦਾਈ ਹੈ, ਪਰ ਇੱਥੇ ਇੱਕ ਹੋਰ ਗੰਭੀਰ ਸਮੱਸਿਆ ਨਿਕਲੀ: ਰੈਪਰ ਫੰਕਸ਼ਨਾਂ ਦੇ ਤਿਆਰ ਕੀਤੇ ਕੋਡ ਵਿੱਚ, ਆਰਗੂਮੈਂਟਾਂ ਨੂੰ ਬਦਲਿਆ ਅਤੇ ਬਦਲਿਆ ਗਿਆ, ਪਰ ਕਈ ਵਾਰ ਤਿਆਰ ਕੀਤੇ ਆਰਗੂਮੈਂਟਾਂ ਵਾਲੇ ਫੰਕਸ਼ਨ ਨੂੰ ਨਹੀਂ ਕਿਹਾ ਜਾਂਦਾ ਸੀ - ਠੀਕ ਹੈ, ਜਿਵੇਂ ਕਿ ਵਿੱਚ ਮੇਰੀ libffi ਲਾਗੂਕਰਨ. ਭਾਵ, ਕੁਝ ਸਹਾਇਕਾਂ ਨੂੰ ਸਿਰਫ਼ ਚਲਾਇਆ ਨਹੀਂ ਗਿਆ ਸੀ.

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਕਿਮੂ ਕੋਲ ਹੈਡਰ ਫਾਈਲ ਦੇ ਰੂਪ ਵਿੱਚ ਮਦਦਗਾਰਾਂ ਦੀਆਂ ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ ਸੂਚੀਆਂ ਹਨ

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, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਲੀਨਕਸ ਨੂੰ ਬੂਟ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ, ਉਦਾਹਰਨ ਲਈ, memtest86+, ਬਲਾਕ ਜੰਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ। ਪਰ ਇੱਥੇ ਸਮੱਸਿਆ ਹੈ: ਮੂਲ ਅਸੈਂਬਲੀ ਵਿੱਚ ਤੁਸੀਂ ਵਿਕਲਪ ਦੇ ਨਾਲ ਕੰਸੋਲ ਵਿੱਚ ਲੀਨਕਸ ਕਰਨਲ ਆਉਟਪੁੱਟ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ -nographic, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਟਰਮੀਨਲ ਤੱਕ ਕੋਈ ਆਉਟਪੁੱਟ ਨਹੀਂ ਜਿੱਥੋਂ ਇਸਨੂੰ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ emrun, ਨਹੀਂ ਆਇਆ। ਭਾਵ, ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ: ਪ੍ਰੋਸੈਸਰ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਗ੍ਰਾਫਿਕਸ ਆਉਟਪੁੱਟ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ। ਅਤੇ ਫਿਰ ਇਹ ਮੇਰੇ ਲਈ ਥੋੜਾ ਇੰਤਜ਼ਾਰ ਕਰਨ ਲਈ ਆਇਆ. ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ "ਪ੍ਰੋਸੈਸਰ ਸੌਂ ਨਹੀਂ ਰਿਹਾ ਹੈ, ਪਰ ਬਸ ਹੌਲੀ-ਹੌਲੀ ਝਪਕ ਰਿਹਾ ਹੈ," ਅਤੇ ਲਗਭਗ ਪੰਜ ਮਿੰਟਾਂ ਬਾਅਦ ਕਰਨਲ ਨੇ ਸੰਦੇਸ਼ਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਕੰਸੋਲ ਉੱਤੇ ਸੁੱਟ ਦਿੱਤਾ ਅਤੇ ਲਟਕਣਾ ਜਾਰੀ ਰੱਖਿਆ। ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਪ੍ਰੋਸੈਸਰ, ਆਮ ਤੌਰ 'ਤੇ, ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਾਨੂੰ SDL2 ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਕੋਡ ਵਿੱਚ ਖੋਦਣ ਦੀ ਲੋੜ ਹੈ. ਬਦਕਿਸਮਤੀ ਨਾਲ, ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਸ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ, ਇਸਲਈ ਕੁਝ ਥਾਵਾਂ 'ਤੇ ਮੈਨੂੰ ਬੇਤਰਤੀਬੇ ਕੰਮ ਕਰਨਾ ਪਿਆ। ਕਿਸੇ ਸਮੇਂ, ਲਾਈਨ parallel0 ਇੱਕ ਨੀਲੇ ਬੈਕਗ੍ਰਾਉਂਡ 'ਤੇ ਸਕ੍ਰੀਨ 'ਤੇ ਫਲੈਸ਼ ਹੋਈ, ਜਿਸ ਨੇ ਕੁਝ ਵਿਚਾਰ ਸੁਝਾਏ। ਅੰਤ ਵਿੱਚ, ਇਹ ਸਾਹਮਣੇ ਆਇਆ ਕਿ ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਕਿਮੂ ਇੱਕ ਭੌਤਿਕ ਵਿੰਡੋ ਵਿੱਚ ਕਈ ਵਰਚੁਅਲ ਵਿੰਡੋਜ਼ ਖੋਲ੍ਹਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ Ctrl-Alt-n ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਦਲ ਸਕਦੇ ਹੋ: ਇਹ ਨੇਟਿਵ ਬਿਲਡ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ Emscripten ਵਿੱਚ ਨਹੀਂ। ਵਿਕਲਪਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬੇਲੋੜੀ ਵਿੰਡੋਜ਼ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਤੋਂ ਬਾਅਦ -monitor none -parallel none -serial none ਅਤੇ ਹਰੇਕ ਫ੍ਰੇਮ 'ਤੇ ਪੂਰੀ ਸਕ੍ਰੀਨ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਨਾਲ ਦੁਬਾਰਾ ਖਿੱਚਣ ਦੀਆਂ ਹਦਾਇਤਾਂ, ਸਭ ਕੁਝ ਅਚਾਨਕ ਕੰਮ ਕਰਦਾ ਹੈ।

ਕੋਰੋਟੀਨ

ਇਸ ਲਈ, ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਇਮੂਲੇਸ਼ਨ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਇਸ ਵਿੱਚ ਕੋਈ ਵੀ ਦਿਲਚਸਪ ਸਿੰਗਲ-ਫਲਾਪੀ ਨਹੀਂ ਚਲਾ ਸਕਦੇ, ਕਿਉਂਕਿ ਇੱਥੇ ਕੋਈ ਬਲਾਕ I/O ਨਹੀਂ ਹੈ - ਤੁਹਾਨੂੰ ਕੋਰਟੀਨ ਲਈ ਸਮਰਥਨ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਕਿਮੂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕਈ ਕੋਰਟੀਨ ਬੈਕਐਂਡ ਹਨ, ਪਰ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਅਤੇ ਐਮਸਕ੍ਰਿਪਟਨ ਕੋਡ ਜਨਰੇਟਰ ਦੀ ਪ੍ਰਕਿਰਤੀ ਦੇ ਕਾਰਨ, ਤੁਸੀਂ ਸਟੈਕ ਨੂੰ ਜੁਗਲ ਕਰਨਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਲਗਦਾ ਹੈ ਕਿ "ਸਭ ਕੁਝ ਖਤਮ ਹੋ ਗਿਆ ਹੈ, ਪਲਾਸਟਰ ਹਟਾਇਆ ਜਾ ਰਿਹਾ ਹੈ," ਪਰ ਐਮਸਕ੍ਰਿਪਟਨ ਡਿਵੈਲਪਰਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਹਰ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਿਆ ਹੈ. ਇਹ ਕਾਫ਼ੀ ਮਜ਼ਾਕੀਆ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ: ਆਓ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਸ਼ੱਕੀ ਫੰਕਸ਼ਨ ਕਾਲ ਕਰੀਏ emscripten_sleep ਅਤੇ ਕਈ ਹੋਰ Asyncify ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਨਾਲ ਹੀ ਪੁਆਇੰਟਰ ਕਾਲਾਂ ਅਤੇ ਕਿਸੇ ਵੀ ਫੰਕਸ਼ਨ ਲਈ ਕਾਲਾਂ ਜਿੱਥੇ ਪਿਛਲੇ ਦੋ ਮਾਮਲਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਸਟੈਕ ਦੇ ਹੇਠਾਂ ਹੋ ਸਕਦਾ ਹੈ। ਅਤੇ ਹੁਣ, ਹਰ ਇੱਕ ਸ਼ੱਕੀ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਇੱਕ ਅਸਿੰਕ ਸੰਦਰਭ ਚੁਣਾਂਗੇ, ਅਤੇ ਕਾਲ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ, ਅਸੀਂ ਜਾਂਚ ਕਰਾਂਗੇ ਕਿ ਕੀ ਇੱਕ ਅਸਿੰਕਰੋਨਸ ਕਾਲ ਆਈ ਹੈ, ਅਤੇ ਜੇਕਰ ਇਹ ਹੈ, ਤਾਂ ਅਸੀਂ ਸਾਰੇ ਸਥਾਨਕ ਵੇਰੀਏਬਲਾਂ ਨੂੰ ਇਸ ਅਸਿੰਕ ਸੰਦਰਭ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਾਂਗੇ, ਇਹ ਦਰਸਾਏਗਾ ਕਿ ਕਿਹੜਾ ਫੰਕਸ਼ਨ ਕੰਟਰੋਲ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਲਈ ਜਦੋਂ ਸਾਨੂੰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਜਾਰੀ ਰੱਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਮੌਜੂਦਾ ਫੰਕਸ਼ਨ ਤੋਂ ਬਾਹਰ ਨਿਕਲਦੇ ਹਾਂ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਪ੍ਰਭਾਵ ਦਾ ਅਧਿਐਨ ਕਰਨ ਦੀ ਗੁੰਜਾਇਸ਼ ਹੈ ਬਰਬਾਦੀ - ਇੱਕ ਅਸਿੰਕਰੋਨਸ ਕਾਲ ਤੋਂ ਵਾਪਸ ਆਉਣ ਤੋਂ ਬਾਅਦ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਦੀਆਂ ਲੋੜਾਂ ਲਈ, ਕੰਪਾਈਲਰ ਇੱਕ ਸ਼ੱਕੀ ਕਾਲ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਫੰਕਸ਼ਨ ਦੇ "ਸਟੱਬਸ" ਬਣਾਉਂਦਾ ਹੈ — ਜਿਵੇਂ ਕਿ: ਜੇਕਰ n ਸ਼ੱਕੀ ਕਾਲਾਂ ਹਨ, ਤਾਂ ਫੰਕਸ਼ਨ ਨੂੰ n/2 ਵਿੱਚ ਫੈਲਾਇਆ ਜਾਵੇਗਾ। ਵਾਰ — ਇਹ ਅਜੇ ਵੀ ਹੈ, ਜੇਕਰ ਨਹੀਂ ਤਾਂ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ ਕਿ ਹਰੇਕ ਸੰਭਾਵੀ ਅਸਿੰਕਰੋਨਸ ਕਾਲ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਮੂਲ ਫੰਕਸ਼ਨ ਵਿੱਚ ਕੁਝ ਲੋਕਲ ਵੇਰੀਏਬਲ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ ਪਾਈਥਨ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਸਕ੍ਰਿਪਟ ਵੀ ਲਿਖਣੀ ਪਈ, ਜੋ ਕਿ ਖਾਸ ਤੌਰ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਰਤੇ ਗਏ ਫੰਕਸ਼ਨਾਂ ਦੇ ਇੱਕ ਦਿੱਤੇ ਸੈੱਟ ਦੇ ਅਧਾਰ 'ਤੇ ਜੋ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ "ਅਸਿੰਕ੍ਰੋਨੀ ਨੂੰ ਆਪਣੇ ਆਪ ਵਿੱਚੋਂ ਲੰਘਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ" (ਅਰਥਾਤ, ਸਟੈਕ ਪ੍ਰੋਮੋਸ਼ਨ ਅਤੇ ਉਹ ਸਭ ਕੁਝ ਜੋ ਮੈਂ ਹੁਣੇ ਵਰਣਨ ਕੀਤਾ ਹੈ, ਨਹੀਂ ਹੈ। ਉਹਨਾਂ ਵਿੱਚ ਕੰਮ), ਪੁਆਇੰਟਰਾਂ ਦੁਆਰਾ ਕਾਲਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਕੰਪਾਈਲਰ ਦੁਆਰਾ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਅਣਡਿੱਠ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹਨਾਂ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਅਸਿੰਕ੍ਰੋਨਸ ਨਾ ਮੰਨਿਆ ਜਾਵੇ। ਅਤੇ ਫਿਰ 60 MB ਤੋਂ ਘੱਟ JS ਫਾਈਲਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਨ - ਆਓ ਘੱਟੋ-ਘੱਟ 30 ਕਹੀਏ. ਹਾਲਾਂਕਿ, ਇੱਕ ਵਾਰ ਜਦੋਂ ਮੈਂ ਅਸੈਂਬਲੀ ਸਕ੍ਰਿਪਟ ਸਥਾਪਤ ਕਰ ਰਿਹਾ ਸੀ, ਅਤੇ ਅਚਾਨਕ ਲਿੰਕਰ ਵਿਕਲਪਾਂ ਨੂੰ ਬਾਹਰ ਸੁੱਟ ਦਿੱਤਾ, ਜਿਸ ਵਿੱਚ ਸੀ. -O3. ਮੈਂ ਤਿਆਰ ਕੀਤਾ ਕੋਡ ਚਲਾਉਂਦਾ ਹਾਂ, ਅਤੇ Chromium ਮੈਮੋਰੀ ਨੂੰ ਖਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ। ਮੈਂ ਫਿਰ ਗਲਤੀ ਨਾਲ ਦੇਖਿਆ ਕਿ ਉਹ ਕੀ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ... ਖੈਰ, ਮੈਂ ਕੀ ਕਹਿ ਸਕਦਾ ਹਾਂ, ਜੇ ਮੈਨੂੰ 500+ MB ਜਾਵਾਸਕ੍ਰਿਪਟ ਨੂੰ ਸੋਚ-ਸਮਝ ਕੇ ਅਧਿਐਨ ਕਰਨ ਅਤੇ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਕਿਹਾ ਗਿਆ ਹੁੰਦਾ ਤਾਂ ਮੈਂ ਵੀ ਫ੍ਰੀਜ਼ ਹੋ ਜਾਂਦਾ।

ਬਦਕਿਸਮਤੀ ਨਾਲ, Asyncify ਸਮਰਥਨ ਲਾਇਬ੍ਰੇਰੀ ਕੋਡ ਵਿੱਚ ਚੈਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਦੋਸਤਾਨਾ ਨਹੀਂ ਸਨ longjmp-s ਜੋ ਵਰਚੁਅਲ ਪ੍ਰੋਸੈਸਰ ਕੋਡ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਇੱਕ ਛੋਟੇ ਪੈਚ ਤੋਂ ਬਾਅਦ ਜੋ ਇਹਨਾਂ ਜਾਂਚਾਂ ਨੂੰ ਅਯੋਗ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸੰਦਰਭਾਂ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਰੀਸਟੋਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਸਭ ਕੁਝ ਠੀਕ ਸੀ, ਕੋਡ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਤੇ ਫਿਰ ਇੱਕ ਅਜੀਬ ਚੀਜ਼ ਸ਼ੁਰੂ ਹੋਈ: ਕਈ ਵਾਰ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਕੋਡ ਵਿੱਚ ਜਾਂਚ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਸੀ - ਉਹੀ ਜੋ ਕੋਡ ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰਦੇ ਹਨ ਜੇਕਰ, ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਤਰਕ ਦੇ ਅਨੁਸਾਰ, ਇਸਨੂੰ ਬਲੌਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ - ਕਿਸੇ ਨੇ ਪਹਿਲਾਂ ਹੀ ਕੈਪਚਰ ਕੀਤੇ ਮਿਊਟੇਕਸ ਨੂੰ ਫੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ. ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਸੀਰੀਅਲਾਈਜ਼ਡ ਕੋਡ ਵਿੱਚ ਇੱਕ ਤਰਕਪੂਰਨ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ - ਮੈਂ ਸਿਰਫ਼ Emscripten ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਸਟੈਂਡਰਡ ਮੁੱਖ ਲੂਪ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਸੀ, ਪਰ ਕਈ ਵਾਰ ਅਸਿੰਕਰੋਨਸ ਕਾਲ ਸਟੈਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖੋਲ੍ਹ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਉਸ ਸਮੇਂ ਇਹ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ। setTimeout ਮੁੱਖ ਲੂਪ ਤੋਂ - ਇਸ ਤਰ੍ਹਾਂ, ਕੋਡ ਪਿਛਲੀ ਦੁਹਰਾਅ ਨੂੰ ਛੱਡੇ ਬਿਨਾਂ ਮੁੱਖ ਲੂਪ ਦੁਹਰਾਅ ਵਿੱਚ ਦਾਖਲ ਹੋਇਆ। ਇੱਕ ਅਨੰਤ ਲੂਪ 'ਤੇ ਮੁੜ ਲਿਖਿਆ ਅਤੇ emscripten_sleep, ਅਤੇ mutexes ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਬੰਦ ਹੋ ਗਈਆਂ। ਕੋਡ ਹੋਰ ਵੀ ਲਾਜ਼ੀਕਲ ਬਣ ਗਿਆ ਹੈ - ਆਖਰਕਾਰ, ਅਸਲ ਵਿੱਚ, ਮੇਰੇ ਕੋਲ ਕੁਝ ਕੋਡ ਨਹੀਂ ਹੈ ਜੋ ਅਗਲੇ ਐਨੀਮੇਸ਼ਨ ਫਰੇਮ ਨੂੰ ਤਿਆਰ ਕਰਦਾ ਹੈ - ਪ੍ਰੋਸੈਸਰ ਸਿਰਫ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਸਕ੍ਰੀਨ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਅਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਸਮੱਸਿਆਵਾਂ ਇੱਥੇ ਨਹੀਂ ਰੁਕੀਆਂ: ਕਈ ਵਾਰ ਕਿਮੂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਬਿਨਾਂ ਕਿਸੇ ਅਪਵਾਦ ਜਾਂ ਗਲਤੀਆਂ ਦੇ ਚੁੱਪਚਾਪ ਸਮਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਸ ਪਲ 'ਤੇ ਮੈਂ ਇਸ ਨੂੰ ਛੱਡ ਦਿੱਤਾ, ਪਰ, ਅੱਗੇ ਦੇਖਦੇ ਹੋਏ, ਮੈਂ ਕਹਾਂਗਾ ਕਿ ਸਮੱਸਿਆ ਇਹ ਸੀ: ਕੋਰਟੀਨ ਕੋਡ, ਅਸਲ ਵਿੱਚ, ਵਰਤਦਾ ਨਹੀਂ ਹੈ setTimeout (ਜਾਂ ਘੱਟੋ ਘੱਟ ਓਨੀ ਵਾਰ ਨਹੀਂ ਜਿੰਨੀ ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ): ਫੰਕਸ਼ਨ emscripten_yield ਬਸ ਅਸਿੰਕ੍ਰੋਨਸ ਕਾਲ ਫਲੈਗ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਸਾਰੀ ਗੱਲ ਇਹ ਹੈ ਕਿ emscripten_coroutine_next ਇੱਕ ਅਸਿੰਕਰੋਨਸ ਫੰਕਸ਼ਨ ਨਹੀਂ ਹੈ: ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਇਹ ਫਲੈਗ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ ਰੀਸੈਟ ਕਰਦਾ ਹੈ ਅਤੇ ਨਿਯੰਤਰਣ ਨੂੰ ਜਿੱਥੇ ਇਸਦੀ ਲੋੜ ਹੈ ਉੱਥੇ ਤਬਦੀਲ ਕਰਦਾ ਹੈ। ਯਾਨੀ ਸਟੈਕ ਦਾ ਪ੍ਰਚਾਰ ਉੱਥੇ ਹੀ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਵਰਤੋਂ-ਬਾਅਦ-ਮੁਕਤ ਦੇ ਕਾਰਨ, ਜੋ ਕਿ ਉਦੋਂ ਪ੍ਰਗਟ ਹੋਇਆ ਜਦੋਂ ਕੋਰੋਟੀਨ ਪੂਲ ਨੂੰ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਅਸਮਰੱਥ ਬਣਾਇਆ ਗਿਆ ਸੀ ਕਿ ਮੈਂ ਮੌਜੂਦਾ ਕੋਰੋਟੀਨ ਬੈਕਐਂਡ ਤੋਂ ਕੋਡ ਦੀ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਲਾਈਨ ਦੀ ਨਕਲ ਨਹੀਂ ਕੀਤੀ, ਫੰਕਸ਼ਨ. qemu_in_coroutine ਸੱਚ ਵਾਪਸ ਆਇਆ ਜਦੋਂ ਅਸਲ ਵਿੱਚ ਇਸਨੂੰ ਗਲਤ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਸੀ। ਇਸ ਕਾਰਨ ਇੱਕ ਕਾਲ ਹੋਈ emscripten_yield, ਜਿਸ ਦੇ ਉੱਪਰ ਸਟੈਕ 'ਤੇ ਕੋਈ ਨਹੀਂ ਸੀ emscripten_coroutine_next, ਸਟੈਕ ਬਹੁਤ ਸਿਖਰ 'ਤੇ ਪ੍ਰਗਟ ਹੋਇਆ, ਪਰ ਨਹੀਂ setTimeout, ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ, ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ.

JavaScript ਕੋਡ ਬਣਾਉਣਾ

ਅਤੇ ਇੱਥੇ, ਵਾਸਤਵ ਵਿੱਚ, ਵਾਅਦਾ ਕੀਤਾ ਗਿਆ ਹੈ "ਕੀਮੇ ਹੋਏ ਮੀਟ ਨੂੰ ਵਾਪਸ ਮੋੜਨਾ." ਸਚ ਵਿੱਚ ਨਹੀ. ਬੇਸ਼ੱਕ, ਜੇਕਰ ਅਸੀਂ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ Qemu ਨੂੰ ਚਲਾਉਂਦੇ ਹਾਂ, ਅਤੇ ਇਸ ਵਿੱਚ Node.js, ਤਾਂ, ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, Qemu ਵਿੱਚ ਕੋਡ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ ਸਾਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗਲਤ JavaScript ਪ੍ਰਾਪਤ ਹੋਵੇਗੀ। ਪਰ ਫਿਰ ਵੀ, ਕੁਝ ਕਿਸਮ ਦਾ ਉਲਟਾ ਪਰਿਵਰਤਨ.

ਪਹਿਲਾਂ, ਕਿਮੂ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਸ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ। ਕਿਰਪਾ ਕਰਕੇ ਮੈਨੂੰ ਤੁਰੰਤ ਮਾਫ਼ ਕਰੋ: ਮੈਂ ਇੱਕ ਪੇਸ਼ੇਵਰ Qemu ਡਿਵੈਲਪਰ ਨਹੀਂ ਹਾਂ ਅਤੇ ਮੇਰੇ ਸਿੱਟੇ ਕੁਝ ਥਾਵਾਂ 'ਤੇ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ। ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ, "ਵਿਦਿਆਰਥੀ ਦੀ ਰਾਏ ਦਾ ਅਧਿਆਪਕ ਦੀ ਰਾਏ, ਪੀਨੋ ਦੇ ਸਵੈ-ਵਿਗਿਆਨ ਅਤੇ ਆਮ ਸਮਝ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।" Qemu ਕੋਲ ਸਮਰਥਿਤ ਮਹਿਮਾਨ ਆਰਕੀਟੈਕਚਰ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਗਿਣਤੀ ਹੈ ਅਤੇ ਹਰੇਕ ਲਈ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਹੈ ਜਿਵੇਂ ਕਿ target-i386. ਬਣਾਉਂਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਕਈ ਗੈਸਟ ਆਰਕੀਟੈਕਚਰ ਲਈ ਸਮਰਥਨ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਨਤੀਜਾ ਸਿਰਫ ਕਈ ਬਾਈਨਰੀਆਂ ਹੋਵੇਗਾ। ਗੈਸਟ ਆਰਕੀਟੈਕਚਰ ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲਾ ਕੋਡ, ਬਦਲੇ ਵਿੱਚ, ਕੁਝ ਅੰਦਰੂਨੀ ਕਿਮੂ ਓਪਰੇਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਕਿ TCG (ਟਿੰਨੀ ਕੋਡ ਜੇਨਰੇਟਰ) ਪਹਿਲਾਂ ਹੀ ਹੋਸਟ ਆਰਕੀਟੈਕਚਰ ਲਈ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ tcg ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਸਥਿਤ ਰੀਡਮੀ ਫਾਈਲ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇਹ ਅਸਲ ਵਿੱਚ ਇੱਕ ਨਿਯਮਤ C ਕੰਪਾਈਲਰ ਦਾ ਹਿੱਸਾ ਸੀ, ਜਿਸਨੂੰ ਬਾਅਦ ਵਿੱਚ JIT ਲਈ ਅਨੁਕੂਲਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਲਈ, ਉਦਾਹਰਨ ਲਈ, ਇਸ ਦਸਤਾਵੇਜ਼ ਦੇ ਰੂਪ ਵਿੱਚ ਟਾਰਗੇਟ ਆਰਕੀਟੈਕਚਰ ਹੁਣ ਇੱਕ ਗੈਸਟ ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ ਹੈ, ਪਰ ਇੱਕ ਹੋਸਟ ਆਰਕੀਟੈਕਚਰ ਹੈ। ਕਿਸੇ ਸਮੇਂ, ਇੱਕ ਹੋਰ ਕੰਪੋਨੈਂਟ ਪ੍ਰਗਟ ਹੋਇਆ - ਟਿੰਨੀ ਕੋਡ ਇੰਟਰਪ੍ਰੇਟਰ (ਟੀਸੀਆਈ), ਜਿਸ ਨੂੰ ਇੱਕ ਖਾਸ ਹੋਸਟ ਆਰਕੀਟੈਕਚਰ ਲਈ ਕੋਡ ਜਨਰੇਟਰ ਦੀ ਅਣਹੋਂਦ ਵਿੱਚ ਕੋਡ (ਲਗਭਗ ਉਹੀ ਅੰਦਰੂਨੀ ਕਾਰਵਾਈਆਂ) ਨੂੰ ਚਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਇਸਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਕਿਹਾ ਗਿਆ ਹੈ, ਇਹ ਦੁਭਾਸ਼ੀਏ ਹਮੇਸ਼ਾਂ ਇੱਕ JIT ਕੋਡ ਜਨਰੇਟਰ ਦੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਨਾ ਸਿਰਫ ਗਤੀ ਦੇ ਰੂਪ ਵਿੱਚ, ਸਗੋਂ ਗੁਣਾਤਮਕ ਤੌਰ 'ਤੇ ਵੀ। ਹਾਲਾਂਕਿ ਮੈਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ ਕਿ ਉਸਦਾ ਵਰਣਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਢੁਕਵਾਂ ਹੈ।

ਪਹਿਲਾਂ ਮੈਂ ਇੱਕ ਪੂਰਾ ਟੀਸੀਜੀ ਬੈਕਐਂਡ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪਰ ਜਲਦੀ ਹੀ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਉਲਝਣ ਵਿੱਚ ਪੈ ਗਿਆ ਅਤੇ ਬਾਈਟਕੋਡ ਨਿਰਦੇਸ਼ਾਂ ਦਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਪੱਸ਼ਟ ਨਹੀਂ ਦੱਸਿਆ, ਇਸਲਈ ਮੈਂ TCI ਦੁਭਾਸ਼ੀਏ ਨੂੰ ਲਪੇਟਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਇਸ ਨੇ ਕਈ ਫਾਇਦੇ ਦਿੱਤੇ:

• ਕੋਡ ਜਨਰੇਟਰ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਵਰਣਨ ਨੂੰ ਨਹੀਂ, ਪਰ ਦੁਭਾਸ਼ੀਏ ਕੋਡ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ
• ਤੁਸੀਂ ਹਰ ਅਨੁਵਾਦ ਬਲਾਕ ਲਈ ਫੰਕਸ਼ਨ ਤਿਆਰ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ, ਉਦਾਹਰਨ ਲਈ, ਸੌਵੇਂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਤੋਂ ਬਾਅਦ
• ਜੇ ਤਿਆਰ ਕੀਤਾ ਕੋਡ ਬਦਲਦਾ ਹੈ (ਅਤੇ ਇਹ ਸੰਭਵ ਜਾਪਦਾ ਹੈ, ਸ਼ਬਦ ਪੈਚ ਵਾਲੇ ਨਾਵਾਂ ਵਾਲੇ ਫੰਕਸ਼ਨਾਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ), ਮੈਨੂੰ ਤਿਆਰ ਕੀਤੇ JS ਕੋਡ ਨੂੰ ਅਯੋਗ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਪਰ ਘੱਟੋ ਘੱਟ ਮੇਰੇ ਕੋਲ ਇਸਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਕੁਝ ਹੋਵੇਗਾ

ਤੀਜੇ ਬਿੰਦੂ ਦੇ ਸੰਬੰਧ ਵਿੱਚ, ਮੈਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ ਕਿ ਕੋਡ ਨੂੰ ਪਹਿਲੀ ਵਾਰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਪੈਚਿੰਗ ਸੰਭਵ ਹੈ, ਪਰ ਪਹਿਲੇ ਦੋ ਪੁਆਇੰਟ ਕਾਫ਼ੀ ਹਨ.

ਸ਼ੁਰੂ ਵਿੱਚ, ਕੋਡ ਨੂੰ ਮੂਲ ਬਾਈਟਕੋਡ ਨਿਰਦੇਸ਼ ਦੇ ਪਤੇ 'ਤੇ ਇੱਕ ਵੱਡੇ ਸਵਿੱਚ ਦੇ ਰੂਪ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਫਿਰ, ਐਮਸਕ੍ਰਿਪਟਨ ਬਾਰੇ ਲੇਖ ਨੂੰ ਯਾਦ ਕਰਦੇ ਹੋਏ, ਉਤਪੰਨ ਜੇਐਸ ਦੇ ਅਨੁਕੂਲਤਾ ਅਤੇ ਰੀਲੂਪਿੰਗ, ਮੈਂ ਹੋਰ ਮਨੁੱਖੀ ਕੋਡ ਤਿਆਰ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਖਾਸ ਕਰਕੇ ਅਨੁਭਵੀ ਤੌਰ 'ਤੇ ਇਹ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਅਨੁਵਾਦ ਬਲਾਕ ਵਿੱਚ ਸਿਰਫ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਇਸਦਾ ਸ਼ੁਰੂਆਤ ਹੈ। ਜਲਦੀ ਹੀ ਕਿਹਾ ਗਿਆ, ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਸਾਡੇ ਕੋਲ ਇੱਕ ਕੋਡ ਜਨਰੇਟਰ ਸੀ ਜੋ ifs ਨਾਲ ਕੋਡ ਤਿਆਰ ਕਰਦਾ ਸੀ (ਹਾਲਾਂਕਿ ਲੂਪਸ ਤੋਂ ਬਿਨਾਂ)। ਪਰ ਬਦਕਿਸਮਤੀ, ਇਹ ਕ੍ਰੈਸ਼ ਹੋ ਗਿਆ, ਇੱਕ ਸੁਨੇਹਾ ਦਿੰਦਾ ਹੋਇਆ ਕਿ ਨਿਰਦੇਸ਼ ਕੁਝ ਗਲਤ ਲੰਬਾਈ ਦੇ ਸਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਆਵਰਤੀ ਪੱਧਰ 'ਤੇ ਆਖਰੀ ਹਦਾਇਤ ਸੀ brcond. ਠੀਕ ਹੈ, ਮੈਂ ਆਵਰਤੀ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਸ ਹਦਾਇਤ ਦੀ ਪੀੜ੍ਹੀ ਲਈ ਇੱਕ ਸਮਾਨ ਜਾਂਚ ਸ਼ਾਮਲ ਕਰਾਂਗਾ ਅਤੇ... ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਵੀ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਅਸਰਟ ਸਵਿੱਚ ਤੋਂ ਬਾਅਦ ਉਹ ਅਜੇ ਵੀ ਅਸਫਲ ਰਹੇ। ਅੰਤ ਵਿੱਚ, ਤਿਆਰ ਕੀਤੇ ਕੋਡ ਦਾ ਅਧਿਐਨ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਸਵਿੱਚ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੌਜੂਦਾ ਹਦਾਇਤਾਂ ਦਾ ਪੁਆਇੰਟਰ ਸਟੈਕ ਤੋਂ ਰੀਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ JavaScript ਕੋਡ ਦੁਆਰਾ ਓਵਰਰਾਈਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਇਸ ਲਈ ਇਹ ਬਾਹਰ ਬਦਲ ਦਿੱਤਾ. ਬਫਰ ਨੂੰ ਇੱਕ ਮੈਗਾਬਾਈਟ ਤੋਂ ਦਸ ਤੱਕ ਵਧਾਉਣ ਨਾਲ ਕੁਝ ਵੀ ਨਹੀਂ ਹੋਇਆ, ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਕੋਡ ਜਨਰੇਟਰ ਚੱਕਰਾਂ ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਸੀ. ਸਾਨੂੰ ਇਹ ਜਾਂਚ ਕਰਨੀ ਪਈ ਕਿ ਅਸੀਂ ਮੌਜੂਦਾ ਟੀਬੀ ਦੀਆਂ ਸੀਮਾਵਾਂ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਗਏ, ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਅਜਿਹਾ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇੱਕ ਘਟਾਓ ਦੇ ਚਿੰਨ੍ਹ ਨਾਲ ਅਗਲੀ ਟੀਬੀ ਦਾ ਪਤਾ ਜਾਰੀ ਕਰੋ ਤਾਂ ਜੋ ਅਸੀਂ ਅਮਲ ਨੂੰ ਜਾਰੀ ਰੱਖ ਸਕੀਏ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ "ਜੇ ਬਾਈਟਕੋਡ ਦਾ ਇਹ ਟੁਕੜਾ ਬਦਲ ਗਿਆ ਹੈ ਤਾਂ ਕਿਹੜੇ ਤਿਆਰ ਕੀਤੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਅਯੋਗ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ?" — ਸਿਰਫ਼ ਉਹ ਫੰਕਸ਼ਨ ਜੋ ਇਸ ਅਨੁਵਾਦ ਬਲਾਕ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਨੂੰ ਅਯੋਗ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਵੈਸੇ, ਹਾਲਾਂਕਿ ਮੈਂ Chromium ਵਿੱਚ ਹਰ ਚੀਜ਼ ਨੂੰ ਡੀਬੱਗ ਕੀਤਾ ਹੈ (ਕਿਉਂਕਿ ਮੈਂ ਫਾਇਰਫਾਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ ਅਤੇ ਪ੍ਰਯੋਗਾਂ ਲਈ ਇੱਕ ਵੱਖਰਾ ਬ੍ਰਾਊਜ਼ਰ ਵਰਤਣਾ ਮੇਰੇ ਲਈ ਸੌਖਾ ਹੈ), ਫਾਇਰਫਾਕਸ ਨੇ 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 ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰਨ ਲਈ ਲੀਨਕਸ ਦੀ ਪ੍ਰਸ਼ੰਸਾ ਕਰ ਸਕਦੇ ਹੋ।

ਤੁਸੀਂ ਹੋਰ ਕੀ ਕਰ ਸਕਦੇ ਹੋ

• ਇਮੂਲੇਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਕਰੋ। ਜੇਆਈਟੀ ਮੋਡ ਵਿੱਚ ਵੀ ਇਹ ਵਰਚੁਅਲ x86 ਨਾਲੋਂ ਹੌਲੀ ਚੱਲਦਾ ਜਾਪਦਾ ਹੈ (ਪਰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਇਮੂਲੇਟਡ ਹਾਰਡਵੇਅਰ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਾਲ ਇੱਕ ਪੂਰਾ ਕਿਮੂ ਹੈ)
• ਇੱਕ ਸਧਾਰਨ ਇੰਟਰਫੇਸ ਬਣਾਉਣ ਲਈ - ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਮੈਂ ਇੱਕ ਚੰਗਾ ਵੈੱਬ ਡਿਵੈਲਪਰ ਨਹੀਂ ਹਾਂ, ਇਸ ਲਈ ਹੁਣ ਲਈ ਮੈਂ ਮਿਆਰੀ ਐਮਸਕ੍ਰਿਪਟਨ ਸ਼ੈੱਲ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਢੰਗ ਨਾਲ ਦੁਬਾਰਾ ਬਣਾਇਆ ਹੈ ਜੋ ਮੈਂ ਕਰ ਸਕਦਾ ਹਾਂ
• ਹੋਰ ਗੁੰਝਲਦਾਰ Qemu ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ - ਨੈੱਟਵਰਕਿੰਗ, VM ਮਾਈਗ੍ਰੇਸ਼ਨ, ਆਦਿ।
• ਯੂਪੀਡੀ: ਤੁਹਾਨੂੰ ਆਪਣੇ ਕੁਝ ਵਿਕਾਸ ਅਤੇ ਬੱਗ ਰਿਪੋਰਟਾਂ ਨੂੰ Emscripten ਅੱਪਸਟ੍ਰੀਮ ਵਿੱਚ ਜਮ੍ਹਾਂ ਕਰਾਉਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਜਿਵੇਂ ਕਿ Qemu ਅਤੇ ਹੋਰ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਪਿਛਲੇ ਪੋਰਟਰਾਂ ਨੇ ਕੀਤਾ ਸੀ। ਮੇਰੇ ਕੰਮ ਦੇ ਹਿੱਸੇ ਵਜੋਂ Emscripten ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਯੋਗਦਾਨ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਵਰਤਣ ਦੇ ਯੋਗ ਹੋਣ ਲਈ ਉਹਨਾਂ ਦਾ ਧੰਨਵਾਦ।

ਸਰੋਤ: www.habr.com