كيف تعمل ترجمة x86 على Windows on Arm؟

لقد تم إنشاء Windows دائمًا من أجل وحدات المعالجة المركزية x86 من Intel وAMD، ولكن منذ ظهور Windows RT قبل عقد من الزمن للهواتف الذكية، أصبح نظام التشغيل أكثر ملاءمةً له ببطء وحدات المعالجة المركزية الذراع. اليوم، يقدم كل من Windows 10 وWindows 11 دعمًا كاملاً لوحدات المعالجة المركزية Arm، ولكن هناك مشكلة. في حين أن نظام التشغيل نفسه يعمل بشكل جيد على وحدات المعالجة المركزية هذه، فإن معظم التطبيقات لم تطلق إصدارًا متوافقًا مع Arm. على الرغم من أنه يمكن تشغيل Windows على شرائح Arm، إلا أن وجود عدد قليل من البرامج لاستخدامها فعليًا قد يمثل مشكلة.

ومع ذلك، لدى مايكروسوفت خدعة في جعبتها: محاكي لتشغيل تطبيقات x86 على الأجهزة المستندة إلى Arm. إنه الشيء الأساسي الذي أعطى Windows on Arm زخمه منذ ظهور المترجم في عام 2017. إليك كيفية عمل المحاكي، ولماذا تحتاج أجهزة كمبيوتر Arm إلى استخدامه إذا أرادت تشغيل البرامج المصممة لشرائح x86.

محاكاة كود x86 لوحدات المعالجة المركزية Arm في الوقت الفعلي

إن فكرة محاكاة التعليمات البرمجية المصممة لنوع واحد من المعالجات بحيث يمكن تشغيلها على نوع آخر ليست جديدة. هذه هي الطريقة التي تعمل بها محاكاة الألعاب، والتي تُستخدم بشكل شائع لتشغيل ألعاب الفيديو القديمة على أجهزة جديدة بأجهزة مختلفة تمامًا. عند تشغيل تطبيق x86 على كمبيوتر Arm، يأخذ Windows كتلًا من التعليمات البرمجية للتطبيق ويجمعها في شيء يمكن تشغيله على شريحة Arm. يتم كل هذا في الوقت الفعلي، ويجب على Windows تخزين كل التعليمات البرمجية التي تمت ترجمتها مؤقتًا، مما يعني أنه ليس من الضروري إعادة ترجمتها مرارًا وتكرارًا.

لسوء الحظ، سيكون الأداء أسوأ في التطبيقات التي تمت محاكاتها مقارنة بالكود المصمم للأجهزة. من الصعب تحديد مقدار الأداء الذي تخسره عند تشغيل تعليمات برمجية تمت محاكاتها على Windows نظرًا لأن بيانات الاختبار قليلة للغاية، ولكن للمقارنة، مترجم أبل روزيتا 2 (الذي يترجم أيضًا تطبيقات x86 إلى Arm) يفقد حوالي 20%. من الممكن تقليل هذا الرقم، ولكن عادةً ما تؤدي المحاكاة والترجمة إلى عقوبة الأداء مهما كانت الظروف.

لماذا لا يمكن تشغيل تطبيقات x86 على Arm بدون مضاهاة

ربما تتساءل عن سبب ضرورة كتابة البرامج خصيصًا لـ x86 وArm وأنواع أخرى من وحدات المعالجة المركزية (CPUs). يتعلق الأمر ب الفرق في الهندسة المعمارية، وفي هذه الحالة، نحن نتحدث عن بنية مجموعة التعليمات (ISA). إنها التصميم الأساسي للمعالج وتحدد ما إذا كان يمكن إجراء شيء بسيط مثل الضرب أو شيء معقد مثل AVX محليًا. يؤثر تغيير ISA على الطريقة الأساسية التي يتفاعل بها البرنامج مع الأجهزة، وصولاً إلى الأصفار والأصفار الأساسية التي تقرأها وحدة المعالجة المركزية.

x86 هو ISA لوحدات المعالجة المركزية Intel وAMD، والتي كانت تاريخيًا وحدات المعالجة المركزية الوحيدة التي يمكن لنظام التشغيل Windows تشغيلها عليها. وفي الوقت نفسه، يتم استخدام Arm في الغالب للهواتف الذكية، والتداخل بين برامج الكمبيوتر وبرامج الهاتف قليل جدًا. وبطبيعة الحال، فإن معظم البرامج إما مصممة لـ x86 أو Arm، وبالنسبة لنظام Windows on Arm، كانت هذه مشكلة كبيرة لأن لم تظهر الترجمة في عام 2020، بينما ظهر Windows RT (الإصدار الأول من Windows الذي يدعم Arm) في عام 2020. 2012.

لقد مر عقد من الزمان تقريبًا منذ أن بدأ Windows في دعم Arm، فأين جميع التطبيقات الأصلية؟ المشكلة الأساسية هي أن الأمر يستغرق وقتًا وخبرة لإعادة كتابة البرامج لـ ISA مختلف، خاصة إذا أراد المطورون القيام بذلك بشكل جيد. يمكن للمطورين الذين لا يتخذون الرعاية المناسبة لنقل التطبيق من ISA إلى آخر أن يؤديوا إلى حدوث خلل وأخطاء. مثال رائع على ذلك هو Photoshop لنظام التشغيل Windows on Arm. يتم تشغيله أصلاً على Windows on Arm، حتى الآن في مراجعتنا لجهاز Lenovo Thinkpad X13s، لقد واجهنا العديد من الأخطاء والكثير من التحذيرات بأن OpenCL وOpenGL غير مدعومين. إلى جانب قاعدة مستخدمين أصغر بكثير يستخدمون Arm على Windows، هناك حافز أقل للمطورين للاهتمام.

لذلك، عندما لا يتمكن المطورون أو لا يرغبون في تخصيص الموارد لإنشاء برامج أصلية، فإن البديل هو المحاكاة. على الرغم من أن ترجمة تطبيقات x86 لنظام التشغيل Windows on Arm ليست مثالية، إلا أنه من المثير للإعجاب أنها تعمل على الإطلاق، وفي بعض الأحيان يكون فقدان الأداء أمرًا يستحق معرفة أن التطبيق سيعمل كما هو متوقع. على الأقل حتى يصل Windows on Arm إلى النقطة التي لم يعد بإمكان المطورين تجاهلها، فإن الترجمة والمحاكاة تمنحه دفعة تشتد الحاجة إليها في النظام البيئي للأجهزة والبرمجيات.