مُجمِّع متقاطع

تنفيذ البرنامج
المفاهيم العامة
شفرة ترجمة المُجمِّع وقت التجميع تحسين المترجم التمثيل المتوسط ​​(IR) تنفيذ نظام التشغيل وقت التشغيل قابل للتنفيذ مترجم آلة افتراضية
أنواع الكود
الكود المصدر كود الكائن البايت كود كود الآلة الكود الصغير
استراتيجيات التجميع
مقدمًا في الوقت المحدد (AOT) التسليم في الوقت المناسب (JIT) التتبع في الوقت المناسب تجميع النظام والذهاب إليه التجميع المسبق الترجمة التجميعية إعادة التجميع
أوقات التشغيل البارزة
وقت تشغيل Android (ART) شعاع (إرلانج) وقت تشغيل اللغة المشتركة (CLR) و  Mono CPython و  PyPy crt0 ( مبدئ خاص بالهدف C ) آلة جافا الافتراضية (JVM) لواجيت Objective -C و  Swift V8 و  Node.js محرك Zend (PHP)
المترجمون وسلاسل الأدوات المشهورة
مجموعة مُجمِّعات جنو (GCC) LLVM و  Clang ام اس في سي
ف ت هـ

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

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

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

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

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

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

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

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

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

• يتم استخدام المترجم الأصلي الخاص بالجهاز 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 يسمى والذي سيقوم أولاً ببناء سلسلة أدواتهbuild.sh الخاصة مع مُجمِّع المضيف؛ وسيتم استخدام هذا، بدوره، لبناء المُجمِّع المتقاطع الذي سيتم استخدامه لبناء النظام بأكمله.

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

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

• 1979 – قام ALGOL 68C بإنشاء ZCODE ؛ ساعد هذا في نقل المترجم وتطبيقات ALGOL 68 الأخرى إلى منصات بديلة. يتطلب تجميع مترجم ALGOL 68C حوالي 120 كيلوبايت من الذاكرة. مع Z80، تكون ذاكرته التي تبلغ 64 كيلوبايت صغيرة جدًا لتجميع المترجم فعليًا. لذلك بالنسبة لـ Z80، كان لا بد من تجميع المترجم نفسه من كمبيوتر أكبر مزود بإمكانية CAP أو حاسب مركزي IBM System/370 .

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

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

PATH=/path/to/binutils/bin:${PATH} إنشاء

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

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

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

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

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

منذ ثمانينيات القرن العشرين وحتى اختفاء شركة Manx Software Systems، تم تقديم إصدار MS-DOS من Aztec C ^[5] كمترجم أصلي أو كمترجم متقاطع لمنصات أخرى ذات معالجات مختلفة بما في ذلك Commodore 64 ^[6] وApple II. ^[7] لا تزال توزيعات الإنترنت موجودة لـ Aztec C بما في ذلك المترجمين المتقاطعين المستندين إلى MS-DOS. لا تزال قيد الاستخدام حتى اليوم.

كان برنامج Aztec C86 من Manx، وهو برنامج التجميع الأصلي 8086 MS-DOS، برنامج تجميع متقاطع أيضًا. ورغم أنه لم يقم بتجميع التعليمات البرمجية لمعالج مختلف مثل برنامج التجميع المتقاطع 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 ^[8] والتي كانت أقل قوة من إصدار MS-DOS "الأساسي" 3 وما بعده والذي استهدفه Aztec C86 حتى زواله.

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

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

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

في عام 1987، بدأ العديد من المطورين في التحول إلى Microsoft C، وتبعهم العديد من المطورين الآخرين أثناء تطوير Microsoft Windows إلى حالته الحالية. ظهرت منتجات مثل Clipper ولاحقًا Clarion والتي قدمت تطويرًا سهلاً لتطبيقات قواعد البيانات باستخدام تقنيات متعددة اللغات، مما يسمح بتجميع جزء من برامجهم باستخدام Microsoft C.

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

قبل فترة طويلة من بورلاند، حصلت شركة BSD Unix (جامعة بيركلي) على لغة C من مؤلفي لغة C: Kernighan و Ritchie اللذان كتباها معًا أثناء العمل في AT&T (المختبرات). لم تكن احتياجات K&R الأصلية مجرد بناء جملة أنيق من المستوى الثاني ليحل محل بناء جملة من المستوى الأول من التجميع: فقد تم تصميمها بحيث يتم كتابة الحد الأدنى من التجميع لدعم كل منصة (كان التصميم الأصلي لـ C هو القدرة على التجميع المتبادل باستخدام C بأقل قدر من كود الدعم لكل منصة، وهو ما احتاجوا إليه). كما أن لغة C بالأمس كانت مرتبطة بشكل مباشر بكود التجميع أينما لم يكن معتمدًا على المنصة. لم تعد لغة C اليوم (وخاصة c++) متوافقة مع C ويمكن أن يكون كود التجميع الأساسي مختلفًا تمامًا عن المكتوب على منصة معينة (في Linux: يحل أحيانًا محل استدعاءات المكتبة ويحولها باختيارات الموزع). تعد لغة C اليوم لغة من المستوى الثالث أو الرابع تُستخدم بالطريقة القديمة مثل لغة المستوى الثاني.

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

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

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

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

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

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

كان دعم MS-DOS لا يزال متوفرًا مع إصدار أول مترجم C++ من Microsoft، 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 .

في عام 2001، طورت شركة Microsoft Common Language Runtime (CLR)، والتي شكلت الأساس لمترجم .NET Framework في بيئة التطوير المتكاملة Visual Studio. تسمح هذه الطبقة الموجودة في نظام التشغيل والتي توجد في واجهة برمجة التطبيقات بخلط لغات التطوير المترجمة عبر الأنظمة الأساسية التي تعمل بنظام التشغيل Windows.

يوفر وقت تشغيل .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) وجميع أنظمة التشغيل الأخرى (انظر ^[13] ). ومع ذلك، لتجميع بنية أخرى، يجب أولاً بناء إصدار متعدد البنى من المترجم. سيكون ملف المترجم القابل للتنفيذ الناتج "ross" إضافيًا قبل البنية المستهدفة في اسمه. أي إذا تم بناء المترجم لاستهداف x64، فسيكون الملف القابل للتنفيذ ppcrossx64.

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

Clang هو في الأساس مُجمِّع متقاطع، في وقت البناء يمكنك تحديد المعماريات التي تريد أن يتمكن Clang من استهدافها.

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

• مينجي دبليو
• سكراتشبوكس 2
• باسكال الحرة
• المجمع المتقاطع

• أدوات التجميع المتقاطع – مرجع لتكوين أدوات التجميع المتقاطع في GNU
• يعد إنشاء سلاسل أدوات متقاطعة باستخدام gcc ويكيًا لمراجع التجميع المتقاطع لـ GCC الأخرى
• Scratchbox عبارة عن مجموعة أدوات لتجميع Linux عبر أهداف ARM وx86
• Grand Unified Builder (GUB) لنظام Linux لتجميع بنيات متعددة مثل: Win32/Mac OS/FreeBSD/Linux المستخدم بواسطة GNU LilyPond
• Crosstool عبارة عن سلسلة أدوات مفيدة من البرامج النصية ، والتي تعمل على إنشاء بيئة تجميع متقاطعة لنظام Linux للهندسة المعمارية المطلوبة، بما في ذلك الأنظمة المضمنة
• crosstool-NG هو إعادة كتابة لـ Crosstool ويساعد في بناء سلاسل الأدوات.
• buildroot عبارة عن مجموعة أخرى من البرامج النصية لبناء سلسلة أدوات تعتمد على uClibc ، عادةً للأنظمة المضمنة. يتم استخدامها بواسطة OpenWrt .
• ELDK (مجموعة تطوير Linux المضمنة). يستخدمها Das U-Boot .
• T2 SDE عبارة عن مجموعة أخرى من البرامج النصية لبناء أنظمة Linux كاملة تعتمد على GNU libC أو uClibc أو dietlibc لمجموعة متنوعة من المعماريات
• مشروع Cross Linux من الصفر
• لدى IBM برنامج تعليمي واضح للغاية حول بناء سلسلة أدوات GCC.
• (بالفرنسية) التجميع المتقاطع باستخدام GCC 4 تحت Windows لنظام Linux - برنامج تعليمي لبناء سلسلة أدوات GCC متقاطعة، ولكن من Windows إلى Linux، وهو موضوع نادرًا ما يتم تطويره