مترجم متقاطع

الموسوعة الحرة

المترجم المتقاطع هو مترجم قادر على إنشاء كود قابل للتنفيذ لمنصة مختلفة عن المنصة التي يعمل عليها. على سبيل المثال، المترجم الذي يعمل على جهاز كمبيوتر شخصي ولكنه يُنتج كودًا يعمل على أجهزة أندرويد هو مترجم متقاطع.

يُعدّ المُترجم المتقاطع مفيدًا لترجمة التعليمات البرمجية لمنصات متعددة من جهاز تطوير واحد. قد تكون الترجمة المباشرة على المنصة المستهدفة غير عملية، على سبيل المثال في الأنظمة المُدمجة ذات موارد الحوسبة المحدودة.

تختلف المترجمات المتقاطعة عن المترجمات المصدرية . فالمترجم المتقاطع يُستخدم لتوليد برامج متعددة المنصات بلغة الآلة، بينما يقوم المترجم المصدري بترجمة التعليمات البرمجية من لغة برمجة إلى أخرى باستخدام نص برمجي. وكلاهما أدوات برمجة .

يستخدم

يتمثل الاستخدام الأساسي للمترجم المتقاطع في فصل بيئة البناء عن بيئة الهدف. وهذا مفيد في عدة حالات:

  • الحواسيب المدمجة هي أجهزة ذات موارد محدودة للغاية. على سبيل المثال، يحتوي فرن الميكروويف على حاسوب صغير جدًا لقراءة لوحة المفاتيح ومستشعر الباب، وتوفير مخرجات لشاشة عرض رقمية ومكبر صوت، والتحكم في الميكروويف لطهي الطعام. عادةً ما يكون هذا الحاسوب غير قادر على تشغيل مُترجم برمجي، أو نظام ملفات، أو بيئة تطوير.
  • إمكانية الترجمة البرمجية لأجهزة متعددة. على سبيل المثال، قد ترغب شركة ما في دعم عدة إصدارات مختلفة من نظام تشغيل واحد، أو دعم عدة أنظمة تشغيل مختلفة. باستخدام مترجم متقاطع، يمكن إعداد بيئة بناء واحدة للترجمة البرمجية لكل من هذه الأنظمة المستهدفة.
  • التجميع على مزرعة خوادم . على غرار التجميع لأجهزة متعددة، يمكن تنفيذ عملية بناء معقدة تتضمن العديد من عمليات التجميع على أي جهاز متاح، بغض النظر عن مكوناته المادية الأساسية أو إصدار نظام التشغيل الذي يعمل عليه.
  • الانتقال إلى منصة جديدة. عند تطوير برامج لمنصة جديدة، أو محاكي لمنصة مستقبلية، يتم استخدام مترجم متقاطع لتجميع الأدوات الضرورية مثل نظام التشغيل ومترجم أصلي.
  • تجميع التعليمات البرمجية الأصلية لمحاكيات المنصات القديمة التي عفا عليها الزمن مثل Commodore 64 أو Apple II بواسطة المتحمسين الذين يستخدمون المترجمات المتقاطعة التي تعمل على منصة حالية (مثل مترجمات Aztec C المتقاطعة MS-DOS 6502 التي تعمل تحت Windows XP ).

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

عادة ما تختلف بنية الأجهزة (على سبيل المثال، كتابة برنامج مخصص لبنية MIPS على جهاز كمبيوتر x86 ) ولكن يمكن أيضًا استخدام الترجمة المتقاطعة عندما تختلف بيئة نظام التشغيل فقط ، كما هو الحال عند تجميع برنامج FreeBSD تحت Linux ، أو حتى مكتبة النظام فقط، كما هو الحال عند تجميع البرامج باستخدام uClibc على مضيف glibc .

الصليب الكندي

تُعدّ تقنية " الصليب الكندي" أسلوبًا لبناء مُترجمات هجينة لأجهزة أخرى، حيث يكون الجهاز الأصلي أبطأ بكثير أو أقل ملاءمة من الجهاز المستهدف. لنفترض وجود ثلاثة أجهزة A وB وC، نستخدم الجهاز A (على سبيل المثال، يعمل بنظام Windows XP على معالج IA-32 ) لبناء مُترجم هجين يعمل على الجهاز B (على سبيل المثال، يعمل بنظام macOS على معالج x86-64 ) لإنشاء ملفات تنفيذية للجهاز C (على سبيل المثال، يعمل بنظام Android على معالج ARM ). تكمن الميزة العملية في هذا المثال في أن الجهاز A بطيء ولكنه مزود بمُترجم خاص، بينما الجهاز B سريع ولكنه لا يحتوي على مُترجم على الإطلاق، أما الجهاز C فهو بطيء للغاية بحيث لا يُمكن استخدامه عمليًا في عملية الترجمة.

عند استخدام الصليب الكندي مع مجلس التعاون الخليجي، وكما هو الحال في هذا المثال، قد يكون هناك أربعة مُجمِّعين مشاركين.

  • يتم استخدام المترجم الأصلي الخاص بالجهاز A (1) (على سبيل المثال المترجم من Microsoft Visual Studio ) لإنشاء المترجم الأصلي gcc للجهاز A (2) .
  • يتم استخدام مترجم gcc الأصلي للجهاز A (2) لبناء مترجم gcc المتقاطع من الجهاز A إلى الجهاز B (3).
  • يتم استخدام مترجم gcc المتقاطع من الجهاز A إلى الجهاز B (3) لبناء مترجم gcc المتقاطع من الجهاز B إلى الجهاز C (4).

مثال على مخطط الصليب الكندي

لن يتمكن المترجم المتقاطع للنتيجة النهائية (4) من التشغيل على جهاز البناء A؛ بدلاً من ذلك، سيتم تشغيله على الجهاز B لتجميع تطبيق في رمز قابل للتنفيذ والذي سيتم نسخه بعد ذلك إلى الجهاز C وتنفيذه على الجهاز C.

على سبيل المثال، يوفر NetBSD برنامج نصي POSIX Unix shell يسمى والذي سيقوم أولاً ببناء سلسلة الأدواتbuild.sh الخاصة به باستخدام مترجم المضيف؛ وهذا بدوره سيتم استخدامه لبناء المترجم المتقاطع الذي سيتم استخدامه لبناء النظام بأكمله.

نشأ مصطلح الصليب الكندي لأنه في ذلك الوقت الذي كانت فيه هذه القضايا قيد المناقشة، كان لدى كندا ثلاثة أحزاب سياسية وطنية. [ 1 ]

الجدول الزمني للمترجمات المتقاطعة المبكرة

  • 1969 – طُوِّرت النسخة الأولى من نظام يونكس على يد كين تومسون باستخدام جهاز PDP-7 ، ولكن نظرًا لنقص الأدوات وارتفاع التكلفة، جرى تجميعها برمجيًا على نظام GECOS ونقلها عبر شريط ورقي . وقد أظهر ذلك جدوى التجميع البرمجي المتقاطع في تطوير أنظمة التشغيل. [ 2 ]
  • في عام 1979، أنتجت لغة ALGOL 68C برنامج ZCODE ، مما سهّل نقل المترجم وتطبيقات ALGOL 68 الأخرى إلى منصات بديلة. تطلّب تجميع مترجم ALGOL 68C حوالي 120  كيلوبايت من الذاكرة. أما مع معالج Z80، فإنّ ذاكرته البالغة 64  كيلوبايت صغيرة جدًا بحيث لا تكفي لتجميع المترجم فعليًا. لذا، كان لا بدّ من تجميع المترجم نفسه باستخدام حاسوب CAP ذي القدرات الأكبر أو حاسوب IBM System/370 المركزي.
  • في ثمانينيات القرن العشرين، قدمت لغة Aztec C إمكانية الترجمة الأصلية والترجمة المتقاطعة لأجهزة الكمبيوتر المنزلية مثل Apple II و Commodore 64 .

GCC والتجميع المتقاطع

يمكن إعداد GCC ، وهي مجموعة برامج مجانية من المترجمات، للترجمة المتقاطعة. وهي تدعم العديد من المنصات واللغات.

يتطلب GCC توفر نسخة مُجمّعة من binutils لكل منصة مُستهدفة. ويُعدّ مُجمّع GNU Assembler بالغ الأهمية . لذا، يجب أولاً تجميع binutils بشكل صحيح باستخدام الخيار --target=some-targetالمُرسل إلى سكربت التهيئة . كما يجب تهيئة GCC بنفس --targetالخيار. بعد ذلك، يُمكن تشغيل GCC بشكل طبيعي شريطة أن تكون الأدوات التي يُنشئها binutils مُتاحة في المسار ، وهو ما يُمكن فعله باستخدام الأمر التالي (على أنظمة التشغيل الشبيهة بـ UNIX مع bash):

PATH=/path/to/binutils/bin:${PATH} make

يتطلب تجميع GCC المتقاطع توفر جزء من مكتبة C القياسية الخاصة بالمنصة المستهدفة على المنصة المضيفة . يمكن للمبرمج اختيار تجميع مكتبة C كاملة، لكن هذا الخيار قد يكون غير موثوق. البديل هو استخدام newlib ، وهي مكتبة C صغيرة تحتوي فقط على المكونات الأساسية اللازمة لتجميع شفرة مصدر C.

تستخدم حزم GNU Autotools (مثل autoconf و automake و libtool ) مفهوم منصة البناء ، ومنصة الاستضافة ، ومنصة الهدف . منصة البناء هي المكان الذي يُجرى فيه تجميع المُصرّف فعليًا. في معظم الحالات، يُفضّل ترك قيمة منصة البناء غير مُحدّدة (حيث تُستخدَم افتراضيًا منصة الاستضافة). منصة الاستضافة هي المكان الذي تُنفَّذ فيه مُخرجات المُصرّف، سواءً كان المُخرج مُصرّفًا آخر أم لا. تُستخدم منصة الهدف عند التجميع المُتقاطع للمُصرّفات المُتقاطعة، وهي تُمثّل نوع كود الكائن الذي ستُنتجه الحزمة؛ وإلا فإن إعداد منصة الهدف غير ذي صلة. [ 3 ] على سبيل المثال، لنفترض أننا نُجري تجميعًا مُتقاطعًا للعبة فيديو ستعمل على جهاز Dreamcast . الجهاز الذي تُجمَّع عليه اللعبة هو منصة البناء، بينما جهاز Dreamcast هو منصة الاستضافة . يُشير اسما "الاستضافة" و "الهدف" إلى المُصرّف المُستخدم، ويتم تغيير ترتيبهما كما في "الابن" و "الحفيد" . [ 4 ]

هناك طريقة أخرى شائعة الاستخدام بين مطوري أنظمة لينكس المدمجة، وهي دمج مُجمِّعات GCC مع بيئات معزولة متخصصة مثل Scratchbox و Scratchbox 2 أو PRoot . تُنشئ هذه الأدوات بيئة معزولة " مُقيدة" (chrooted ) حيث يُمكن للمبرمج بناء الأدوات ومكتبة libc والمكتبات اللازمة دون الحاجة إلى تحديد مسارات إضافية. كما تُوفر هذه الأدوات إمكانية "خداع" بيئة التشغيل بحيث "تعتقد" أنها تعمل فعليًا على وحدة المعالجة المركزية المستهدفة (مثل معمارية ARM)؛ مما يسمح بتشغيل نصوص التهيئة وما شابهها دون أخطاء. يعمل Scratchbox بشكل أبطأ مقارنةً بالطرق "غير المُقيدة"، ويجب نقل معظم الأدوات الموجودة على النظام المضيف إلى Scratchbox لكي تعمل.

مترجمات مانكس أزتيك سي المتقاطعة

قامت شركة Manx Software Systems ، ومقرها شروزبري ، نيو جيرسي ، بإنتاج مترجمات لغة C بدءًا من ثمانينيات القرن الماضي، والتي استهدفت المطورين المحترفين لمجموعة متنوعة من المنصات وصولاً إلى أجهزة الكمبيوتر الشخصية المتوافقة مع IBM وأجهزة Mac .

كانت لغة البرمجة Aztec C الخاصة بـ Manx متاحة لمجموعة متنوعة من المنصات بما في ذلك MS-DOS و Apple II و DOS 3.3 و ProDOS و Commodore 64 و Mac 68k [ 5 ] و Amiga .

منذ ثمانينيات القرن العشرين وحتى تسعينياته، وحتى اختفاء شركة مانكس لأنظمة البرمجيات، تم توفير نسخة MS-DOS من لغة Aztec C [ 6 ] كمترجم أصلي أو كمترجم متقاطع لمنصات أخرى بمعالجات مختلفة، بما في ذلك كومودور 64 [ 7 ] وأبل 2 [ 8 ] . ولا تزال توزيعات الإنترنت للغة Aztec C، بما فيها المترجمات المتقاطعة الخاصة بها والمبنية على نظام MS-DOS، مستخدمة حتى اليوم.

كان برنامج Aztec C86 من شركة Manx، وهو برنامج تجميعي أصلي لنظام MS-DOS يعمل بمعالج 8086 ، برنامج تجميعي متقاطع أيضًا. ورغم أنه لم يُجمّع التعليمات البرمجية لمعالج مختلف مثل برامج Aztec C65 6502 التجميعية المتقاطعة لأجهزة Commodore 64 وApple II، إلا أنه كان يُنشئ ملفات تنفيذية ثنائية لأنظمة التشغيل القديمة آنذاك لعائلة معالجات 8086 ذات 16 بت.

عندما طُرح جهاز IBM PC لأول مرة، كان متوفرًا بخيارين من أنظمة التشغيل، أحدهما CP/M-86 والآخر PC DOS . زُوّد برنامج Aztec C86 بمكتبات ربط لتوليد التعليمات البرمجية لكلا نظامي تشغيل IBM PC . خلال ثمانينيات القرن الماضي، أضافت الإصدارات اللاحقة من Aztec C86 (3.xx، 4.xx، و5.xx) دعمًا لإصداري MS-DOS "المؤقتين" 1 و2 [ 9 ]، واللذين كانا أقل استقرارًا من إصدار MS-DOS "الأساسي" 3 والإصدارات اللاحقة التي استهدفها Aztec C86 حتى توقفه عن العمل.

أخيرًا، مكّن معالج Aztec C86 مطوري لغة C من إنتاج شفرة "HEX" قابلة للتخزين في ذاكرة ROM ، والتي يمكن نقلها مباشرةً إلى معالج 8086 باستخدام ناسخ ROM . قد يكون المحاكاة الافتراضية الجزئية أكثر شيوعًا اليوم، لكن ممارسة إنشاء شفرة ROM منخفضة المستوى كانت أكثر انتشارًا في تلك السنوات، حيث كان تطوير برامج تشغيل الأجهزة يتم غالبًا بواسطة مبرمجي التطبيقات لتطبيقات فردية، وكانت الأجهزة الجديدة تُشكل صناعة منزلية . لم يكن من النادر أن يتفاعل مبرمجو التطبيقات مباشرةً مع الأجهزة دون دعم من الشركة المصنعة. تشبه هذه الممارسة تطوير الأنظمة المدمجة اليوم.

كان توماس فينويك وجيمس جودناو الثاني هما المطوران الرئيسيان لبرنامج Aztec-C. وقد اشتهر فينويك لاحقًا كمؤلف نواة نظام التشغيل Microsoft Windows CE أو NK ("النواة الجديدة") كما كانت تسمى آنذاك. [ 10 ]

مترجمات لغة C المتقاطعة من مايكروسوفت

التاريخ المبكر – ثمانينيات القرن العشرين

تتمتع لغة مايكروسوفت سي (MSC) بتاريخ أقصر من غيرها [ 11 ] ، إذ يعود تاريخها إلى ثمانينيات القرن الماضي. وقد صُنعت أولى مُجمّعات مايكروسوفت سي من قِبل الشركة نفسها التي صنعت لاتيس سي ، ثم أعادت مايكروسوفت تسميتها لتصبح علامتها التجارية الخاصة، إلى أن صدر الإصدار الرابع من MSC، وهو أول إصدار أنتجته مايكروسوفت بنفسها. [ 12 ]

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

كانت لغة البرمجة Borland C (شركة من كاليفورنيا) متاحة للشراء قبل سنوات من إصدار مايكروسوفت لأول منتج لها بلغة C.

1987

لطالما ارتبطت برامج لغة C بوحدات مكتوبة بلغة التجميع . توفر معظم مترجمات لغة C (حتى المترجمات الحالية) مرحلة لغة التجميع (التي يمكن تعديلها لتحسين الكفاءة ثم ربطها ببقية البرنامج بعد التجميع).

كانت المترجمات مثل Aztec-C تحوّل كل شيء إلى لغة التجميع في خطوة منفصلة، ​​ثم تُجمّع الكود في خطوة منفصلة أخرى، واشتهرت بكفاءتها العالية وصغر حجم الكود. ولكن بحلول عام 1987، كان مُحسِّن الأداء المُدمج في لغة Microsoft C متطورًا للغاية، ولم يعد يُعاد كتابة سوى الأجزاء "البالغة الأهمية" من البرنامج. في الواقع، أصبحت لغة البرمجة C هي اللغة "الأدنى مستوى"، مع تحوّل البرمجة إلى صناعة متعددة التخصصات ومتنامية، وتزايد حجم المشاريع، حيث يكتب المبرمجون واجهات المستخدم وواجهات قواعد البيانات بلغات برمجة عالية المستوى، وبرزت الحاجة إلى تطوير البرامج متعددة اللغات، وهي حاجة لا تزال قائمة حتى اليوم.

بحلول عام 1987، ومع إصدار MSC 5.1، وفرت مايكروسوفت بيئة تطوير متعددة اللغات لنظام MS-DOS. كان بالإمكان ربط كود الكائن الثنائي ذي 16 بت المكتوب بلغة التجميع ( MASM ) مع لغات مايكروسوفت الأخرى، بما في ذلك QuickBASIC و Pascal و Fortran ، في برنامج واحد، في عملية أطلقوا عليها اسم "البرمجة متعددة اللغات" وتُعرف الآن باسم "استدعاء اللغات المتداخلة". [ 13 ] إذا استُخدمت لغة BASIC في هذا المزيج، كان البرنامج الرئيسي يجب أن يكون مكتوبًا بلغة BASIC لدعم نظام التشغيل الداخلي الذي يُجمّع لغة BASIC اللازمة لجمع البيانات المهملة والعمليات المُدارة الأخرى التي تُحاكي مُفسّر BASIC مثل QBasic في MS-DOS.

كانت آلية استدعاء الدوال في لغة C، على وجه الخصوص، تتمثل في تمرير المعاملات بترتيب عكسي على المكدس وإرجاع القيم عليه بدلاً من سجلات المعالج . كانت هناك قواعد برمجة أخرى لضمان توافق جميع اللغات، لكن هذه القاعدة تحديدًا استمرت خلال تطوير البرامج متعددة اللغات، والذي شمل إصدارات ويندوز 16 و32 بت، وتطوير برامج نظام التشغيل OS/2 ، ولا يزال ساريًا حتى اليوم. تُعرف هذه الآلية بآلية استدعاء الدوال في لغة باسكال .

كان أحد أنواع الترجمة المتقاطعة التي استخدمتها مايكروسوفت بلغة C خلال تلك الفترة هو استخدامها في تطبيقات البيع بالتجزئة التي تتطلب أجهزة محمولة مثل جهاز Symbol Technologies PDT3100 (المستخدم لجرد المخزون )، والذي كان يوفر مكتبة ربط تستهدف قارئ الباركود القائم على معالج 8088. كان يتم بناء التطبيق على الحاسوب المضيف ثم نقله إلى الجهاز المحمول (عبر كابل تسلسلي ) حيث يتم تشغيله، على غرار ما يتم فعله اليوم لنفس السوق باستخدام نظام التشغيل Windows Mobile من قبل شركات مثل موتورولا ، التي استحوذت على Symbol.

أوائل التسعينيات

خلال تسعينيات القرن الماضي، وبدءًا من MSC 6 (أول مُترجم متوافق مع معيار ANSI C )، أعادت مايكروسوفت تركيز مُترجمات لغة C الخاصة بها على سوق ويندوز الناشئ، وكذلك على نظام التشغيل OS/2 وتطوير برامج واجهة المستخدم الرسومية . استمر التوافق بين اللغات المختلفة حتى MSC 6 على نظام MS-DOS، ولكن واجهة برمجة التطبيقات (API) لنظامي التشغيل مايكروسوفت ويندوز 3.0 و3.1 كُتبت بلغة MSC 6. كما تم توسيع MSC 6 لدعم تجميعات 32 بت ودعم نظامي التشغيل الناشئين ويندوز لمجموعات العمل وويندوز NT، اللذين شكّلا الأساس لنظام ويندوز XP . تم تقديم ممارسة برمجية تُسمى " thunk" للسماح بالتحويل بين برامج 16 بت و32 بت، والتي استفادت من الربط الديناميكي ( الربط أثناء التشغيل ) بدلاً من الربط الثابت الذي كان مُفضلاً في تطبيقات MS-DOS المتجانسة 16 بت. لا يزال الربط الثابت مُفضلاً لدى بعض مطوري البرامج الأصلية، ولكنه لا يُوفر عمومًا درجة إعادة استخدام الكود المطلوبة وفقًا لأفضل الممارسات الحديثة، مثل نموذج نضج القدرات (CMM).

تم توفير دعم MS-DOS مع إصدار أول مترجم C++ من مايكروسوفت، MSC 7، والذي كان متوافقًا مع الإصدارات السابقة من لغة البرمجة C وMS-DOS وكان يدعم توليد التعليمات البرمجية 16 بت و32 بت.

استكملت شركة MSC المسيرة من حيث توقفت شركة Aztec C86 . وتحولت حصة سوق مترجمات لغة C إلى المترجمات المتقاطعة التي استفادت من أحدث وأفضل ميزات نظام التشغيل Windows، وقدمت لغتي C وC++ في حزمة واحدة، وما زالت تدعم أنظمة MS-DOS التي مضى عليها عقد من الزمان، ولم تعد الشركات الصغيرة التي أنتجت مترجمات مثل Aztec C قادرة على المنافسة، فاتجهت إما إلى أسواق متخصصة مثل الأنظمة المدمجة أو اختفت.

استمر دعم MS-DOS وتوليد التعليمات البرمجية 16 بت حتى MSC 8.00c الذي تم تضمينه مع Microsoft C++ و Microsoft Application Studio 1.5، وهو الإصدار السابق لـ Microsoft Visual Studio الذي يمثل بيئة التطوير المتقاطع التي توفرها Microsoft اليوم.

أواخر التسعينيات

تم إصدار MSC 12 مع Microsoft Visual Studio 6، ولم يعد يدعم ملفات MS-DOS الثنائية ذات 16 بت، بل أصبح يدعم تطبيقات سطر الأوامر ذات 32 بت، ولكنه كان يدعم توليد التعليمات البرمجية لأنظمة Windows 95 و Windows 98 ، بالإضافة إلى Windows NT . وكانت مكتبات الربط متاحة لمعالجات أخرى تعمل بنظام Microsoft Windows، وهي ممارسة لا تزال Microsoft تتبعها حتى اليوم.

تم إصدار MSC 13 مع Visual Studio 2003 ، وتم إصدار MSC 14 مع Visual Studio 2005 ، وكلاهما لا يزال ينتج التعليمات البرمجية للأنظمة القديمة مثل Windows 95، ولكنهما سينتجان التعليمات البرمجية للعديد من المنصات المستهدفة بما في ذلك سوق الأجهزة المحمولة وبنية ARM .

.NET وما بعده

في عام 2001، طورت مايكروسوفت بيئة التشغيل المشتركة للغة (CLR)، والتي شكلت النواة الأساسية لمترجم إطار عمل .NET في بيئة التطوير المتكاملة Visual Studio. تتيح هذه الطبقة الموجودة في واجهة برمجة التطبيقات (API) على نظام التشغيل دمج لغات البرمجة المُجمّعة عبر منصات مختلفة تعمل بنظام التشغيل ويندوز.

توفر بيئة تشغيل .NET Framework وCLR طبقة ربط بين الإجراءات الأساسية للمعالج والأجهزة على الحاسوب المستهدف. يقوم مُصرّف لغة C في سطر الأوامر في Visual Studio بتجميع التعليمات البرمجية الأصلية لمجموعة متنوعة من المعالجات، ويمكن استخدامه لبناء الإجراءات الأساسية نفسها.

تطبيقات Microsoft .NET للأنظمة الأساسية المستهدفة مثل Windows Mobile على بنية ARM يتم تجميعها بشكل متقاطع على أجهزة Windows مع مجموعة متنوعة من المعالجات، كما تقدم Microsoft أيضًا برامج محاكاة وبيئات نشر عن بعد تتطلب القليل جدًا من التكوين، على عكس برامج التجميع المتقاطع في الأيام الخوالي أو على الأنظمة الأساسية الأخرى.

توفر مكتبات وقت التشغيل، مثل Mono ، التوافق لبرامج .NET المترجمة بشكل متقاطع مع أنظمة تشغيل أخرى، مثل Linux .

توفر مكتبات مثل Qt وأسلافها، بما في ذلك XVT، إمكانية تطوير البرامج عبر منصات متعددة على مستوى الكود المصدري، مع الاستمرار في استخدام لغة Microsoft C لبناء إصدارات Windows. كما اكتسبت مُجمِّعات أخرى مثل MinGW شعبية في هذا المجال نظرًا لتوافقها المباشر مع أنظمة Unix التي تُشكِّل الجانب غير Windows من تطوير البرامج، مما يسمح للمطورين باستهداف جميع المنصات باستخدام بيئة بناء مألوفة.

فري باسكال

طُوِّرت لغة Free Pascal منذ البداية كمترجم متقاطع. يستطيع ملف المترجم التنفيذي (ppcXXX حيث XXX هي بنية النظام المستهدفة) إنتاج ملفات تنفيذية (أو ملفات كائنية فقط في حال عدم وجود رابط داخلي، أو حتى ملفات تجميع فقط في حال عدم وجود مُجمِّع داخلي) لجميع أنظمة التشغيل التي تنتمي إلى نفس البنية. على سبيل المثال، يستطيع ppc386 إنتاج ملفات تنفيذية لأنظمة i386-linux وi386-win32 وi386-go32v2 (DOS) وجميع أنظمة التشغيل الأخرى (انظر [ 14 ] ). ولكن، للترجمة إلى بنية أخرى، يجب أولاً إنشاء نسخة من المترجم متوافقة مع البنية المتقاطعة. سيحتوي الملف التنفيذي الناتج للمترجم على كلمة "ross" قبل اسم بنية النظام المستهدفة. أي، إذا تم إنشاء المترجم لاستهداف x64، فسيكون اسم الملف التنفيذي ppcrossx64.

للتجميع لنظام تشغيل ذي بنية معمارية محددة، يمكن استخدام مفتاحي المُجمِّع -P و-T (لبرنامج تشغيل المُجمِّع fpc). يُستخدم هذا الخيار أيضًا عند التجميع المتقاطع للمُجمِّع نفسه، ولكن يتم ضبطه عبر خياري التجميع CPU_TARGET وOS_TARGET. يلزم وجود مُجمِّع ورابط GNU للمنصة المستهدفة إذا لم يكن لدى Free Pascal إصدار داخلي من الأدوات الخاصة بها.

كلانغ

يُعد Clang في الأصل مُترجمًا متقاطعًا، ويمكنك أثناء عملية البناء تحديد البنى التي تريد أن يكون Clang قادرًا على استهدافها باستخدام -targetالعلامة. [ 15 ]

الخطة 9

لا يُميّز نظام Plan 9 غير المتجانس ومجموعة أدواته بين الترجمة المتقاطعة والترجمة الأصلية. ملفات Makefiles مستقلة عن بنية النظام.

انظر أيضاً

مراجع

  1. ↑ "4.9 الصلبان الكندية" . CrossGCC . مؤرشف من الأصل في 9 أكتوبر 2004. تم الاطلاع عليه في 8 أغسطس 2012. يُطلق على هذا اسم "الصليب الكندي" لأنه في ذلك الوقت، كانت كندا تضم ​​ثلاثة أحزاب وطنية.
  2. ↑ ريتشي، د.م. (أكتوبر 1984). "نظام يونكس: تطور نظام يونكس لتقاسم الوقت" . المجلة التقنية لمختبرات إيه تي آند تي بيل . 63 (8): 1577-1593 . doi : 10.1002/j.1538-7305.1984.tb00054.x .
  3. ↑ "التجميع المتقاطع (Automake)" .
  4. ↑ "تجميع متقاطع" .
  5. ↑ "أجهزة كمبيوتر ماكنتوش القديمة" . مؤرشف من الأصل بتاريخ 26 فبراير 2008. تم الاطلاع عليه بتاريخ 10 مارس 2008 .
  6. ↑ أزتيك سي
  7. ↑ كومودور 64
  8. ↑ أبل 2
  9. ↑ الجدول الزمني لنظام MS-DOS ، مؤرشف بتاريخ 1 مايو 2008 في أرشيف الإنترنت (Wayback Machine).
  10. ↑ داخل نظام التشغيل Windows CE (ابحث عن Fenwick)
  11. ↑ سجل إصدارات أداة لغة مايكروسوفت
  12. ↑ تاريخ مُجمِّعات لغة C على أجهزة الكمبيوتر الشخصية (مؤرشف في 15 ديسمبر 2007، على موقع Wayback Machine)
  13. ↑ ما هي الإصدارات الأساسية التي يمكنها استدعاء لغات C و FORTRAN و Pascal و MASM؟
  14. ↑ "قائمة المنصات المدعومة بلغة Free Pascal" . قائمة المنصات . تم الاطلاع عليها بتاريخ 17 يونيو 2010. i386
  15. ↑ "الترجمة المتقاطعة باستخدام Clang" . llvm.org . تم الاطلاع عليه في 1 مارس 2026 .