کالبدشکافی شبیه‌سازهای معماری (Rosetta و Prism): پردازنده‌های ARM واقعاً چگونه برنامه‌های قدیمی را فریب می‌دهند؟

شما یک مک‌بوک مجهز به تراشه M3 یا یک لپ‌تاپ ویندوزی با پردازنده Snapdragon X Elite می‌خرید. یک برنامه قدیمی که سال‌ها پیش برای پردازنده‌های اینتل نوشته شده است را دانلود می‌کنید و روی آن دو بار کلیک می‌کنید. برنامه در کسری از ثانیه باز می‌شود و بدون هیچ خطایی کار می‌کند. تیم‌های بازاریابی این فرآیند را «جادو» یا «یکپارچگی بی‌نقص» می‌نامند، اما در پس‌زمینه، یکی از پیچیده‌ترین فریب‌های تاریخ علوم کامپیوتر در حال رخ دادن است.[5]

پردازنده جدید شما با زبان ARM صحبت می‌کند، در حالی که برنامه قدیمی شما به زبان x86 نوشته شده است. این دو معماری از پایه با هم متفاوت‌اند. معماری x86 از نوع CISC (مجموعه دستورالعمل‌های پیچیده) است که در آن طول دستورات متغیر است، در حالی که ARM از نوع RISC (مجموعه دستورالعمل‌های کاهش‌یافته) با طول ثابت استفاده می‌کند. اجرای مستقیم یک برنامه x86 روی ARM مانند این است که یک رمان ژاپنی را به فردی بدهید که فقط زبان سواحیلی می‌فهمد و از او بخواهید آن را در لحظه و بدون تپق زدن با صدای بلند بخواند.[5]

برای حل این مشکل، مهندسان نرم‌افزار از دو روش اصلی استفاده می‌کنند: ترجمه پیش از اجرا (AOT) و ترجمه درلحظه (JIT). ابزار Rosetta 2 اپل بخش بزرگی از کار خود را به روش AOT انجام می‌دهد. وقتی شما یک برنامه x86 را روی مک نصب می‌کنید، Rosetta کل کدهای باینری آن را اسکن کرده و پیش از اینکه حتی برنامه را باز کنید، یک نسخه ترجمه‌شده به زبان ARM از آن می‌سازد و ذخیره می‌کند. این کار باعث می‌شود برنامه در دفعات بعدی با سرعت بومی اجرا شود.[1]

اما ترجمه پیش از اجرا نمی‌تواند همه چیز را حل کند. مرورگرهای وب (که کدهای جاوا اسکریپت را اجرا می‌کنند) و بازی‌های ویدیویی، کدهای جدیدی را در همان لحظه اجرا تولید می‌کنند. برای این موارد، Rosetta 2 و شبیه‌ساز Prism مایکروسافت به روش JIT متوسل می‌شوند. آن‌ها باید کدها را در کسری از میلی‌ثانیه، درست قبل از رسیدن به پردازنده، ترجمه کنند. شبیه‌ساز Prism در ویندوز ۱۱ به شدت روی بهینه‌سازی این ترجمه درلحظه تمرکز کرده است تا افت عملکرد را به حداقل برساند.[1][2]

با این حال، ترجمه دستورالعمل‌ها تنها نیمی از نبرد است. غول مرحله آخر در شبیه‌سازی معماری، چیزی است که مهندسان به آن «مدل حافظه» (Memory Model) می‌گویند. این همان جایی است که تفاوت واقعی بین رویکرد اپل و مایکروسافت آشکار می‌شود.[3]

معماری x86 دارای یک مدل حافظه بسیار سخت‌گیرانه به نام «ترتیب ذخیره‌سازی کل» (Total Store Ordering یا TSO) است. در این مدل، پردازنده تضمین می‌کند که اگر یک بخش از برنامه (Thread) اطلاعاتی را در حافظه بنویسد، بخش‌های دیگر برنامه آن اطلاعات را دقیقاً به همان ترتیبی که نوشته شده‌اند، خواهند دید. این مدل مانند یک صف منظم در بانک است که همه چیز طبق نوبت پیش می‌رود.[3]

اما پردازنده‌های ARM از یک «مدل حافظه ضعیف» (Weak Memory Model) استفاده می‌کنند. برای افزایش سرعت و کارایی، تراشه‌های ARM به خود اجازه می‌دهند ترتیب خواندن و نوشتن در حافظه را تغییر دهند. برای برنامه‌هایی که از ابتدا برای ARM نوشته شده‌اند، این موضوع مشکلی ایجاد نمی‌کند. اما اگر یک برنامه x86 که انتظار نظم مطلق را دارد روی این مدل اجرا شود، داده‌ها با هم تداخل پیدا کرده و برنامه بلافاصله دچار فروپاشی (Crash) می‌شود.[3][4]

اپل چگونه این مشکل را در Rosetta 2 حل کرد؟ آن‌ها تقلب کردند! مهندسان اپل در طراحی تراشه‌های سری M، یک سوئیچ مخفی سخت‌افزاری به نام بیت TSOEN تعبیه کردند. زمانی که Rosetta یک برنامه x86 را اجرا می‌کند، این سوئیچ را فعال می‌کند. در این حالت، پردازنده ARM اپل قوانین خود را کنار گذاشته و دقیقاً مانند یک پردازنده اینتل با حافظه رفتار می‌کند. این تقلب سخت‌افزاری دلیل اصلی سرعت خیره‌کننده Rosetta 2 است.[1][3]

از سوی دیگر، مایکروسافت و کوالکام این تجملات را در اختیار نداشتند. تراشه‌های Snapdragon X بر اساس طراحی‌های استاندارد ARM ساخته شده‌اند و فاقد این سوئیچ سخت‌افزاری برای تغییر مدل حافظه هستند. بنابراین، شبیه‌ساز Prism باید این نظم را به صورت نرم‌افزاری ایجاد کند.[2][4]

شبیه‌ساز Prism برای جلوگیری از فروپاشی برنامه‌ها، مجبور است «موانع حافظه» (Memory Barriers) را در میان کدها تزریق کند. این موانع مانند تابلوهای ایست نامرئی هستند که پردازنده ARM را مجبور می‌کنند تا تمام شدن یک عملیات صبر کند و سپس به سراغ عملیات بعدی برود. این توقف‌های مداوم، دلیل اصلی افت فریم در بازی‌های ویدیویی روی نسخه‌های اولیه ویندوز ARM بود.[2][4]

با این حال، مهندسی نرم‌افزار در حال پر کردن این شکاف است. در به‌روزرسانی‌های اخیر ویندوز ۱۱ (نسخه 24H2)، مایکروسافت شبیه‌ساز Prism را به شدت ارتقا داد و پشتیبانی از دستورالعمل‌های پیشرفته‌ای مانند AVX و AVX2 را به آن افزود. آن‌ها همچنین الگوریتم‌های تزریق موانع حافظه را بهینه‌تر کردند تا پردازنده کمتر معطل بماند. این تغییرات باعث شد تا برنامه‌های سنگینی مانند Ableton Live و بسیاری از بازی‌ها اکنون با سرعت قابل قبولی روی پردازنده‌های کوالکام اجرا شوند.[2]

در نهایت، این لایه‌های ترجمه قرار نیست برای همیشه باقی بمانند. آن‌ها پل‌هایی موقتی برای عبور از دوران گذار هستند تا زمانی که توسعه‌دهندگان نسخه‌های بومی ARM برنامه‌های خود را منتشر کنند. اما تا آن زمان، Rosetta و Prism به عنوان شاهکارهایی از مهندسی نرم‌افزار نامرئی، به فریب دادن کدهای قدیمی ادامه خواهند داد تا شما هرگز متوجه تغییر زبان در قلب کامپیوترتان نشوید.[5]