رمز الآلة ورمز البايت: ما هي اللغة التي يتحدث بها برنامجك؟

أولئك الذين بدأوا للتو في التعرف على Java غالبًا ما يكون لديهم ارتباك حول مفاهيم كود الآلة ورمز البايت . ما هم؟ ما هي الاختلافات؟ في ملاحظة قصيرة، سنحاول وصف ميزاتها ببساطة ووضوح قدر الإمكان من أجل إغلاق هذه المشكلة مرة واحدة وإلى الأبد.

كود الآلة

المعالج في جوهره عبارة عن آلة حاسبة معقدة ومتقدمة للغاية. يحتوي على العديد من مواقع الذاكرة (تسمى السجلات) والتي يتم من خلالها تنفيذ العمليات الرياضية والبايتات المختلفة. رمز الآلة هو على وجه التحديد وصف لتسلسل العمليات ومجموعة البيانات المعنية. في الواقع، إنها اللغة الوحيدة التي يفهمها معالج جهاز الكمبيوتر الخاص بك.

عدم التوافق الخلقي

وفي الوقت نفسه، لا "تتحدث" جميع المعالجات نفس اللغة. هناك اختلافات ليس فقط بين بنيات CISC و RISC ، ولكن أيضًا داخل هذه "المعسكرات". تقدم الأجيال الجديدة من المعالجات مجموعات إضافية من التعليمات غير المعروفة لنماذج الجيل الأقدم. ولهذا السبب، لا يمكن تشغيل البرامج المترجمة لبنية واحدة (أو جيل واحد من المعالجات) على أجهزة أخرى. كل هذا يجبرنا على إعادة ترجمة البرامج للتأكد من أنها تعمل على أجهزة كمبيوتر أخرى. ومع ذلك، يجب عليك إعادة الترجمة ليس فقط بسبب المعالجات، ولكن أيضًا بسبب الاختلافات في تفاعل البرامج ونظام التشغيل. وبسببهما يستحيل تشغيل برنامج "Windows" تحت نظام Linux، وبرنامج "Linux" تحت نظام Windows.

كود بايت

يشبه Bytecode في كثير من النواحي رمز الجهاز، ولكنه يستخدم فقط مجموعة من التعليمات ليس من معالج حقيقي، ولكن من معالج افتراضي. علاوة على ذلك، قد يتضمن أقسامًا تركز على استخدام مترجم JIT ، الذي يعمل على تحسين تنفيذ الأوامر للمعالج الحقيقي الذي يعمل عليه البرنامج. بالنسبة لمعالجات CISC ، يمكن دمج بعض التعليمات في هياكل أكثر تعقيدًا يدعمها المعالج، وبالنسبة لمعالجات RISC ، على العكس من ذلك، يمكن تقسيمها إلى تسلسلات أبسط من التعليمات.

أيضا نظام تشغيل افتراضي

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

هل JVM هو الوحيد من هذا القبيل؟

بالطبع لا. يعد نفس DotNet CLI أيضًا جهازًا افتراضيًا يتم استخدامه غالبًا على أجهزة الكمبيوتر التي تعمل بنظام Windows مع معالجات متوافقة مع x86. ومع ذلك، هناك تطبيقه لأنظمة أخرى: يجب تشغيل التطبيقات الخاصة به على Windows RT الذي يعمل على معالجات متوافقة مع ARM (RISC) ، أو يمكنك تشغيلها على Linux/OSX في بيئة Mono ، وهي جهة خارجية (وبالتالي غير متوافق تمامًا) تنفيذ DotNet لهذه الأنظمة الأساسية. لذلك، تعمل هذه المنصة، مثل JVM ، على معالجات مختلفة وأنظمة تشغيل مختلفة. هناك العديد من الحلول المشابهة (القديمة والجديدة): LLVM و Flash SWF وغيرها. تمتلك بعض لغات البرمجة أجهزة افتراضية خاصة بها. على سبيل المثال، يقوم CPython بتجميع مصادر PY في ملفات PYC - رمز البايت المترجم والجاهز للتشغيل في PVM . أو هناك مثال أقدم بكثير - يمكن تجميع Lisp في ملفات FASL (التحميل السريع). في الواقع، فهي تحتوي على شجرة AST أنشأها المولد من الكود المصدري. يمكن قراءة هذه الملفات وتنفيذها بواسطة مترجم Lisp على منصات مختلفة، أو استخدامها لإنشاء رمز الجهاز لبنية الأجهزة المستخدمة حاليًا.