क्रॉस कंपाइलर: Difference between revisions

एक क्रॉस कंपाइलर एक कंपाइलर है जो एक [[मंच (कंप्यूटिंग)]] के लिए [[निष्पादन]] योग्य कोड बनाने में सक्षम है, जिस पर कंपाइलर चल रहा है। उदाहरण के लिए, एक कंपाइलर जो एक [[निजी कंप्यूटर]] पर चलता है लेकिन कोड उत्पन्न करता है जो एंड्रॉइड (ऑपरेटिंग सिस्टम) [[स्मार्टफोन]] पर चलता है, एक क्रॉस कंपाइलर है।

एक विकास होस्ट से कई प्लेटफार्मों के लिए कोड संकलित करने के लिए एक क्रॉस कंपाइलर उपयोगी है। लक्ष्य प्लेटफॉर्म पर प्रत्यक्ष संकलन संभव नहीं हो सकता है, उदाहरण के लिए सीमित कंप्यूटिंग संसाधनों वाले [[अंतः स्थापित प्रणाली]] पर।

क्रॉस कंपाइलर्स [[स्रोत से स्रोत [[संकलक]]]]्स से भिन्न हैं। एक क्रॉस कंपाइलर मशीन कोड के [[क्रॉस-प्लेटफ़ॉर्म सॉफ़्टवेयर]] जनरेशन के लिए है, जबकि सोर्स-टू-सोर्स कंपाइलर टेक्स्ट कोड में एक कोडिंग भाषा से दूसरी भाषा में अनुवाद करता है। दोनों [[प्रोग्रामिंग उपकरण]] हैं।

क्रॉस कंपाइलर का मौलिक उपयोग निर्माण वातावरण को लक्षित वातावरण से भिन्न  करना है। यह कई स्थितियों में उपयोगी है:

* एम्बेडेड सिस्टम जहां डिवाइस में अत्यधिक सीमित संसाधन होते हैं। उदाहरण के लिए, एक माइक्रोवेव ओवन में अपने कीपैड और डोर सेंसर को पढ़ने, डिजिटल डिस्प्ले और स्पीकर को आउटपुट प्रदान करने और खाना पकाने के लिए माइक्रोवेव को नियंत्रित करने के लिए एक बहुत छोटा कंप्यूटर होगा। यह कंप्यूटर सामान्यतः  एक कंपाइलर, फाइल सिस्टम, या विकास पर्यावरण चलाने के लिए पर्याप्त शक्तिशाली नहीं होता है।

* कई मशीनों के लिए संकलन। उदाहरण के लिए, एक कंपनी [[ऑपरेटिंग सिस्टम]] के कई भिन्न -भिन्न  संस्करणों का समर्थन करना चाहती है या कई भिन्न -भिन्न  ऑपरेटिंग सिस्टमों का समर्थन करना चाहती है। एक क्रॉस कंपाइलर का उपयोग करके, इनमें से प्रत्येक लक्ष्य के लिए संकलन करने के लिए एक एकल निर्माण वातावरण स्थापित किया जा सकता है।

* एक [[सर्वर फार्म]] पर संकलन। कई मशीनों के लिए संकलन के समान, एक जटिल निर्माण जिसमें कई संकलन संचालन सम्मलित  हैं, किसी भी मशीन पर निष्पादित किया जा सकता है, जो कि इसके अंतर्निहित हार्डवेयर या ऑपरेटिंग सिस्टम संस्करण पर ध्यान दिए बिना मुक्त है।

* [[बूटस्ट्रैपिंग (संकलक)]] एक नए मंच के लिए। एक नए प्लेटफ़ॉर्म के लिए सॉफ़्टवेयर विकसित करते समय, या भविष्य के प्लेटफ़ॉर्म के एमुलेटर, ऑपरेटिंग सिस्टम और एक देशी कंपाइलर जैसे आवश्यक टूल को संकलित करने के लिए एक क्रॉस कंपाइलर का उपयोग करता है।

[[आभासी मशीन]] (जैसे जावा की [[जावा वर्चुअल मशीन]]) का उपयोग कुछ ऐसे कारणों को हल करता है जिनके लिए क्रॉस कंपाइलर्स विकसित किए गए थे। वर्चुअल मशीन प्रतिमान एक ही कंपाइलर आउटपुट को कई लक्ष्य प्रणालियों में उपयोग करने की अनुमति देता है, चूंकि  यह निरंतर आदर्श नहीं होता है क्योंकि वर्चुअल मशीन अधिकांशतः   धीमी होती हैं और संकलित प्रोग्राम केवल उस वर्चुअल मशीन वाले कंप्यूटर पर ही चलाया जा सकता है।

सामान्यतः  [[हार्डवेयर वास्तुकला]] भिन्न होता है (उदाहरण के लिए x[[86]] कंप्यूटर पर MIPS आर्किटेक्चर के लिए नियत प्रोग्राम को कोड करना) लेकिन क्रॉस-संकलन भी तब उपयोगी होता है जब केवल ऑपरेटिंग सिस्टम का वातावरण भिन्न  होता है, जैसे कि [[Linux]] के अनुसार  एक [[FreeBSD]] प्रोग्राम को संकलित करते समय, या यहां तक ​​​​कि सिस्टम लाइब्रेरी , जैसे किसी [[glibc]] होस्ट पर [[uClibc]] के साथ प्रोग्राम संकलित करते समय।

कैनेडियन क्रॉस अन्य मशीनों के लिए क्रॉस कंपाइलर्स बनाने की एक तकनीक है, जहां मूल मशीन लक्ष्य से बहुत धीमी या कम सुविधाजनक है। तीन मशीनों A, B, और C को देखते हुए, एक मशीन B पर चलने वाले क्रॉस कंपाइलर (जैसे [[x86-64]] प्रोसेसर पर [[Mac OS X]] चलाना) बनाने के लिए मशीन A (जैसे [[IA-32]] प्रोसेसर पर Windows XP चलाना) का उपयोग करता है। मशीन सी के लिए निष्पादन योग्य बनाएं (उदाहरण के लिए [[एआरएम वास्तुकला]] प्रोसेसर पर एंड्रॉइड (ऑपरेटिंग सिस्टम) चलाना)। इस उदाहरण में व्यावहारिक लाभ यह है कि मशीन A धीमी है, लेकिन उसके पास मालिकाना संकलक है, जबकि मशीन B तेज़ है, लेकिन उसका कोई संकलक नहीं है, और मशीन C संकलन के लिए उपयोग किए जाने के लिए अव्यावहारिक रूप से धीमी है।

उदाहरण के लिए, [[NetBSD]] एक [[POSIX]] Unix शेल स्क्रिप्ट प्रदान करता है जिसका नाम है <code>build.sh</code> जो पहले होस्ट के कंपाइलर के साथ अपना [[toolchain]] बनाएगा; बदले में, इसका उपयोग क्रॉस कंपाइलर बनाने के लिए किया जाएगा जिसका उपयोग पूरे सिस्टम को बनाने के लिए किया जाएगा।

GCC के लिए आवश्यक है कि प्रत्येक लक्षित प्लेटफॉर्म के लिए बिनुटिल्स की एक संकलित प्रति उपलब्ध हो। [[जीएनयू असेंबलर]] विशेष रूप से महत्वपूर्ण है। इसलिए, पहले बिनुटिल्स को स्विच के साथ सही ढंग से संकलित करना होगा <code>--target=some-target</code> [[स्क्रिप्ट कॉन्फ़िगर करें]] को भेजा गया। जीसीसी को भी उसी के साथ स्क्रिप्ट को कॉन्फ़िगर करना होगा <code>--target</code> विकल्प। तब GCC को सामान्य रूप से चलाया जा सकता है, बशर्ते कि उपकरण, जो बिनुटिल्स बनाता है, [[पथ (कंप्यूटिंग)]] में उपलब्ध हो, जिसे निम्नलिखित का उपयोग करके किया जा सकता है (यूनिक्स-जैसे ऑपरेटिंग सिस्टम पर बैश के साथ):

[[जीएनयू बिल्ड सिस्टम]] पैकेज (अर्थात [[autoconf]]़, [[automake]] और [[libtool]]) एक बिल्ड प्लेटफ़ॉर्म, एक होस्ट प्लेटफ़ॉर्म और एक लक्ष्य प्लेटफ़ॉर्म की धारणा का उपयोग करते हैं। बिल्ड प्लेटफॉर्म वह जगह है जहां कंपाइलर वास्तव में संकलित होता है। ज्यादातर स्थितियो  में, बिल्ड को अपरिभाषित छोड़ दिया जाना चाहिए (यह होस्ट से डिफ़ॉल्ट होगा)। होस्ट प्लेटफ़ॉर्म निरंतर  वह होता है जहाँ कंपाइलर से आउटपुट कलाकृतियों को निष्पादित किया जाएगा चाहे आउटपुट कोई अन्य कंपाइलर हो या नहीं। लक्ष्य प्लेटफ़ॉर्म का उपयोग तब किया जाता है जब क्रॉस-कंपाइलर क्रॉस-कंपाइलर होते हैं, यह दर्शाता है कि पैकेज किस प्रकार का ऑब्जेक्ट कोड उत्पन्न करेगा; अन्यथा लक्ष्य प्लेटफ़ॉर्म सेटिंग अप्रासंगिक है।<ref>{{Cite web|url=https://www.gnu.org/s/libtool/manual/automake/Cross_002dCompilation.html|title=Cross-Compilation (Automake)}}</ref> उदाहरण के लिए, एक [[कलाकारों का सपना]] पर चलने वाले वीडियो गेम को क्रॉस-कंपाइल करने पर विचार करें। मशीन जहां गेम को संकलित किया गया है वह बिल्ड प्लेटफॉर्म है जबकि ड्रीमकास्ट होस्ट प्लेटफॉर्म है। नाम मेजबान और लक्ष्य संकलक के सापेक्ष उपयोग किए जा रहे हैं और बेटे और पोते की तरह स्थानांतरित किए जा रहे हैं।<ref>{{Cite web|url=https://mesonbuild.com/Cross-compilation.html|title=Cross compilation}}</ref>

1980 के दशक से और 1990 के दशक तक जारी रहा जब तक कि मैनक्स सॉफ्टवेयर सिस्टम गायब नहीं हो गया, एज़्टेक सी का एमएस-डॉस संस्करण<ref>[http://www.clipshop.ca/Aztec/index.htm Aztec C]</ref> कमोडोर 64 सहित विभिन्न प्रोसेसर के साथ अन्य प्लेटफार्मों के लिए मूल मोड कंपाइलर या क्रॉस कंपाइलर के रूप में दोनों की पेशकश की गई थी<ref>[http://www.clipshop.ca/Aztec/index.htm#commodore Commodore 64]</ref> और एप्पल II।<ref>[http://www.clipshop.ca/Aztec/index.htm#apple Apple II]</ref> एज़्टेक सी के लिए उनके एमएस-डॉस आधारित क्रॉस कंपाइलर्स सहित इंटरनेट वितरण अभी भी उपलब्ध  हैं। वे आज भी उपयोग में हैं।

मैनक्स का एज़्टेक C86, उनका मूल मोड [[Intel 8086]] MS-DOS कंपाइलर भी एक क्रॉस कंपाइलर था। चूंकि  यह कमोडोर 64 और ऐप्पल II के लिए उनके एज़्टेक सी 65 एमओएस टेक्नोलॉजी 6502 क्रॉस कंपाइलर्स जैसे एक भिन्न  प्रोसेसर के लिए कोड संकलित नहीं करता था, इसने प्रोसेसर के 16-बिट 8086 परिवार के लिए तत्कालीन विरासत ऑपरेटिंग सिस्टम के लिए बाइनरी एक्ज़ीक्यूटेबल्स बनाए।

जब IBM PC पहली बार पेश किया गया था तो यह ऑपरेटिंग सिस्टम के विकल्प के साथ उपलब्ध था, CP/M-86 और PC DOS उनमें से दो थे। एज़्टेक C86 को आईबीएम पीसी ऑपरेटिंग सिस्टम दोनों के लिए कोड बनाने के लिए लिंक लाइब्रेरी प्रदान की गई थी। 1980 के दशक के समय  एज़्टेक C86 (3.xx, 4.xx और 5.xx) के बाद के संस्करणों ने MS-DOS अस्थायी संस्करण 1 और 2 के लिए समर्थन जोड़ा<ref>[http://members.fortunecity.com/pcmuseum/dos.htm MS-DOS Timeline] {{webarchive|url=https://web.archive.org/web/20080501141058/http://members.fortunecity.com/pcmuseum/dos.htm |date=2008-05-01 }}</ref> और जो बेसलाइन MS-DOS संस्करण 3 की तुलना में कम मजबूत थे और बाद में जिन्हें एज़्टेक C86 ने अपने अंत तक लक्षित किया।

अंत में, एज़्टेक C86 ने C भाषा डेवलपर्स को ROM छवि बनाने की क्षमता प्रदान की। रोम-सक्षम हेक्साडेसिमल| हेक्स कोड जिसे तब [[केवल पढ़ने के लिये मेमोरी]] का उपयोग करके सीधे 8086 आधारित प्रोसेसर में स्थानांतरित किया जा सकता था। [[पैरावर्चुअलाइजेशन]] आज अधिक सामान्य हो सकता है, लेकिन निम्न-स्तरीय ROM कोड बनाने का अभ्यास उन वर्षों के समय  प्रति व्यक्ति अधिक सामान्य था, जब [[डिवाइस ड्राइवर]] का विकास अधिकांशतः  व्यक्तिगत अनुप्रयोगों के लिए एप्लिकेशन प्रोग्रामर द्वारा किया जाता था, और नए उपकरण एक कुटीर उद्योग के बराबर होते थे। निर्माता से समर्थन के बिना सीधे हार्डवेयर के साथ इंटरफ़ेस करने के लिए एप्लिकेशन प्रोग्रामर के लिए यह असामान्य नहीं था। यह अभ्यास आज के एम्बेडेड सिस्टम के समान था।

1987 तक, MSC 5.1 की रिलीज़ के साथ, Microsoft ने MS-DOS के लिए एक क्रॉस लैंग्वेज डेवलपमेंट एनवायरनमेंट की पेशकश की। असेंबली लैंग्वेज ([[MASM]]) और Microsoft की अन्य भाषाओं में [[QuickBASIC]], [[पास्कल (प्रोग्रामिंग भाषा)]], और [[फोरट्रान]] सहित लिखे गए 16-बिट बाइनरी ऑब्जेक्ट कोड को एक साथ एक प्रोग्राम में जोड़ा जा सकता है, एक प्रक्रिया में वे मिश्रित भाषा प्रोग्रामिंग और अब इंटरलैंग्वेज कॉलिंग कहलाते हैं।<ref>[http://support.microsoft.com/kb/35965 Which Basic Versions Can CALL C, FORTRAN, Pascal, MASM]</ref> यदि इस मिश्रण में [[BASIC]] का उपयोग किया गया था, तो आंतरिक [[रनटाइम सिस्टम]] का समर्थन करने के लिए मुख्य प्रोग्राम का BASIC में होना आवश्यक था, जो कचरा संग्रह के लिए आवश्यक BASIC को संकलित करता था और इसके अन्य प्रबंधित संचालन जो MS-DOS में [[QBasic]] जैसे BASIC [[दुभाषिया (कंप्यूटिंग)]] का अनुकरण करते थे।

एमएससी ने वहीं से पदभार संभाला जहां एज़्टेक सी ने छोड़ा था। सी कंपाइलर्स के लिए बाजार हिस्सेदारी क्रॉस कंपाइलर्स में बदल गई थी, जिसने नवीनतम और सबसे बड़ी विंडोज सुविधाओं का लाभ उठाया, एक ही बंडल में सी और सी ++ की पेशकश की, और अभी भी एमएस-डॉस सिस्टम का समर्थन किया जो पहले से ही एक दशक पुराना था, और छोटी कंपनियां जो एज़्टेक सी जैसे उत्पादित संकलक अब प्रतिस्पर्धा नहीं कर सकते थे और या तो एम्बेडेड सिस्टम जैसे आला बाजारों में बदल गए या गायब हो गए।

MSC 13 को [[Visual Studio 2003]] के साथ रिलीज़ किया गया था, और MSC 14 को [[Visual Studio 2005]] के साथ रिलीज़ किया गया था, जो दोनों अभी भी Windows 95 जैसे पुराने सिस्टम के लिए कोड का उत्पादन करते हैं, लेकिन जो मोबाइल मार्केट और ARM आर्किटेक्चर सहित कई लक्षित प्लेटफॉर्म के लिए कोड तैयार करेगा।

2001 में माइक्रोसॉफ्ट ने [[सामान्य भाषा रनटाइम]] (सीएलआर) विकसित किया, जिसने विजुअल स्टूडियो आईडीई में उनके .NET फ्रेमवर्क कंपाइलर के लिए कोर का गठन किया। ऑपरेटिंग सिस्टम पर यह परत जो [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] में है, विंडोज ऑपरेटिंग सिस्टम चलाने वाले प्लेटफॉर्म पर संकलित विकास भाषाओं के मिश्रण की अनुमति देती है।