לפני כמה שנים פבריס בלארד נכתב על ידי jslinux הוא אמולטור PC שנכתב ב-JavaScript. אחרי זה היה לפחות יותר וירטואלי x86. אבל כולם, עד כמה שידוע לי, היו מתורגמנים, בעוד Qemu, שנכתב הרבה קודם על ידי אותו Fabrice Bellard, וכנראה, כל אמולטור מודרני שמכבד את עצמו, משתמש בהידור JIT של קוד אורח לתוך קוד מערכת מארח. נראה לי שהגיע הזמן ליישם את המשימה ההפוכה ביחס למשימה שדפדפנים פותרים: הידור JIT של קוד מכונה ל-JavaScript, שעבורו נראה הכי הגיוני להעביר Qemu. נראה, למה Qemu, ישנם אמולטורים פשוטים וידידותיים יותר - אותו VirtualBox, למשל - מותקנים ועובדים. אבל ל-Qemu יש כמה תכונות מעניינות

• קוד פתוח
• יכולת לעבוד ללא מנהל התקן ליבה
• יכולת עבודה במצב מתורגמן
• תמיכה במספר רב של ארכיטקטורות מארח ואורח

לגבי הנקודה השלישית, אני יכול להסביר כעת שלמעשה, במצב TCI, לא מתפרשות הוראות מכונת האורח עצמן, אלא ה-bytecode המתקבל מהן, אבל זה לא משנה את המהות - על מנת לבנות ולהפעיל Qemu על ארכיטקטורה חדשה, אם יתמזל מזלכם, מספיק מהדר C - כתיבת מחולל קוד יכולה להידחות.

ועכשיו, אחרי שנתיים של התעסקות נינוחה עם קוד המקור של Qemu בזמני הפנוי, הופיע אב טיפוס עובד, שבו כבר אפשר להריץ, למשל, את מערכת ההפעלה Kolibri.

מה זה Emscripten

כיום, הופיעו מהדרים רבים, שהתוצאה הסופית שלהם היא JavaScript. חלקם, כמו Type Script, נועדו במקור להיות הדרך הטובה ביותר לכתוב עבור האינטרנט. יחד עם זאת, Emscripten היא דרך לקחת קוד C או C++ קיים ולהדר אותו לצורה הניתנת לקריאה בדפדפן. עַל דף זה אספנו יציאות רבות של תוכניות ידועות: כאןלדוגמה, אפשר להסתכל על PyPy - אגב, הם טוענים שכבר יש להם JIT. למעשה, לא כל תוכנה ניתנת להידור ולהפעיל בדפדפן פשוט - יש מספר מאפייניםעם זאת, אתה צריך להשלים עם הכיתוב באותו עמוד "אפשר להשתמש ב-Emscripten כדי להרכיב כמעט כל נייד קוד C/C++ ל-JavaScript". כלומר, ישנן מספר פעולות שהן התנהגות לא מוגדרת לפי התקן, אך לרוב עובדות על x86 - למשל, גישה לא מיושרת למשתנים, שבדרך כלל אסורה בחלק מהארכיטקטורות. באופן כללי , Qemu היא תוכנית חוצת פלטפורמות ו-, רציתי להאמין, והיא לא מכילה כבר הרבה התנהגות לא מוגדרת - קח אותה והידור, ואז תתעסק קצת עם JIT - וסיימת! אבל זה לא העניין מקרה...

ניסיון ראשון

באופן כללי, אני לא האדם הראשון שהעלה את הרעיון של העברה של Qemu ל-JavaScript. נשאלה שאלה בפורום ReactOS אם זה אפשרי באמצעות Emscripten. עוד קודם לכן, היו שמועות שפבריס בלארד עשה זאת באופן אישי, אבל דיברנו על jslinux, שככל הידוע לי הוא רק ניסיון להשיג ביצועים מספקים באופן ידני ב-JS, והוא נכתב מאפס. מאוחר יותר, Virtual x86 נכתב - פורסמו עבורו מקורות לא מעורפלים, וכאמור, ה"ריאליזם" הגדול יותר של האמולציה אפשרה להשתמש ב-SeaBIOS בתור קושחה. בנוסף, היה לפחות ניסיון אחד להעביר את Qemu באמצעות Emscripten - ניסיתי לעשות זאת זוג שקעים, אבל ההתפתחות, למיטב הבנתי, הוקפאה.

אז, כך נראה, הנה המקורות, הנה Emscripten - קח אותו והידור. אבל יש גם ספריות ש-Qemu תלוי בהן, וספריות שהספריות האלה תלויות בהן וכו', ואחת מהן היא ליבפי, אשר גליב תלוי בו. היו שמועות באינטרנט שיש אחד באוסף הגדול של יציאות ספריות עבור Emscripten, אבל איכשהו היה קשה להאמין: ראשית, הוא לא נועד להיות מהדר חדש, שנית, הוא היה ברמה נמוכה מדי. ספריה פשוט לאסוף, והידור ל-JS. וזה לא רק עניין של תוספות assembly - כנראה, אם תסובב את זה, עבור כמה מוסכמות קריאה אתה יכול ליצור את הארגומנטים הדרושים על המחסנית ולקרוא לפונקציה בלעדיהם. אבל Emscripten הוא דבר מסובך: על מנת לגרום לקוד שנוצר להיראות מוכר לכלי האופטימיזציה של מנוע JS של הדפדפן, משתמשים בכמה טריקים. בפרט, מה שנקרא relooping - מחולל קוד המשתמש ב-LLVM IR שהתקבל עם כמה הוראות מעבר מופשטות מנסה ליצור מחדש אם סבירים, לולאות וכו'. ובכן, כיצד מועברים הארגומנטים לפונקציה? באופן טבעי, כארגומנטים לפונקציות JS, כלומר, אם אפשר, לא דרך המחסנית.

בהתחלה היה רעיון פשוט לכתוב תחליף ל-libffi עם JS ולהריץ בדיקות סטנדרטיות, אבל בסוף התבלבלתי איך לעשות את קבצי ה-header שלי כך שהם יעבדו עם הקוד הקיים - מה אני יכול לעשות, כמו שאומרים, "האם המשימות כל כך מורכבות "האם אנחנו כל כך טיפשים?" הייתי צריך להעביר את libffi לארכיטקטורה אחרת, כביכול - למרבה המזל, ל-Emscripten יש גם פקודות מאקרו להרכבה מוטבעת (ב-Javascript, כן - ובכן, לא משנה מה הארכיטקטורה, אז האסמבלר), וגם את היכולת להריץ קוד שנוצר תוך כדי תנועה. באופן כללי, לאחר התעסקות עם שברי libffi התלויים בפלטפורמה במשך זמן מה, קיבלתי קוד קומפילציה והרצתי אותו בבדיקה הראשונה שנתקלתי בה. להפתעתי, המבחן הצליח. המום מהגאונות שלי - בלי בדיחה, זה עבד מההשקה הראשונה - אני, עדיין לא מאמין למראה עיניי, הלכתי להסתכל שוב על הקוד שהתקבל, כדי להעריך היכן לחפור הלאה. כאן השתגעתי בפעם השנייה - הדבר היחיד שהפונקציה שלי עשתה היה ffi_call - זה דיווח על שיחה מוצלחת. לא הייתה שיחה עצמה. אז שלחתי את בקשת המשיכה הראשונה שלי, שתיקנה טעות במבחן שברורה לכל תלמיד אולימפיאדה - אין להשוות מספרים אמיתיים a == b ואפילו איך a - b < EPS - צריך לזכור גם את המודול, אחרת 0 יתברר כשווה מאוד ל-1/3... באופן כללי, הגעתי לפורט מסוים של libffi, שעובר את המבחנים הפשוטים ביותר, ואיתו glib הוא הידור - החלטתי שזה נחוץ, אוסיף את זה מאוחר יותר. במבט קדימה, אני אגיד שכפי שהתברר, המהדר אפילו לא כלל את הפונקציה libffi בקוד הסופי.

אבל, כפי שכבר אמרתי, ישנן כמה מגבלות, ובין השימוש החופשי בהתנהגות לא מוגדרת למיניהן, הוסתרה תכונה לא נעימה יותר - JavaScript בעיצובו אינו תומך ב-multithreading עם זיכרון משותף. באופן עקרוני, זה יכול להיקרא בדרך כלל רעיון טוב, אבל לא עבור העברת קוד שהארכיטקטורה שלו קשורה ל-C threads. באופן כללי, פיירפוקס מתנסה בתמיכה בעובדים משותפים, ול-Emscripten יש יישום pthread עבורם, אבל לא רציתי לסמוך עליו. נאלצתי לאט לאט להוציא את ה-multithreading מקוד ה-Qemu - כלומר, לברר היכן ה-threads רצים, להעביר את גוף הלולאה הפועלת בשרשור הזה לפונקציה נפרדת, ולקרוא לפונקציות כאלו אחת אחת מהלולאה הראשית.

ניסיון שני

בשלב מסוים, התברר שהבעיה עדיין קיימת, ושדחיפה אקראית של קביים סביב הקוד לא תוביל לשום טוב. מסקנה: עלינו לעשות איכשהו שיטתיות של תהליך הוספת קביים. לכן נלקחה גרסה 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 משתמשת בגישה לא מיושרת בעת ניתוח ה-bytecode שלה. כלומר, בכל מיני ארכיטקטורות ARM וארכיטקטורות אחרות עם גישה מפולסת בהכרח, Qemu מבצע קומפילציה כי יש להם TCG backend רגיל שמייצר קוד מקורי, אבל האם TCI יעבוד עליהם זו שאלה אחרת. עם זאת, כפי שהתברר, תיעוד TCI הצביע בבירור על משהו דומה. כתוצאה מכך נוספו לקוד קריאות פונקציה לקריאה לא מיושרת, שנמצאו בחלק אחר של Qemu.

הרס ערימה

כתוצאה מכך, תוקנה גישה לא מיושרת ל-TCI, נוצרה לולאה ראשית אשר בתורה קראה למעבד, RCU ועוד כמה דברים קטנים. וכך אני משיק את Qemu עם האפשרות -d exec,in_asm,out_asm, מה שאומר שאתה צריך לומר אילו בלוקים של קוד מבוצעים, וגם בזמן השידור לכתוב מה היה קוד האורח, מה הפך לקוד המארח (במקרה זה, bytecode). זה מתחיל, מבצע מספר בלוקים של תרגום, כותב את הודעת איתור הבאגים שהשארתי ש-RCU יתחיל עכשיו ו... קורס abort() בתוך פונקציה free(). על ידי התעסקות עם הפונקציה free() הצלחנו לגלות שבראש בלוק הערימה, שנמצא בשמונה בתים שלפני הזיכרון שהוקצה, במקום גודל הבלוק או משהו דומה, היה זבל.

הרס הערימה - כמה חמוד... במקרה כזה, יש תרופה שימושית - מאותם מקורות (אם אפשר) הרכיבו בינארי יליד והריצו אותו תחת Valgrind. לאחר זמן מה, הבינארי היה מוכן. אני משיק אותו עם אותן אפשרויות - הוא קורס אפילו בזמן האתחול, לפני שהוא מגיע לביצוע בפועל. זה לא נעים, כמובן - ככל הנראה, המקורות לא היו בדיוק זהים, וזה לא מפתיע, כי התצורה הסתכלה על אפשרויות קצת שונות, אבל יש לי Valgrind - קודם אני אתקן את הבאג הזה, ואז, אם יהיה לי מזל , המקורי יופיע. אני מריץ את אותו הדבר תחת Valgrind... Y-y-y, y-y-y, אה-אה, זה התחיל, עבר אתחול כרגיל ועבר את הבאג המקורי ללא אזהרה אחת על גישה לא נכונה לזיכרון, שלא לדבר על נפילות. החיים, כמו שאומרים, לא הכינו אותי לזה - תוכנית קורסת מפסיקה לקרוס כשהיא מופעלת תחת Walgrind. מה זה היה תעלומה. ההשערה שלי היא שפעם אחת בקרבת ההוראה הנוכחית לאחר התרסקות במהלך האתחול, gdb הראה עבודה memset-a עם מצביע חוקי באמצעות אחד מהם mmx, או xmm רושמים, אז אולי זו הייתה איזושהי שגיאת יישור, אם כי עדיין קשה להאמין.

בסדר, נראה שלגרינד לא עוזר כאן. וכאן התחיל הדבר הכי מגעיל - נראה שהכל אפילו מתחיל, אבל קורס מסיבות לא ידועות לחלוטין בגלל אירוע שיכול היה להתרחש לפני מיליוני הוראות. הרבה זמן אפילו לא היה ברור איך לגשת. בסופו של דבר, עדיין הייתי צריך לשבת ולבצע ניפוי באגים. הדפסת מה שהכותרת נכתבה איתו הראתה שהיא לא נראית כמו מספר, אלא סוג של נתונים בינאריים. והנה, המחרוזת הבינארית הזו נמצאה בקובץ ה-BIOS – כלומר, עכשיו אפשר היה לומר בביטחון סביר שמדובר ב-buffer overflow, ואפילו ברור שהוא נכתב למאגר הזה. ובכן, אז משהו כזה - ב-Emscripten, למרבה המזל, אין אקראי של מרחב הכתובות, גם אין בו חורים, אז אתה יכול לכתוב איפשהו באמצע הקוד כדי להוציא נתונים לפי מצביע מההשקה האחרונה, הסתכלו על הנתונים, הסתכלו על המצביע, ואם הם לא השתנו, קבלו חומר למחשבה. נכון, לוקח כמה דקות לקשר אחרי כל שינוי, אבל מה אתה יכול לעשות? כתוצאה מכך, נמצאה שורה ספציפית שהעתיקה את ה-BIOS מהמאגר הזמני לזיכרון האורח - ואכן, לא היה מספיק מקום במאגר. מציאת המקור של כתובת המאגר המוזרה הזו הובילה לפונקציה qemu_anon_ram_alloc בקובץ oslib-posix.c - ההיגיון שם היה זה: לפעמים זה יכול להיות שימושי ליישר את הכתובת לעמוד ענק בגודל 2 מגה-בייט, בשביל זה נבקש mmap תחילה עוד קצת, ואז נחזיר את העודף בעזרתו munmap. ואם לא נדרש יישור כזה, נציין את התוצאה במקום 2 מגה-בייט getpagesize() - mmap זה עדיין ימסור כתובת מיושרת... אז ב-Emscripten mmap רק שיחות malloc, אבל כמובן שזה לא מתיישר בדף. באופן כללי, באג שתסכל אותי במשך כמה חודשים תוקן על ידי שינוי ב двух שורות.

תכונות של פונקציות שיחות

ועכשיו המעבד סופר משהו, Qemu לא קורס, אבל המסך לא נדלק, והמעבד נכנס במהירות ללולאות, אם לשפוט לפי הפלט -d exec,in_asm,out_asm. עלתה השערה: פסיקות טיימר (או, באופן כללי, כל ההפסקות) אינן מגיעות. ואכן, אם בורגים את ההפרעות מהאספת הילידים, שמשום מה עבדה, מתקבלת תמונה דומה. אבל זו לא הייתה התשובה בכלל: השוואה של העקבות שהופקו עם האפשרות הנ"ל הראתה שמסלולי הביצוע התפצלו מוקדם מאוד. כאן יש לומר השוואה של מה שנרשם באמצעות המשגר emrun איתור באגים בפלט עם הפלט של ההרכבה המקומית אינו תהליך מכני לחלוטין. אני לא יודע איך בדיוק מתחברת תוכנית הפועלת בדפדפן 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> כתוצאה מכך, סוף סוף הייתה לי הזדמנות לנסות את הספרייה בעבודה קידוד, ונכתב סקריפט שמייצר בדיוק את אותם עטיפות בדיוק לפונקציות שעבורן הן נחוצות.

וכך, אחרי זה נראה היה שהמעבד עובד. נראה שזה בגלל שהמסך מעולם לא אותחל, למרות ש-memtest86+ הצליחה לרוץ ב-Native assembly. כאן יש צורך להבהיר שקוד Qemu block I/O כתוב בקורוטינות. ל-Emscripten יש יישום מאוד מסובך משלו, אבל עדיין היה צורך לתמוך בו בקוד Qemu, ואתה יכול לבצע ניפוי באגים במעבד עכשיו: Qemu תומך באפשרויות -kernel, -initrd, -append, שבאמצעותו אתה יכול לאתחל את לינוקס או, למשל, memtest86+, מבלי להשתמש במכשירי חסימה כלל. אבל הנה הבעיה: בהרכבה המקורית אפשר היה לראות את פלט ליבת לינוקס לקונסולה עם האפשרות -nographic, וללא פלט מהדפדפן למסוף שממנו הושק emrun, לא הגיע. כלומר, לא ברור: המעבד לא עובד או הפלט הגרפי לא עובד. ואז עלה בדעתי לחכות קצת. התברר ש"המעבד לא ישן, אלא פשוט מהבהב לאט", ואחרי כחמש דקות הקרנל זרק צרור הודעות לקונסולה והמשיך להיתקע. התברר שהמעבד, באופן כללי, עובד, ועלינו לחפור בקוד לעבודה עם SDL2. לצערי, אני לא יודע איך להשתמש בספרייה הזו, אז במקומות מסוימים נאלצתי לפעול באקראי. בשלב מסוים, הקו parallel0 הבהב על המסך על רקע כחול, מה שהציע כמה מחשבות. בסופו של דבר התברר שהבעיה היא ש-Qemu פותחת מספר חלונות וירטואליים בחלון פיזי אחד, ביניהם ניתן לעבור באמצעות Ctrl-Alt-n: זה עובד ב-Native build, אבל לא ב-Emscripten. לאחר להיפטר מחלונות מיותרים באמצעות אפשרויות -monitor none -parallel none -serial none והוראות לצייר מחדש בכוח את כל המסך על כל פריים, הכל פתאום עבד.

קורוטינים

אז, אמולציה בדפדפן עובדת, אבל אתה לא יכול להפעיל בו שום תקליטון מעניין, מכיוון שאין קלט/פלט חסום - אתה צריך ליישם תמיכה בקורוטינים. ל-Qemu כבר יש מספר קצה קצה של Coroutine, אבל בגלל האופי של JavaScript ומחולל הקוד של Emscripten, אתה לא יכול פשוט להתחיל ללהטט בערימות. נראה ש"הכל נעלם, הטיח מוסר", אבל מפתחי Emscripten כבר דאגו להכל. זה מיושם די מצחיק: בואו נקרא לקריאת פונקציה כזו כחשודה emscripten_sleep ועוד כמה אחרים המשתמשים במנגנון Asyncify, כמו גם קריאות מצביע וקריאות לכל פונקציה שבה אחד משני המקרים הקודמים עשוי להתרחש בהמשך הערימה. וכעת, לפני כל קריאה חשודה, נבחר הקשר אסינכרוני, ומיד לאחר הקריאה נבדוק האם התרחשה קריאה אסינכרונית, ואם כן נשמור את כל המשתנים המקומיים בהקשר אסינכרוני זה, נציין איזו פונקציה להעביר את השליטה למועד שבו אנחנו צריכים להמשיך בביצוע ולצאת מהפונקציה הנוכחית. זה המקום שבו יש מקום לחקור את ההשפעה בִּזבּוּז - לצורכי המשך ביצוע קוד לאחר חזרה מקריאה אסינכרונית, המהדר מייצר "תולים" של הפונקציה החל לאחר קריאה חשודה - כך: אם יש n קריאות חשודות, אז הפונקציה תורחב איפשהו n/2 פעמים - זה עדיין, אם לא זכור שאחרי כל שיחה שעלולה להיות אסינכרונית, אתה צריך להוסיף שמירת כמה משתנים מקומיים לפונקציה המקורית. לאחר מכן, אפילו נאלצתי לכתוב סקריפט פשוט ב-Python, אשר, בהתבסס על סט נתון של פונקציות בשימוש יתר במיוחד, שכביכול "לא מאפשרות לא-סינכרון לעבור דרך עצמן" (כלומר, קידום מחסנית וכל מה שתיארתי זה עתה לא עבודה בהם), מציינת קריאות דרך מצביעים שבהם יש להתעלם מפונקציות על ידי המהדר כך שפונקציות אלו לא ייחשבו אסינכרוניות. ואז קבצי JS מתחת ל-60 מגה-בייט הם בעליל יותר מדי - נניח לפחות 30. אם כי, פעם אחת הגדרתי סקריפט assembly, ובטעות זרקתי את אפשרויות הקישור, ביניהן -O3. אני מריץ את הקוד שנוצר, ו-Chromium אוכל את הזיכרון ומתרסק. ואז הסתכלתי בטעות על מה שהוא ניסה להוריד... ובכן, מה אני יכול לומר, גם אני הייתי קופאת אם היו מבקשים ממני ללמוד ולבצע אופטימיזציה של 500+ MB Javascript.

לרוע המזל, הבדיקות בקוד ספריית התמיכה של Asyncify לא היו ידידותיים לחלוטין longjmp-s המשמשים בקוד המעבד הוירטואלי, אבל לאחר תיקון קטן שמבטל את הבדיקות הללו ומשחזר בכוח הקשרים כאילו הכל בסדר, הקוד עבד. ואז התחיל דבר מוזר: לפעמים הופעלו בדיקות בקוד הסנכרון - אותן בדיקות שמרסקות את הקוד אם, לפי היגיון הביצוע, צריך לחסום אותו - מישהו ניסה לתפוס mutex שכבר נלכד. למרבה המזל, התברר שזו לא בעיה הגיונית בקוד הסדרתי - פשוט השתמשתי בפונקציונליות הלולאה הראשית הסטנדרטית שסיפקה Emscripten, אבל לפעמים הקריאה האסינכרונית הייתה מפרקת לחלוטין את הערימה, ובאותו רגע היא תיכשל setTimeout מהלולאה הראשית - כך, הקוד נכנס לאיטרציה של הלולאה הראשית מבלי לצאת מהאיטרציה הקודמת. נכתב מחדש על לולאה אינסופית ו emscripten_sleep, והבעיות עם mutexes פסקו. הקוד אפילו הפך ליותר הגיוני - אחרי הכל, למעשה, אין לי איזה קוד שמכין את המסגרת האנימציה הבאה - המעבד פשוט מחשב משהו והמסך מתעדכן מעת לעת. עם זאת, הבעיות לא נעצרו שם: לפעמים ביצוע Qemu פשוט היה מסתיים בשקט ללא חריגים או שגיאות. באותו רגע ויתרתי על זה, אבל בהסתכלות קדימה, אני אגיד שהבעיה הייתה כזו: למעשה, קוד הקורוטין אינו משתמש setTimeout (או לפחות לא בתדירות שבה אתה עשוי לחשוב): פונקציה emscripten_yield פשוט מגדיר את דגל השיחה האסינכרונית. כל העניין הוא זה emscripten_coroutine_next אינה פונקציה אסינכרונית: פנימית היא בודקת את הדגל, מאפסת אותו ומעבירה את השליטה למקום הדרוש. כלומר, קידום המחסנית מסתיים שם. הבעיה הייתה שבגלל use-after-free, שהופיע כאשר מאגר ה-coroutine הושבת עקב העובדה שלא העתקתי שורת קוד חשובה מה-backend הקיים של coroutine, הפונקציה qemu_in_coroutine החזיר אמת כשלמעשה זה היה צריך להחזיר שקר. זה הוביל לשיחה emscripten_yield, שמעליו לא היה איש על הערימה emscripten_coroutine_next, הערימה נפרשה עד למעלה, אבל לא setTimeout, כפי שכבר אמרתי, לא הוצג.

יצירת קוד JavaScript

והנה, למעשה, מובטחת "החזרת הבשר הטחון לאחור". לא באמת. כמובן שאם נריץ את Qemu בדפדפן, ו-Node.js בו, אז, באופן טבעי, לאחר יצירת קוד ב-Qemu נקבל JavaScript שגוי לחלוטין. אבל בכל זאת, איזושהי טרנספורמציה הפוכה.

ראשית, קצת על איך Qemu עובד. אנא סלח לי מיד: אני לא מפתח Qemu מקצועי והמסקנות שלי עשויות להיות שגויות במקומות מסוימים. כפי שאומרים, "דעתו של התלמיד אינה חייבת להיות תואמת את דעתו של המורה, האקסיומטיקה והשכל הישר של פיאנו". ל-Qemu יש מספר מסוים של ארכיטקטורות אורחים נתמכות ולכל אחת יש ספרייה כמו target-i386. בעת בנייה, אתה יכול לציין תמיכה עבור כמה ארכיטקטורות אורחים, אבל התוצאה תהיה רק ​​כמה בינאריים. הקוד לתמיכה בארכיטקטורת האורח, בתורו, יוצר כמה פעולות Qemu פנימיות, שה-TCG (מחולל קוד זעיר) כבר הופך לקוד מכונה עבור ארכיטקטורת המארח. כפי שצוין בקובץ readme שנמצא בספריית tcg, זה היה במקור חלק ממהדר C רגיל, שהותאם מאוחר יותר ל-JIT. לכן, למשל, ארכיטקטורת יעד מבחינת מסמך זה אינה עוד ארכיטקטורת אורח, אלא ארכיטקטורת מארח. בשלב מסוים הופיע רכיב נוסף - Tiny Code Interpreter (TCI), שאמור לבצע קוד (כמעט אותן פעולות פנימיות) בהיעדר מחולל קוד לארכיטקטורת מארח ספציפית. למעשה, כפי שצוין בתיעוד שלו, ייתכן שהמתורגמן הזה לא תמיד מתפקד כמו מחולל קוד JIT, לא רק מבחינה כמותית מבחינת מהירות, אלא גם מבחינה איכותית. למרות שאני לא בטוח שהתיאור שלו רלוונטי לחלוטין.

בהתחלה ניסיתי ליצור TCG backend מלא, אבל מהר מאוד התבלבלתי בקוד המקור ובתיאור לא לגמרי ברור של הוראות ה-bytecode, אז החלטתי לעטוף את המתורגמן TCI. זה נתן מספר יתרונות:

• בעת יישום מחולל קוד, אתה יכול להסתכל לא על תיאור ההוראות, אלא על קוד המתורגמן
• אתה יכול ליצור פונקציות לא עבור כל בלוק תרגום שנתקל בו, אלא, למשל, רק לאחר הביצוע המאה
• אם הקוד שנוצר משתנה (ונראה שזה אפשרי, אם לשפוט לפי הפונקציות עם שמות המכילים את המילה patch), אצטרך לבטל את תוקף קוד ה-JS שנוצר, אבל לפחות יהיה לי ממה ליצור אותו מחדש.

לגבי הנקודה השלישית, אני לא בטוח שתיקון אפשרי לאחר ביצוע הקוד בפעם הראשונה, אבל שתי הנקודות הראשונות מספיקות.

בתחילה, הקוד נוצר בצורה של מתג גדול בכתובת של הוראת ה-bytecode המקורית, אבל לאחר מכן, כשנזכרתי במאמר על Emscripten, אופטימיזציה של JS שנוצר ו-relooping, החלטתי ליצור קוד אנושי יותר, במיוחד מכיוון שמבחינה אמפירית זה התברר שנקודת הכניסה היחידה לבלוק התרגום היא ההתחלה שלו. לא מוקדם יותר מאשר נעשה, לאחר זמן מה היה לנו מחולל קוד שיצר קוד עם ifs (אם כי ללא לולאות). אבל מזל רע, זה התרסק, נותן הודעה שההוראות היו באורך לא נכון. יתרה מכך, ההוראה האחרונה ברמת הרקורסיה הזו הייתה brcond. אוקיי, אני אוסיף צ'ק זהה להפקת ההוראה הזו לפני ואחרי השיחה הרקורסיבית ו... אף אחת מהן לא בוצעה, אבל אחרי ה-assert switch הם עדיין נכשלו. בסופו של דבר, לאחר לימוד הקוד שנוצר, הבנתי שאחרי המעבר, המצביע להוראה הנוכחית נטען מחדש מהמחסנית וככל הנראה מוחלף על ידי קוד ה-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"]

מסקנה

אז העבודה עדיין לא הושלמה, אבל נמאס לי להביא את הבנייה ארוכת הטווח הזו לשלמות בסתר. לכן החלטתי לפרסם את מה שיש לי לעת עתה. הקוד קצת מפחיד במקומות, כי זה ניסוי, ולא ברור מראש מה צריך לעשות. כנראה, אז כדאי להוציא התחייבויות אטומיות רגילות על גבי גרסה מודרנית יותר של Qemu. בינתיים יש שרשור בגיטה בפורמט בלוג: על כל "רמה" שעברה לפחות איכשהו, נוספה פרשנות מפורטת ברוסית. למעשה, מאמר זה הוא במידה רבה מספר מחדש של המסקנה git log.

אתה יכול לנסות הכל כאן (היזהרו מתנועה).

מה כבר עובד:

• מעבד וירטואלי x86 פועל
• יש אב טיפוס עובד של מחולל קוד JIT מקוד מכונה ועד JavaScript
• יש תבנית להרכבת ארכיטקטורות אורח אחרות של 32 סיביות: כרגע אתה יכול להתפעל מ-Linux עבור ארכיטקטורת MIPS שקפאה בדפדפן בשלב הטעינה

מה עוד אתה יכול לעשות

• האצת הדמייה. אפילו במצב JIT נראה שהוא פועל לאט יותר מאשר Virtual x86 (אבל יש פוטנציאל Qemu שלם עם הרבה חומרה וארכיטקטורות מחקות)
• כדי ליצור ממשק נורמלי - למען האמת, אני לא מפתח אינטרנט טוב, אז לעת עתה יצרתי מחדש את מעטפת Emscripten הסטנדרטית כמיטב יכולתי
• נסה להפעיל פונקציות מורכבות יותר של Qemu - רשתות, העברת VM וכו'.
• UPD: תצטרך להגיש את מספר ההתפתחויות ודיווחי הבאגים שלך ל-Emscripten במעלה הזרם, כפי שעשו סבלים קודמים של Qemu ופרויקטים אחרים. תודה להם על היכולת להשתמש באופן מרומז בתרומתם ל-Emscripten כחלק מהמשימה שלי.

מקור: www.habr.com