कोड उत्पन्न करते समय, आपको कौन सी भाषा उत्पन्न करनी चाहिए?

Question

मैंने कोड उत्पादों का उपयोग करने वाले कई उत्पादों पर काम किया है। यह उपयोगकर्ता-अनुकूलन और उच्च निष्पादन गति दोनों की एक उच्च डिग्री प्राप्त करने का एकमात्र तरीका प्रतीत होता है।

नकारात्मकता यह है कि हमें उपयोगकर्ताओं को एक कंपाइलर स्थापित करने की आवश्यकता है (मुख्य रूप से एमएस विंडोज़ पर)।

यह चल रहा सिरदर्द रहा है, क्योंकि एमएस जैसे विक्रेता ओएसओएसटिंग कंपिलर रखते हैं, और कुछ उपयोगकर्ताओं में एक से अधिक कंपाइलर स्थापित होते हैं।

हम जीएनयू सी, और संभवतः सी ++ का उपयोग करने पर विचार कर रहे हैं, लेकिन यहां तक ​​कि वहां लगातार संस्करण मुद्दे हैं।

मैंने संकलक-संस्करण-ट्रेडमिल को दूर करने के प्रयास में संभावित रूप से असेंबली भाषा उत्पन्न की है, लेकिन असेंबली भाषाएं सभी मशीन-विशिष्ट हैं।

आदर्श रूप से जेनरेट कोड उत्पन्न करने का कोई तरीका होगा जो लचीला होगा, तेजी से दौड़ेंगे, और हमें तीसरे पक्ष के प्रदाताओं की इच्छाओं के बारे में बताएगा।

शायद मैं जावा की तरह कुछ सरल दिख रहा हूं। किसी भी सुझाव की सराहना की जाएगी। धन्यवाद।

Answer 1

आप सी और यहां तक ​​कि कोडांतरक पर विचार कर रहे हैं, तो पहले LLVM पर एक नज़र डालें: http://llvm.org

Answer 2

यहाँ शुरू

: http://www.codegeneration.net/

Answer 3

मैं कुछ संदर्भ यहाँ लापता हो सकता है, लेकिन तुम सिर्फ एक विशेष संस्करण के लिए अपने आप को पिन कर सकता है? उदा।, .NET 2.0 को .NET 1.1 और .NET 3.5 के साथ-साथ भविष्य में आने वाले अन्य संस्करणों के साथ-साथ स्थापित किया जा सकता है। इसलिए जब तक आपका कोड किसी कंपाइलर के विशिष्ट संस्करण का उपयोग करता है, तो समस्या क्या है?

Answer 4

एक विकल्प एक भाषा/पर्यावरण का उपयोग करना होगा जो कोड में कंपाइलर तक पहुंच प्रदान करता है; उदाहरण के लिए, here is a C# example।

Answer 5

मैंने संकलक-संस्करण-ट्रेडमिल को दूर करने के प्रयास में संभावित रूप से असेंबली भाषा उत्पन्न की है, लेकिन असेंबली भाषाएं सभी मशीन-विशिष्ट हैं।

एक संकलक :)

कहा जा सकता है कि तुम क्यों C90 से टिक नहीं पाता?

यदि आपने एक्सटेंशन का उपयोग नहीं किया है, तो मैंने gcc की तरफ से मानकों के गंभीर उल्लंघन के बारे में बहुत कुछ नहीं सुना है।

और आप हमेशा अपने उत्पाद के साथ gcc की एक निश्चित संस्करण वितरित कर सकते, कहते हैं, 4.3.2, अपने स्वयं के जोखिम पर अपने स्वयं के संकलक का उपयोग करने के लिए उपयोगकर्ताओं के लिए एक विकल्प दे रही है।

जब तक आपके द्वारा सभी कोड उत्पन्न नहीं होते हैं (i। ई। आप अपने निर्देशों को अन्य कोड में एम्बेड नहीं करते हैं), इस संस्करण के खिलाफ परीक्षण करने और अपने पुस्तकालयों को संकलित करने के लिए इसका उपयोग करने में कोई समस्या नहीं होनी चाहिए।

Answer 6

क्यों अपने कोड जनरेटर के साथ एक GNU सी संकलक जहाज नहीं? इस तरह आपके पास कोई संस्करण समस्या नहीं है, और ग्राहक लगातार कोड उत्पन्न कर सकता है जो प्रयोग योग्य है।

Answer 7

मैं उस भाषा को तैयार करने के लिए उस भाषा से चिपके रहूंगा जिसका उपयोग आप उस भाषा को उत्पन्न करने के लिए करते हैं।आप जावा में जावा कोड जेनरेट और संकलित कर सकते हैं, पाइथन में पाइथन कोड, सी # सी # सीआईएस में एलआईएसपी आदि में भी

लेकिन यह स्पष्ट नहीं है कि ऐसी भाषाएं आपके लिए पर्याप्त तेज़ हैं या नहीं। शीर्ष गति के लिए मैं सी ++ उत्पन्न करना और संकलन के लिए जीसीसी का उपयोग करना चुनूंगा।

Answer 8

ऐसा लगता है कि आप LLVM की तलाश में हैं।

Answer 9

स्पाइडरमोन्की या राइनो (जावा या सी ++ में जावास्क्रिप्ट समर्थन) जैसे कुछ का उपयोग क्यों न करें। आप अपनी ऑब्जेक्ट्स जावास्क्रिप्ट नेमस्पेस पर निर्यात कर सकते हैं, और आपके उपयोगकर्ताओं को कुछ भी संकलित करने की आवश्यकता नहीं है।

Answer 10

यदि आप एएसएम कोड जेनरेट करना चाहते हैं, तो आप asmjit पर एक नज़र डाल सकते हैं।

Answer 11

यह बहुत देर हो सकती है। लेकिन यहां मेरे दो सेंट हैं। आपके प्रोग्राम में लुआ/स्कीम जैसी भाषा के लिए एक दुभाषिया एम्बेड करें। और उस भाषा में कोड उत्पन्न करें।

Answer 12

@ एल्विन के उत्तर के मामले में "मेरे 2 सेंट जोड़ने में देर हो सकती है" की भावना में, यहां कुछ ऐसा है जो मैं सोचता हूं: यदि आपका आवेदन कुछ वर्षों तक चल रहा है, तो है आवेदन और सिस्टम कैसे काम करते हैं, इस बारे में कई बदलावों का सामना करना पड़ रहा है।

उदाहरण के लिए, मान लीजिए कि आप इस 10 साल पहले सोच रहे थे। मैं फिर डेक्सटर देख रहा था, लेकिन मुझे लगता है कि आपको वास्तव में यादें हैं कि उस समय चीजें कैसे थीं। जो मैं कह सकता हूं, उससे 2000 के डेवलपर्स के लिए मल्टीथ्रेडिंग एक मुद्दा नहीं था, और अब यह है। तो मूर का कानून उनके लिए तोड़ दिया। इससे पहले कि लोगों ने "Y2K" में क्या होगा, इस बारे में भी परवाह नहीं की थी।

मूर के कानून की बात करते हुए, प्रोसेसर वास्तव में काफी तेजी से हो रहे हैं, इसलिए शायद कुछ अनुकूलन भी आवश्यक नहीं होंगे। और संभवतः ऑप्टिमाइज़ेशन की सरणी बहुत बड़ी होगी, some processors कई सर्वर-केंद्रित सामग्री (एक्सएमएल, क्रिप्टोग्राफी, संपीड़न और रेगेक्स के लिए अनुकूलन प्राप्त कर रहे हैं! मुझे आश्चर्य है कि चिप पर ऐसी चीजें हो सकती हैं) और कम ऊर्जा खर्च भी करती है (जो युद्ध हार्डवेयर के लिए शायद बहुत महत्वपूर्ण है ...)।

मेरा मुद्दा यह है कि कल के लिए एक मंच के रूप में आज मौजूद होने पर ध्यान केंद्रित करना एक अच्छा विचार नहीं है। इसे आज काम करें, और निश्चित रूप से यह कल काम करेगा (पिछड़ा-संगतता विशेष रूप से माइक्रोसॉफ्ट द्वारा मूल्यवान है, ऐप्पल बुरा नहीं लगता है और लिनक्स इसे काम करने के बारे में बहुत उदार है)।

वहाँ है, हाँ, एक चीज जो आप कर सकते हैं। अपनी तकनीक को उस चीज़ से अटैच करें जो जावास्क्रिप्ट जैसे मरने की संभावना नहीं है। मैं गंभीर हूं, जावास्क्रिप्ट वीएम आजकल बहुत कुशल हो रहे हैं और बस बेहतर होने जा रहे हैं, साथ ही हर कोई इसे प्यार करता है, इसलिए यह अचानक गायब होने वाला नहीं है। यदि अधिक दक्षता/सुविधाओं की आवश्यकता है, तो शायद सीआरएल या जेवीएम को लक्षित करें?

मुझे विश्वास है कि मल्टीथ्रेडिंग एक और अधिक समस्या बन जाएगी। मुझे लगता है कि प्रोसेसर कोर की संख्या में मूर का कानून होगा। और क्लाउड buzz के दिखने से आर्किटेक्चर बदलने की संभावना से अधिक हैं।

पीएस: किसी भी मामले में, मैं अतीत के सी अनुकूलन विश्वास करता हूं अभी भी आधुनिक कंपाइलरों के तहत काफी मान्य है!