Rust: `asm` (इनलाइन असेंबली) के लिए ट्रैकिंग समस्या

क्या स्थिर कोड में इनलाइन असेंबली की पश्च-संगतता सुनिश्चित करने में कोई कठिनाई होगी?

@ main-- https://github.com/rust-lang/rfcs/pull/1471#issuecomment -173982852 पर एक अच्छी टिप्पणी है कि मैं यहां भावी पीढ़ी के लिए पुन: प्रस्तुत कर रहा हूं:

साथ सभी खुले कीड़े और अस्थायित्व आसपास के एएसएम ()! (वहाँ एक बहुत ), मैं वास्तव में यह स्थिरीकरण के लिए तैयार है नहीं लगता है - भले ही मैं जंग में स्थिर इनलाइन एएसएम करके हमें खुशी होगी।

हमें यह भी चर्चा करनी चाहिए कि क्या आज का asm!() वास्तव में सबसे अच्छा समाधान है या यदि RFC #129 या D की तर्ज पर कुछ बेहतर होगा। यहां विचार करने के लिए एक महत्वपूर्ण बिंदु यह है कि एएसएम() जीसीसी के समान बाधाओं के सेट का समर्थन नहीं करता है। इसलिए, हम या तो कर सकते हैं:

• एलएलवीएम व्यवहार पर टिके रहें और उसके लिए दस्तावेज़ लिखें (क्योंकि मुझे कोई भी नहीं मिला है)। अच्छा है क्योंकि यह जंग में जटिलता से बचाता है। खराब है क्योंकि यह सी/सी++ से आने वाले प्रोग्रामर को भ्रमित करेगा और क्योंकि कुछ बाधाओं को जंग कोड में अनुकरण करना मुश्किल हो सकता है।
• जीसीसी का अनुकरण करें और बस उनके दस्तावेज़ों से लिंक करें: अच्छा है क्योंकि कई प्रोग्रामर इसे पहले से ही जानते हैं और ऐसे बहुत से उदाहरण हैं जिन्हें केवल थोड़े संशोधनों के साथ कॉपी-पेस्ट किया जा सकता है। खराब क्योंकि यह संकलक के लिए एक अनौपचारिक विस्तार है।
• कुछ और करें (जैसे डी करता है): बहुत सारे काम जो भुगतान कर सकते हैं या नहीं भी कर सकते हैं। यदि सही किया जाए, तो यह एर्गोनॉमिक्स के मामले में जीसीसी-शैली से काफी बेहतर हो सकता है, जबकि संभवतः केवल एक अपारदर्शी ब्लॉब की तुलना में भाषा और कंपाइलर के साथ अधिक अच्छी तरह से एकीकृत हो सकता है (यहां बहुत सारे हैंडविंग हैं क्योंकि मैं इसका आकलन करने के लिए कंपाइलर इंटर्नल के साथ पर्याप्त परिचित नहीं हूं) .

अंत में, विचार करने की एक और बात # 1201 है जो कि इसके वर्तमान डिजाइन (मुझे लगता है) में इनलाइन एएसएम पर काफी निर्भर करता है - या इनलाइन एएसएम उस मामले के लिए सही किया जाता है।

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

आंतरिक-आधारित दृष्टिकोण का एक फायदा यह है कि इसके लिए सर्व-या-कुछ होने की आवश्यकता नहीं है। आप सबसे पहले सबसे आवश्यक इंट्रिनिक्स को परिभाषित कर सकते हैं, और सेट आउट को वृद्धिशील रूप से बना सकते हैं। उदाहरण के लिए, क्रिप्टो के लिए, _addcarry_u64 , _addcarry_u32 । ध्यान दें कि ऐसा लगता है कि इंस्ट्रिनिक्स को करने का काम पहले ही काफी अच्छी तरह से किया जा चुका है: https://github.com/huonw/llvmint।

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

इंट्रिनिक्स अच्छे हैं, लेकिन asm! का उपयोग केवल निर्देश डालने से अधिक के लिए किया जा सकता है।
उदाहरण के लिए, देखें कि मैं अपने probe क्रेट में ईएलएफ नोट्स कैसे बना रहा हूं।
https://github.com/cuviper/rust-libprobe/blob/master/src/platform/systemtap.rs

मुझे उम्मीद है कि इस तरह की हैकरी दुर्लभ होगी, लेकिन मुझे लगता है कि यह अभी भी समर्थन करने के लिए एक उपयोगी चीज है।

@ ब्रायनस्मिथ

इनलाइन एएसएम कोड के लिए भी उपयोगी है जो अपना खुद का रजिस्टर/स्टैक आवंटन करना चाहता है (उदाहरण के लिए नग्न कार्य)।

@briansmith हाँ, जहाँ संभव हो वहाँ

@briansmith ध्यान दें कि asm!() _kind of_ इंट्रिनिक्स का एक सुपरसेट है क्योंकि आप पूर्व का उपयोग करके बाद वाले का निर्माण कर सकते हैं। (इस तर्क के खिलाफ आम तर्क यह है कि संकलक सैद्धांतिक रूप से _थ्रू_ इंट्रिनिक्स को अनुकूलित कर सकता है, उदाहरण के लिए उन्हें लूप से बाहर निकालना, उन पर सीएसई चलाना आदि। हालांकि, यह एक बहुत मजबूत काउंटरपॉइंट है कि _optimization_ उद्देश्यों के लिए एएसएम लिखने वाला कोई भी बेहतर काम करेगा। वैसे भी कंपाइलर की तुलना में।) https://github.com/rust-lang/rust/issues/29722#issuecomment -207628164 और https://github.com/rust-lang/rust/issues/29722# भी देखें।

दूसरी ओर, इंट्रिनिक्स गंभीर रूप से "पर्याप्त रूप से स्मार्ट कंपाइलर" पर निर्भर करता है ताकि _at कम से कम _ प्रदर्शन प्राप्त किया जा सके जो एक हाथ से लुढ़काए गए एएसएम कार्यान्वयन के साथ प्राप्त होगा। इस पर मेरा ज्ञान पुराना है, लेकिन जब तक महत्वपूर्ण प्रगति नहीं हुई है, तब तक कई मामलों में आंतरिक-आधारित कार्यान्वयन अभी भी मापने योग्य रूप से कम हैं - यदि अधिकतर नहीं। बेशक वे उपयोग करने के लिए अधिक सुविधाजनक हैं लेकिन मैं कहूंगा कि प्रोग्रामर वास्तव में _that_ के बारे में ज्यादा परवाह नहीं करते हैं जब वे विशिष्ट CPU निर्देशों की दुनिया में उतरने के इच्छुक होते हैं।

अब एक और दिलचस्प विचार यह है कि इंट्रिनिक्स को आर्किटेक्चर पर फ़ॉलबैक कोड के साथ जोड़ा जा सकता है जहां वे समर्थित नहीं हैं। यह आपको दोनों दुनिया के सर्वश्रेष्ठ प्रदान करता है: आपका कोड अभी भी पोर्टेबल है - यह केवल कुछ हार्डवेयर त्वरित संचालन को नियोजित कर सकता है जहां हार्डवेयर उनका समर्थन करता है। बेशक यह वास्तव में या तो बहुत ही सामान्य निर्देशों के लिए भुगतान करता है या यदि एप्लिकेशन में एक स्पष्ट लक्ष्य वास्तुकला है। अब मैं इसका उल्लेख करने का कारण यह है कि जब कोई यह तर्क दे सकता है कि यह संभावित रूप से _undesirable_ भी हो सकता है _compiler-provided_ इंट्रिनिक्स के साथ (जैसा कि आप शायद इस बात की परवाह करेंगे कि क्या आपको वास्तव में त्वरित संस्करण मिलते हैं और संकलक जटिलता कभी अच्छी नहीं होती है) I 'डी कहेंगे कि यह एक अलग कहानी है यदि आंतरिक _library_ द्वारा प्रदान किया जाता है (और केवल इनलाइन एएसएम का उपयोग करके कार्यान्वित किया जाता है)। वास्तव में, यह वह बड़ी तस्वीर है जिसे मैं पसंद करूंगा, भले ही मैं खुद को इनलाइन एएसएम से अधिक इंट्रिनिक्स का उपयोग करते हुए देख सकूं।

(मैं इस चर्चा के लिए आरएफसी #1199 से कुछ हद तक ऑर्थोगोनल पर विचार करता हूं क्योंकि वे ज्यादातर सिम काम करने के लिए मौजूद हैं।)

@ ब्रायनस्मिथ

अन्यथा, इनलाइन एएसएम के आसपास के कोड को अनुकूलित करना बहुत मुश्किल है, जो विडंबनापूर्ण है क्योंकि इनलाइन एएसएम के कई उपयोग प्रदर्शन अनुकूलन के लिए हैं।

मुझे यकीन नहीं है कि आपका यहाँ क्या मतलब है। यह सच है कि संकलक शक्ति में कमी या उस पर पीपहोल अनुकूलन करने के लिए एएसएम को अपने व्यक्तिगत संचालन में नहीं तोड़ सकता है। लेकिन जीसीसी मॉडल में, कम से कम, कंपाइलर अपने द्वारा उपयोग किए जाने वाले रजिस्टरों को आवंटित कर सकता है, इसे कॉपी कर सकता है जब यह कोड पथों को दोहराता है, इसे कभी भी उपयोग नहीं किया जाता है, और इसी तरह। यदि एएसएम अस्थिर नहीं है, तो जीसीसी के पास इसे किसी भी अन्य अपारदर्शी ऑपरेशन की तरह व्यवहार करने के लिए पर्याप्त जानकारी है, जैसे fsin । अजीब डिजाइन के लिए पूरी प्रेरणा इनलाइन एएसएम बनाना है जिसे ऑप्टिमाइज़र गड़बड़ कर सकता है।

लेकिन मैंने इसका पूरा उपयोग नहीं किया है, खासकर हाल ही में नहीं। और मुझे LLVM द्वारा इस सुविधा को प्रस्तुत करने का कोई अनुभव नहीं है। तो मैं सोच रहा हूं कि क्या बदल गया है, या मैंने इस समय क्या गलत समझा है।

हमने हाल के कार्य सप्ताह में इस मुद्दे पर चर्चा की क्योंकि @japaric के no_std पारिस्थितिकी तंत्र के सर्वेक्षण में asm! मैक्रो अधिक सामान्य रूप से उपयोग की जाने वाली सुविधाओं में से एक है। दुर्भाग्य से हमें इस सुविधा को स्थिर करने का कोई आसान रास्ता नहीं दिख रहा था, लेकिन मैं यह सुनिश्चित करना चाहता था कि हम यह सब न भूलें।

• सबसे पहले, हमारे पास वर्तमान में asm! मैक्रो में स्वीकृत सिंटैक्स का एक अच्छा विनिर्देश नहीं है। अभी यह आम तौर पर "एलएलवीएम को देखो" के रूप में समाप्त होता है जो कहता है "क्लैंग को देखो" जो कहता है "जीसीसी को देखो" जिसमें महान दस्तावेज़ नहीं हैं। अंत में यह आम तौर पर "किसी और के उदाहरण को पढ़ें और इसे अनुकूलित करें" या "एलएलवीएम के स्रोत कोड को पढ़ें" पर नीचे की ओर जाता है। स्थिरीकरण के लिए न्यूनतम यह है कि हमें वाक्य रचना और दस्तावेज़ीकरण का एक विनिर्देश होना चाहिए।

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

• अभी इनलाइन असेंबली से संबंधित कुछ बग हैं। A-इनलाइन-असेंबली टैग एक अच्छा प्रारंभिक बिंदु है, और यह वर्तमान में ICEs, LLVM में segfaults, आदि से अटा पड़ा है। कुल मिलाकर यह सुविधा, जैसा कि आज लागू किया गया है, गुणवत्ता की गारंटी पर खरा नहीं उतरती है जो दूसरों को एक स्थिर से उम्मीद है जंग में विशेषता।

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

ऊपर सूचीबद्ध मुद्दों के बावजूद हम इस मुद्दे को आगे बढ़ाने के लिए कम से कम कुछ क्षमता के साथ आना सुनिश्चित करना चाहते थे! इसके लिए हमने कुछ रणनीतियों पर मंथन किया कि कैसे हम स्थिरीकरण की दिशा में इनलाइन असेंबली को आगे बढ़ा सकते हैं। आगे का प्राथमिक तरीका यह जांचना होगा कि क्लैंग क्या करता है। संभावित रूप से क्लैंग और सी में प्रभावी रूप से स्थिर इनलाइन असेंबली सिंटैक्स होता है और यह संभावना हो सकती है कि हम जो कुछ भी क्लैंग करते हैं (विशेष रूप से wrt LLVM) केवल मिरर कर सकते हैं। क्लैंग इनलाइन असेंबली को कैसे लागू करता है, इसे अधिक गहराई से समझना बहुत अच्छा होगा। क्या क्लैंग की अपनी अनुवाद परत होती है? क्या यह किसी इनपुट पैरामीटर को मान्य करता है? (आदि)

आगे बढ़ने की एक और संभावना यह देखने के लिए है कि क्या कोई असेंबलर है जो हम शेल्फ को कहीं और से हटा सकते हैं जो पहले से ही स्थिर है। यहाँ कुछ विचार थे nasm या plan9 असेंबलर। एलएलवीएम के असेंबलर का उपयोग करने से स्थिरता गारंटी के बारे में वही समस्याएं होती हैं जो आईआर में इनलाइन असेंबली निर्देश के रूप में होती हैं। (यह एक संभावना है, लेकिन इसका उपयोग करने से पहले हमें स्थिरता की गारंटी चाहिए)

मैं यह बताना चाहता हूं कि एलएलवीएम का इनलाइन एएसएम सिंटैक्स क्लैंग/जीसीसी द्वारा उपयोग किए जाने वाले से अलग है। मतभेदों में शामिल हैं:

• LLVM का उपयोग करता है $0 के बजाय %0 ।
• एलएलवीएम नामित एएसएम ऑपरेंड का समर्थन नहीं करता %[name] ।
• LLVM अलग रजिस्टर बाधा प्रकार का समर्थन करता: उदाहरण के लिए "{eax}" के बजाय "a" 86 पर।
• एलएलवीएम स्पष्ट रजिस्टर बाधाओं का समर्थन करता है ( "{r11}" )। सी में आपको एक रजिस्टर ( register asm("r11") int x ) के मूल्य को बांधने के लिए रजिस्टर एएसएम चर का उपयोग करना चाहिए।
• एलएलवीएम "m" और "=m" बाधाएं मूल रूप से टूट गई हैं। क्लैंग इन अप्रत्यक्ष स्मृति बाधाओं "*m" और "=*m" और चर के बजाय चर के पते को एलएलवीएम में पास करता है।
• आदि...

क्लैंग इनलाइन एएसएम को एलएलवीएम में भेजने से पहले जीसीसी प्रारूप से एलएलवीएम प्रारूप में परिवर्तित कर देगा। यह बाधाओं का कुछ सत्यापन भी करता है: उदाहरण के लिए यह सुनिश्चित करता है कि "i" ऑपरेंड संकलन-समय स्थिरांक हैं,

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

ऑनलाइन स्लाइड के साथ डी, एमएसवीसी, जीसीसी, एलएलवीएम, और जंग के साथ सारांश के बारे में एक उत्कृष्ट वीडियो है

किसी ऐसे व्यक्ति के रूप में जो स्थिर जंग में इनलाइन एएसएम का उपयोग करने में सक्षम होना चाहता है, और अधिक अनुभव के साथ मैं जंग से कुछ एलएलवीएम एमसी एपीआई तक पहुंचने का प्रयास करना चाहता हूं, कुछ विचार:

• इनलाइन एएसएम मूल रूप से कुछ स्ट्रिंग प्रतिस्थापन के बाद कोड के एक स्निपेट की एक कॉपी-पेस्ट है, जो कोडांतरण के लिए आउटपुट .s फ़ाइल में है। इसमें इनपुट और आउटपुट रजिस्टरों के साथ-साथ क्लॉबर्ड रजिस्टर भी संलग्न हैं। यह बुनियादी ढांचा एलएलवीएम में वास्तव में कभी भी बदलने की संभावना नहीं है (हालांकि कुछ विवरण थोड़ा भिन्न हो सकते हैं), और मुझे संदेह है कि यह एक काफी ढांचा-स्वतंत्र प्रतिनिधित्व है।

• रस्ट-फेसिंग स्पेसिफिकेशन से LLVM-फेसिंग IR फॉर्मेट में अनुवाद बनाना कठिन नहीं है। और यह सलाह दी जा सकती है - एलएलवीएम के $ और जीसीसी % नोटेशन के विपरीत, स्वरूपण के लिए जंग {} सिंटैक्स असेंबली भाषा में हस्तक्षेप नहीं करता है।

• एलएलवीएम वास्तव में यह पहचानने के अभ्यास में आश्चर्यजनक रूप से खराब काम करता है कि कौन से रजिस्टरों को पकड़ लिया जाता है, खासकर एलएलवीएम द्वारा उत्पन्न नहीं किए गए निर्देशों में। इसका मतलब यह है कि उपयोगकर्ता के लिए मैन्युअल रूप से यह निर्दिष्ट करना बहुत जरूरी है कि कौन से रजिस्टरों को बंद कर दिया गया है।

• असेंबली को स्वयं पार्स करने का प्रयास करना एक दुःस्वप्न होने की संभावना है। LLVM-C API MCAsmParser तर्क को उजागर नहीं करता है, और ये वर्ग बाइंडजेन के साथ काम करने के लिए काफी परेशान हैं (मैंने इसे किया है)।

• अन्य बैकएंड के लिए पोर्टेबिलिटी के लिए, जब तक आप इनलाइन असेंबली को ज्यादातर "इस स्ट्रिंग को रजिस्टर आवंटन और स्ट्रिंग प्रतिस्थापन के साथ कॉपी-पेस्ट" के स्तर पर रखते हैं, तब तक इसे बैकएंड को इतना अधिक बाधित नहीं करना चाहिए। पूर्णांक स्थिरांक और स्मृति बाधाओं को छोड़ना और केवल बैंक बाधाओं को पंजीकृत करने से कोई समस्या नहीं होनी चाहिए।

प्रक्रियात्मक मैक्रोज़ के साथ क्या किया जा सकता है, यह देखने के लिए मुझे थोड़ा सा खेल चल रहा है। मैंने एक लिखा है जो जीसीसी शैली इनलाइन असेंबली को जंग शैली में परिवर्तित करता है https://github.com/parched/gcc-asm-rs। मैंने एक पर काम करना भी शुरू कर दिया है जो एक डीएसएल का उपयोग करता है जहां उपयोगकर्ता को बाधाओं को समझने की ज़रूरत नहीं है और वे सभी स्वचालित रूप से संभाले जाते हैं।

इसलिए मैं इस निष्कर्ष पर पहुंचा हूं कि मुझे लगता है कि जंग को केवल नंगे बिल्डिंग ब्लॉक्स को स्थिर करना चाहिए, फिर समुदाय मैक्रोज़ के साथ पेड़ से बाहर निकलकर सर्वोत्तम समाधानों के साथ आ सकता है। मूल रूप से, केवल llvm शैली को स्थिर करें जो अब हमारे पास केवल "r" और "i" और शायद "m" बाधाओं के साथ है, और कोई क्लॉबर्स नहीं है। अन्य बाधाओं और क्लॉबर्स को बाद में अपने स्वयं के मिनी आरएफसी प्रकार की चीजों के साथ स्थिर किया जा सकता है।

व्यक्तिगत रूप से मुझे ऐसा लगने लगा है कि इस सुविधा को स्थिर करना एक बहुत बड़ा काम है जो तब तक कभी नहीं होगा जब तक कि कोई पूरे साल के लिए इस पर जोर देने के लिए किसी पूर्णकालिक विशेषज्ञ ठेकेदार को काम पर नहीं रखता। मैं विश्वास करना चाहता हूं कि @parched का asm! टुकड़े टुकड़े को स्थिर करने का सुझाव इसे ट्रैक्टेबल बना देगा। मुझे आशा है कि कोई इसे उठाएगा और इसके साथ चलेगा। लेकिन अगर ऐसा नहीं है, तो हमें उस संतोषजनक समाधान तक पहुंचने की कोशिश करना बंद करना होगा जो कभी नहीं आएगा और असंतोषजनक समाधान के लिए पहुंचेगा जो: asm! को स्थिर करेगा, मौसा, आईसीई, बग और सभी , जंक और गैर-पोर्टेबिलिटी का विज्ञापन करने वाले डॉक्स में उज्ज्वल बोल्ड चेतावनियों के साथ, और किसी दिन अगर एक संतोषजनक कार्यान्वयन चमत्कारिक रूप से अपने स्वर्गीय मेजबान पर, भगवान द्वारा भेजे गए उतरना चाहिए, तो इसे हटाने के इरादे से। IOW, हमें ठीक वही करना चाहिए जो हमने macro_rules! (और निश्चित रूप से, macro_rules! , हमारे पास उन्मत्त बैंड-सहायता और लीक भविष्य-प्रूफिंग की एक संक्षिप्त अवधि हो सकती है)। मैं वैकल्पिक बैकएंड के प्रभावों पर दुखी हूं, लेकिन सिस्टम भाषा के लिए इनलाइन असेंबली को इस तरह के एक लिम्बो में आरोपित करना शर्मनाक है, और हम कई बैकएंड की काल्पनिक संभावना को वास्तव में प्रयोग करने योग्य बैकएंड के अस्तित्व में बाधा नहीं बनने दे सकते। मैं तुमसे भीख माँगता हूँ, मुझे गलत साबित करो!

सिस्टम भाषा के लिए इनलाइन असेंबली को इस तरह के एक लिम्बो में फिर से आरोपित करना शर्मनाक है

डेटा बिंदु के रूप में, मैं अभी एक टोकरा पर काम कर रहा हूं जो स्थिर जंग के साथ कुछ एएसएम उत्सर्जित करने के एकमात्र उद्देश्य के लिए gcc पर निर्भर करता है: https://github.com/main--/unwind- आरएस/ब्लॉब/266e0f26b6423f4a2b8a8c72442b319b5c33b658/src/unwind_helper.c

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

कम से कम बिल्डिंग ब्लॉक्स को अच्छी तरह से डिजाइन किया जाना चाहिए - और मेरी राय में, "expr" : foo : bar : baz निश्चित रूप से नहीं है। मुझे याद नहीं है कि पहली कोशिश में ही मुझे ऑर्डर मिल गया हो, मुझे हमेशा इसे देखना होता है। "मैजिक कैटेगरी को कोलन से अलग किया जाता है, जहां आप मैजिक कैरेक्टर के साथ लगातार स्ट्रिंग्स को निर्दिष्ट करते हैं, जो कि वेरिएबल नामों के लिए मैजिक चीजें करते हैं, जिसे आप किसी भी तरह से मैश भी करते हैं" बस खराब है।

एक विचार,…

आज, पहले से ही एक प्रोजेक्ट है, जिसका नाम dynasm है, जो आपको x64 कोड के एक फ्लेवर के साथ असेंबली को प्री-प्रोसेस करने के लिए उपयोग किए जाने वाले प्लगइन के साथ असेंबली कोड जेनरेट करने में मदद कर सकता है।

यह प्रोजेक्ट इनलाइन असेंबली की समस्या का जवाब नहीं देता है, लेकिन यह निश्चित रूप से मदद कर सकता है, अगर rustc रजिस्टरों को वेरिएबल मैप करने का एक तरीका प्रदान करता है, और कोड में बाइट्स के सेट को सम्मिलित करने के लिए स्वीकार करता है, तो इस तरह के प्रोजेक्ट को भरने के लिए भी इस्तेमाल किया जा सकता है- बाइट्स के इन सेट को।

इस तरह, जंग के दृष्टिकोण से आवश्यक एकमात्र मानकीकरण भाग, उत्पन्न कोड में किसी भी बाइट अनुक्रम को इंजेक्ट करने और विशिष्ट रजिस्टर आवंटन को लागू करने की क्षमता है। यह विशिष्ट भाषाओं के स्वाद के लिए सभी विकल्पों को हटा देता है।

गतिशीलता के बिना भी, इसका उपयोग cpuid / rtdsc निर्देशों के लिए मैक्रोज़ बनाने के तरीके के रूप में भी किया जा सकता है, जिसे केवल बाइट्स के कच्चे अनुक्रम में अनुवादित किया जाएगा।

मुझे लगता है कि अगला प्रश्न यह हो सकता है कि क्या हम बाइट-सीक्वेंस में अतिरिक्त गुण/बाधाएं जोड़ना चाहते हैं।

[संपादित करें: मुझे नहीं लगता कि इस टिप्पणी में मैंने जो कुछ भी कहा है वह सही है।]

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

यदि हम एक बाहरी असेंबलर को तैयार करने के लिए तैयार हैं, तो हम अपने इच्छित किसी भी सिंटैक्स का उपयोग कर सकते हैं, लेकिन फिर हम एकीकृत असेंबलर के फायदों को छोड़ रहे हैं, और जो भी बाहरी असेंबलर हम कॉल कर रहे हैं उसमें परिवर्तन के संपर्क में हैं।

मुझे लगता है कि एलएलवीएम के प्रारूप पर स्थिर होना अजीब होगा जब क्लैंग भी ऐसा नहीं करता है। संभवतः यह आंतरिक रूप से एलएलवीएम के समर्थन का उपयोग करता है, लेकिन यह जीसीसी की तरह एक इंटरफ़ेस प्रस्तुत करता है।

मैं यह कहकर 100% ठीक हूं कि "रस्ट वास्तव में क्लैंग का समर्थन करता है" और इसे एक दिन बुला रहा है, खासकर जब से AFAIK क्लैंग का रुख है "क्लैंग बिल्कुल जीसीसी का समर्थन करता है"। यदि हमारे पास कभी वास्तविक जंग का नमूना है, तो हम भाषा को "इनलाइन असेंबली कार्यान्वयन-परिभाषित" में नरम कर सकते हैं। प्राथमिकता और वास्तविक मानकीकरण शक्तिशाली उपकरण हैं। अगर हम जीसीसी सिंटैक्स को एलएलवीएम में अनुवाद करने के लिए क्लैंग के अपने कोड का पुन: उपयोग कर सकते हैं, तो बेहतर होगा। वैकल्पिक बैकएंड चिंताएं दूर नहीं होती हैं, लेकिन सैद्धांतिक रूप से जीसीसी के लिए एक जंग फ्रंटएंड ज्यादा परेशान नहीं होगा। हमारे लिए डिजाइन करने के लिए कम, हमारे लिए अंतहीन बाइकशेड के लिए कम, हमारे लिए सिखाने के लिए कम, हमारे लिए बनाए रखने के लिए कम।

अगर हम क्लैंग के समर्थन के संदर्भ में परिभाषित किसी चीज को स्थिर करते हैं, तो हमें इसे clang_asm! कहना चाहिए। asm! नाम किसी ऐसी चीज़ के लिए आरक्षित होना चाहिए जिसे अन्य प्रमुख रस्ट सुविधाओं की तरह पूर्ण RFC प्रक्रिया के माध्यम से डिज़ाइन किया गया हो। #बाइक शेड

कुछ चीजें हैं जो मैं रस्ट इनलाइन असेंबली में देखना चाहता हूं:

• टेम्पलेट-साथ-प्रतिस्थापन पैटर्न बदसूरत है। मैं हमेशा असेंबली टेक्स्ट और बाधा सूची के बीच आगे और पीछे कूद रहा हूं। ब्रेविटी लोगों को स्थितीय मापदंडों का उपयोग करने के लिए प्रोत्साहित करती है, जिससे सुगमता खराब हो जाती है। प्रतीकात्मक नामों का अक्सर मतलब होता है कि आपके पास एक ही नाम तीन बार दोहराया गया है: टेम्पलेट में, ऑपरेंड का नामकरण, और अभिव्यक्ति में ऑपरेंड के लिए बाध्य होना। एलेक्स की टिप्पणी में उल्लिखित स्लाइड्स से पता चलता है कि डी और एमएसवीसी आपको कोड में केवल चर का संदर्भ देते हैं, जो बहुत अच्छा लगता है।

• बाधाओं को समझना मुश्किल है, और (ज्यादातर) असेंबली कोड के साथ बेमानी। यदि रस्ट में निर्देशों के पर्याप्त विस्तृत मॉडल के साथ एक एकीकृत असेंबलर था, तो यह त्रुटि और भ्रम के स्रोत को हटाकर, ऑपरेंड पर बाधाओं का अनुमान लगा सकता था। यदि प्रोग्रामर को निर्देश के विशिष्ट एन्कोडिंग की आवश्यकता होती है, तो उन्हें एक स्पष्ट बाधा की आपूर्ति करने की आवश्यकता होगी, लेकिन यह आमतौर पर आवश्यक नहीं होगा।

नॉर्मन रैमसे और मैरी फर्नांडीज ने न्यू जर्सी मशीन कोड टूलकिट के बारे में कुछ कागजात लिखे थे जब उनके पास कॉम्पैक्ट तरीके से असेंबली/मशीन भाषा जोड़े का वर्णन करने के लिए उत्कृष्ट विचार थे। वे (पेंटियम प्रो-युग) iA-32 निर्देश एन्कोडिंग से निपटते हैं; यह स्वच्छ आरआईएससी आईएसए तक ही सीमित नहीं है।

मैं सबसे हाल के कार्य सप्ताह के

• आज, जहाँ तक हम जानते हैं, इस सुविधा के लिए मूल रूप से कोई दस्तावेज़ीकरण नहीं है। इसमें एलएलवीएम इंटर्नल और सभी शामिल हैं।
• जहां तक ​​हम जानते हैं, हमारे पास एलएलवीएम से स्थिरता की कोई गारंटी नहीं है। हम सभी जानते हैं कि एलएलवीएम में इनलाइन असेंबली का कार्यान्वयन किसी भी दिन बदल सकता है।
• यह, वर्तमान में, जंग में एक बहुत ही छोटी सुविधा है। यह (संकलन समय पर) segfaults, ICE, और अजीब LLVM त्रुटियों से भरा हुआ है।
• एक विनिर्देश के बिना इसके लिए एक वैकल्पिक बैकएंड की कल्पना करना भी असंभव है।

मेरे लिए यह "अगर हम इसे अभी स्थिर करते हैं तो हम भविष्य में इसे पछताने की गारंटी देंगे" की परिभाषा है, और न केवल "इसे पछतावा" बल्कि "किसी भी नई प्रणाली को लागू करने के लिए गंभीर समस्याएं पैदा करता है" की बहुत संभावना है।

पूरी तरह से कम से कम मैं दृढ़ता से विश्वास करता हूं कि बुलेट (2) से समझौता नहीं किया जा सकता है (उर्फ "स्थिर चैनल" में स्थिर की परिभाषा)। अन्य गोलियों को छोड़ना काफी दुखद होगा क्योंकि यह रस्ट कंपाइलर की अपेक्षित गुणवत्ता को नष्ट कर देता है जो वर्तमान में काफी अधिक है।

@jcranmer ने लिखा:

एलएलवीएम वास्तव में यह पहचानने के अभ्यास में आश्चर्यजनक रूप से खराब काम करता है कि कौन से रजिस्टरों को पकड़ लिया जाता है, खासकर एलएलवीएम द्वारा उत्पन्न नहीं किए गए निर्देशों में। इसका मतलब यह है कि उपयोगकर्ता के लिए मैन्युअल रूप से यह निर्दिष्ट करना बहुत जरूरी है कि कौन से रजिस्टरों को बंद कर दिया गया है।

मुझे लगता है कि, व्यवहार में, क्लोबर सूचियों का अनुमान लगाना काफी कठिन होगा। सिर्फ इसलिए कि मशीन-भाषा का टुकड़ा एक रजिस्टर का उपयोग करता है इसका मतलब यह नहीं है कि यह उसे पकड़ लेता है; शायद यह इसे बचाता है और इसे पुनर्स्थापित करता है। रूढ़िवादी दृष्टिकोण कोड जनरेटर को रजिस्टरों का उपयोग करने से हतोत्साहित कर सकते हैं जो उपयोग करने के लिए ठीक होगा।

@alexcrichton ने लिखा:

जहां तक ​​हम जानते हैं, हमारे पास एलएलवीएम से स्थिरता की कोई गारंटी नहीं है। हम सभी जानते हैं कि एलएलवीएम में इनलाइन असेंबली का कार्यान्वयन किसी भी दिन बदल सकता है।

LLVM डॉक्स गारंटी देता है "नए रिलीज़ पुराने रिलीज़ से सुविधाओं को अनदेखा कर सकते हैं, लेकिन वे उन्हें गलत तरीके से संकलित नहीं कर सकते।" (आईआर संगतता के संबंध में)। इसके बजाय वे इनलाइन असेंबली को कितना बदल सकते हैं, और, जैसा कि मैंने ऊपर तर्क दिया है, एलएलवीएम स्तर पर वास्तव में कोई व्यवहार्य प्रतिस्थापन नहीं है जो मौजूदा स्थिति से अर्थशास्त्र को मौलिक रूप से बदल देगा (इसके विपरीत, कहें, जहर और undef के आसपास चल रहे मुद्दे)। यह कहना कि इसकी संभावित अस्थिरता इसे रस्ट asm! ब्लॉक के लिए आधार के रूप में उपयोग करने से रोकती है, इसलिए कुछ हद तक बेईमान है। अब यह कहना नहीं है कि इसके साथ अन्य समस्याएं हैं (खराब दस्तावेज़ीकरण, हालांकि इसमें सुधार हुआ है; बाधा की कमी; खराब निदान; और कम-सामान्य परिदृश्यों में बगिया वे हैं जो दिमाग में आते हैं)।

सूत्र पढ़ने में मेरी सबसे बड़ी चिंता यह है कि हम उत्तम को अच्छे का दुश्मन बना लेते हैं। विशेष रूप से, मुझे चिंता है कि कुछ जादू डीएसएल मध्यस्थ की खोज में इनलाइन-एएसएम के लिए प्रयोग करने योग्य रूप में घूमने की कोशिश करने में कुछ सालों लगेंगे क्योंकि लोगों को पता चलता है कि एएसएम पार्सर्स को एकीकृत करना और उन्हें एलएलवीएम के कारण के साथ काम करने की कोशिश करना अधिक समस्याएं हैं। किनारे के मामले।

क्या एलएलवीएम वास्तव में गारंटी दे रहा है कि वे कभी भी ऐसी सुविधा को गलत तरीके से संकलित नहीं करेंगे जिसका व्यवहार उन्होंने कभी निर्दिष्ट नहीं किया है? वे यह भी कैसे तय करेंगे कि कोई परिवर्तन गलत संकलन था या नहीं? मैं इसे IR के अन्य भागों के लिए देख सकता था, लेकिन ऐसा लगता है कि बहुत कुछ अपेक्षित है।

मुझे लगता है कि एलएलवीएम के प्रारूप पर स्थिर होना अजीब होगा जब क्लैंग भी ऐसा नहीं करता है।

क्लैंग ऐसा नहीं करता है क्योंकि इसका उद्देश्य जीसीसी के लिए लिखे गए कोड को संकलित करने में सक्षम होना है। rustc का वह उद्देश्य नहीं है। जीसीसी प्रारूप बहुत एर्गोनोमिक नहीं है इसलिए अंततः मुझे लगता है कि हम ऐसा नहीं चाहते हैं, लेकिन क्या अभी के साथ जाना बेहतर होगा, मैं अनिश्चित हूं। वर्तमान रस्ट प्रारूप का उपयोग करते हुए बहुत सारे (रात में) कोड हैं जो कि अगर हम जीसीसी शैली में बदल जाते हैं तो टूट जाएगा, इसलिए शायद यह केवल तभी बदलने लायक है जब हम कुछ बेहतर तरीके से आ सकें।

कम से कम बिल्डिंग ब्लॉक्स को अच्छी तरह से डिजाइन किया जाना चाहिए - और मेरी राय में, "expr" : foo : bar : baz निश्चित रूप से नहीं है।

माना। कम से कम मैं कच्चे एलएलवीएम प्रारूप को पसंद करता हूं जहां बाधाएं और क्लॉबर्स सभी एक सूची में हैं। वर्तमान में "=" उपसर्ग निर्दिष्ट करने और इसे आउटपुट सूची में डालने के लिए एक अतिरेक है। मुझे यह भी लगता है कि एलएलवीएम इसे फ़ंक्शन कॉल की तरह कैसे मानता है जहां आउटपुट अभिव्यक्ति का परिणाम है, AFAIK वर्तमान asm! कार्यान्वयन जंग का एकमात्र हिस्सा है जिसमें "आउट" पैरामीटर हैं।

एलएलवीएम वास्तव में यह पहचानने के अभ्यास में आश्चर्यजनक रूप से खराब काम करता है कि कौन से रजिस्टरों को पकड़ लिया जाता है

AFAIK LLVM ऐसा करने का प्रयास नहीं करता है क्योंकि इनलाइन असेंबली का मुख्य कारण कुछ कोड शामिल करना है जो एलएलवीएम समझ में नहीं आता है। यह वास्तविक असेंबली को देखे बिना केवल आवंटन और टेम्पलेट प्रतिस्थापन पंजीकृत करता है। (जाहिर है यह मशीन कोड उत्पन्न करने के लिए किसी चरण में वास्तव में असेंबली को पार करता है, लेकिन मुझे लगता है कि बाद में ऐसा होता है)

अगर हम बाहरी असेंबलर को तैयार करने के इच्छुक हैं

मुझे यकीन नहीं है कि एकीकृत इनलाइन असेंबलर का उपयोग करने का कोई विकल्प हो सकता है क्योंकि कुछ आपको इसके लिए रजिस्टर आवंटित करने के लिए एलएलवीएम कैसे प्राप्त करना होगा। हालांकि वैश्विक असेंबली के लिए, एक बाहरी असेंबलर काम करने योग्य होगा।

एलएलवीएम इनलाइन असेंबलर में परिवर्तन को तोड़ने के संबंध में, हम क्लैंग के समान नाव में हैं। यानी, अगर वे कुछ बदलाव करते हैं, तो हमें उनके होने पर बस उनके आसपास काम करना होगा।

अगर हम क्लैंग के समर्थन के संदर्भ में परिभाषित किसी चीज को स्थिर करते हैं, तो हमें इसे क्लैंग_आस्म कहना चाहिए। एएसएम! नाम किसी ऐसी चीज़ के लिए आरक्षित होना चाहिए जिसे पूरी RFC प्रक्रिया के माध्यम से डिज़ाइन किया गया हो, जैसे अन्य प्रमुख रस्ट सुविधाएँ। #बाइक शेड

मैं इसके पक्ष में हूँ। +1

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

@parched ऊपर उद्धृत @jimblandy के सुझाव के अनुसार, asm! का उपयोग करने वाला कोई भी व्यक्ति खुशी से अभी भी इसका उपयोग करने में सक्षम होगा।

आज, जहाँ तक हम जानते हैं, इस सुविधा के लिए मूल रूप से कोई दस्तावेज़ीकरण नहीं है। इसमें एलएलवीएम इंटर्नल और सभी शामिल हैं।

यदि GCC का असेंबली सिंटैक्स वास्तव में 30 वर्षों के बाद निर्दिष्ट या प्रलेखित नहीं है, तो यह मान लेना सुरक्षित लगता है कि या तो एक प्रलेखित असेंबली सबलैंग्वेज का निर्माण एक ऐसा कार्य है जो या तो इतना कठिन है कि यह हमारे सीमित संसाधनों को पूरा करने की रस्ट की क्षमता से परे है, या वह जो लोग असेंबली का उपयोग करना चाहते हैं वे परवाह नहीं करते हैं।

जहां तक ​​हम जानते हैं, हमारे पास एलएलवीएम से स्थिरता की कोई गारंटी नहीं है। हम सभी जानते हैं कि एलएलवीएम में इनलाइन असेंबली का कार्यान्वयन किसी भी दिन बदल सकता है।

ऐसा लगता नहीं है कि जीसीसी/क्लैंग का इनलाइन असेंबली का कार्यान्वयन कभी भी बदलेगा, क्योंकि यह 90 के दशक से लिखे गए सभी सी कोड को तोड़ देगा।

एक विनिर्देश के बिना इसके लिए एक वैकल्पिक बैकएंड की कल्पना करना भी असंभव है।

कठोर होने के जोखिम पर, वैकल्पिक बैकएंड की संभावना मूक है यदि रस्ट एक भाषा के रूप में असेंबली में गिरने की शर्मनाक अक्षमता के कारण जीवित नहीं रहती है। रात जब तक करने के लिए चाहता है मौन विचार यह है कि रात जंग है, जो और अधिक कमजोर करने के लिए LLVM परिवर्तन की संभावना से जंग की स्थिरता की गारंटी करता है समर्थन, पर्याप्त नहीं है।

अन्य गोलियों को छोड़ना काफी दुखद होगा क्योंकि यह रस्ट कंपाइलर की अपेक्षित गुणवत्ता को नष्ट कर देता है जो वर्तमान में काफी अधिक है।

मैं झूठ नहीं बोल रहा हूं जब मैं कहता हूं कि हर दिन मैं रस्ट डेवलपर्स के रवैये और गुणवत्ता के विशाल मानक के लिए आभारी हूं जो वे खुद को रखते हैं (वास्तव में कभी-कभी मैं चाहता हूं कि आप सभी धीमा हो जाएं ताकि आप उस गुणवत्ता को बनाए रख सकें ब्रायन की तरह खुद को जलाए बिना)। हालाँकि, जब लुकमाना ने चार साल पहले asm! मैक्रो को जोड़ा था, तब किसी के रूप में बोलना, और जिसने तब से इसे स्थिर करने में कोई प्रगति नहीं देखी है, और जो दुख की बात है कि रस्ट में क्रिप्टो अभी भी असंभव है और वह SIMD क्रॉस-प्लेटफ़ॉर्म इंटरफ़ेस को धीरे-धीरे निर्धारित किया जा रहा है, जबकि जंग में कोई समाधान नहीं है, मैं निराश महसूस करता हूं। अगर मैं यहां पर जोर देता हूं तो ऐसा इसलिए है क्योंकि मैं इस मुद्दे को परियोजना के अस्तित्व के अस्तित्व के रूप में देखता हूं। यह इस समय संकट नहीं हो सकता है, लेकिन किसी भी चीज को स्थिर करने में समय लगेगा, और हमारे पास इतने साल नहीं हैं कि एक विश्व स्तरीय असेंबली बोली को खरोंच से डिजाइन और कार्यान्वित करने में लगें (तथ्य से सिद्ध) कि हमने पिछले चार वर्षों में इस दिशा में कोई प्रगति नहीं की है)। 2018 में कभी-कभी जंग को स्थिर इनलाइन असेंबली की आवश्यकता होती है। हमें इसे खींचने के लिए पूर्व कला की आवश्यकता होती है। macro_rules! स्थिति ने स्वीकार किया कि कभी-कभी बदतर बेहतर होता है। एक बार फिर, मैं किसी से भीख माँग रहा हूँ मुझे गलत साबित करने के लिए।

FWIW और पार्टी में देर से आना मुझे पसंद है जो @florob की कोलोन टॉक प्रस्तावित है। जिन लोगों ने इसे नहीं देखा है, उनके लिए इसका सार है:

// Add 5 to variable:
let mut var = 0;
unsafe {
    asm!("add $5, {}", inout(reg) var);
}

// Get L1 cache size
let ebx: i32;
let ecx: i32;
unsafe {
    asm!(r"
        mov $$4, %eax;
        xor %ecx, %ecx;
        cpuid;
        mov %ebx, {};",
        out(reg) ebx, out(ecx) ecx, clobber(eax, ebx, edx)
    );
}
println!("L1 Cache: {}", ((ebx >> 22) + 1)
    * (((ebx >> 12) & 0x3ff) + 1)
    * ((ebx & 0xfff) + 1) * (ecx + 1));

निम्नलिखित रणनीति के बारे में कैसे: वर्तमान asm का नाम बदलकर llvm_asm (साथ ही शायद कुछ मामूली बदलाव) और बताएं कि यह व्यवहार एलएलवीएम का कार्यान्वयन विवरण है, इस प्रकार जंग स्थिरता गारंटी पूरी तरह से विस्तारित नहीं होती है? उपयोग किए गए बैकएंड के आधार पर सशर्त संकलन के लिए target_feature जैसी कार्यक्षमता के साथ विभिन्न बैकएंड की समस्या को कमोबेश हल किया जाना चाहिए। हां, इस तरह के दृष्टिकोण से जंग की स्थिरता थोड़ी धुंधली हो जाएगी, लेकिन असेंबली को इस तरह सीमित रखना जंग के लिए अपने तरीके से हानिकारक है।

मैंने इंटर्नल फोरम के लिए वैकल्पिक सिंटैक्स प्रस्ताव के साथ एक प्री-आरएफसी पोस्ट किया है: https://internals.rust-lang.org/t/pre-rfc-inline-assembly/6443 । प्रतिक्रिया का स्वागत है।

यह मुझे ऐसा लगता है जैसे यहाँ सबसे अच्छा निश्चित रूप से ठीक-ठाक का दुश्मन है। मैं अभी के लिए संगत सिंटैक्स और शब्दार्थ के साथ gcc_asm! या clang_asm! या llvm_asm! मैक्रो (या उसका कोई उचित उपसमुच्चय) को स्थिर रखने का पूर्ण समर्थन करता हूं, जबकि एक बेहतर समाधान निकाला जाता है . मैं एक बड़े रखरखाव बोझ के रूप में इस तरह की चीज का समर्थन हमेशा के लिए नहीं देखता: ऊपर प्रस्तावित अधिक परिष्कृत सिस्टम ऐसे दिखते हैं जैसे वे पुराने शैली के मैक्रोज़ को नए के लिए सिंटैक्टिक सैकरीन में बदलने में आसानी से समर्थन करेंगे।

मेरे पास एक बाइनरी प्रोग्राम है http://[email protected]/BartMassey/popcount जिसके लिए x86_64 popcntl निर्देश के लिए इनलाइन असेंबली की आवश्यकता है। यह इनलाइन असेंबली इस कोड को रात में रखने वाली एकमात्र चीज है। कोड 12 साल पुराने C प्रोग्राम से लिया गया था।

अभी, मेरी असेंबली की शर्त है

    #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]

और फिर cpuid जानकारी प्राप्त करता है यह देखने के लिए कि popcnt मौजूद है या नहीं। रस्ट में हाल की Google cpu_features लाइब्रेरी https://opensource.googleblog.com/2018/02/cpu-features-library.html के समान कुछ होना अच्छा होगा, लेकिन c'est la vie।

क्योंकि यह एक डेमो प्रोग्राम जितना कुछ भी है, मैं इनलाइन असेंबली रखना चाहता हूं। वास्तविक कार्यक्रमों के लिए, count_ones() आंतरिक पर्याप्त होगा - सिवाय इसके कि इसे popcntl का उपयोग करने के लिए कार्गो को "-सी लक्ष्य-सीपीयू = देशी" पास करने की आवश्यकता है, शायद RUSTFLAGS माध्यम से (समस्या #1137 और कई संबंधित मुद्दे देखें) मेरे स्रोत के साथ .cargo/config वितरित करने के बाद से यह एक अच्छा विचार नहीं लगता है, जिसका अर्थ है कि अभी मुझे मेकफ़ाइल कॉलिंग कार्गो मिल गया है।

संक्षेप में, यह अच्छा होगा यदि कोई वास्तविक अनुप्रयोगों में इंटेल और अन्य के फैंसी पॉपकाउंट निर्देश का उपयोग कर सकता है, लेकिन यह जितना कठिन होना चाहिए, उससे कहीं अधिक कठिन लगता है। इंट्रिनिक्स पूरी तरह से जवाब नहीं हैं। वर्तमान asm! एक ठीक उत्तर है जो स्थिर में उपलब्ध था। इनलाइन असेंबली के लिए बेहतर वाक्यविन्यास और अर्थशास्त्र होना बहुत अच्छा होगा, लेकिन मुझे वास्तव में इसकी आवश्यकता नहीं है। target-cpu=native सीधे Cargo.toml निर्दिष्ट करने में सक्षम होना बहुत अच्छा होगा, लेकिन यह वास्तव में मेरी समस्या का समाधान नहीं करेगा।

क्षमा करें, घूमना। बस सोचा कि मैं साझा करूंगा कि मुझे इसकी परवाह क्यों है।

@BartMassey मुझे समझ में नहीं आता, आपको popcnt को संकलित करने की इतनी सख्त आवश्यकता क्यों है? एकमात्र कारण जो मैं देख सकता हूं वह है प्रदर्शन और आईएमओ आपको निश्चित रूप से उस मामले में केवल count_ones() का उपयोग करना चाहिए। आप जो खोज रहे हैं वह इनलाइन एएसएम नहीं है बल्कि target_feature (जंग-लैंग/आरएफसीएस # 2045) है ताकि आप संकलक को बता सकें कि इसे पॉपकंट उत्सर्जित करने की अनुमति है।

@BartMassey आपको इसके लिए इनलाइन असेंबली का उपयोग करने की भी आवश्यकता नहीं है, बस coresimd cfg_feature_enabled!("popcnt") का उपयोग यह पूछने के लिए करें कि क्या आपका बाइनरी सीपीयू popcnt निर्देश का समर्थन करता है (यह होगा इसे संकलन-समय पर हल करें यदि ऐसा करना संभव हो)।

coresimd एक popcnt आंतरिक भी प्रदान करता है जो popcnt निर्देश का उपयोग करने की गारंटी है।

@gnzlbg

coresimd एक popcnt इंट्रिन्सिक भी प्रदान करता है जो कि popcnt निर्देश का उपयोग करने की गारंटी देता है।

यह थोड़ा विषय से हटकर है, लेकिन यह कथन कड़ाई से सत्य नहीं है। _popcnt64 हुड के नीचे leading_zeros _popcnt64 का उपयोग करता है , इस प्रकार यदि popcnt सुविधा क्रेट उपयोगकर्ता द्वारा सक्षम नहीं की जाएगी और क्रेट लेखक #![cfg(target_feature = "popcnt")] का उपयोग करना भूल जाएगा तो यह आंतरिक प्राप्त होगा अप्रभावी असेंबली में संकलित और इसके खिलाफ कोई सुरक्षा उपाय नहीं है।

इस प्रकार यदि क्रेट उपयोगकर्ता द्वारा popcnt सुविधा सक्षम नहीं की जाएगी

यह गलत है क्योंकि आंतरिक बिना शर्त के आंतरिक के लिए #[target_feature(enable = "popcnt")] विशेषता को सक्षम करने के लिए popcnt विशेषता का उपयोग करता है, स्वतंत्र रूप से जो टोकरा उपयोगकर्ता सक्षम या अक्षम करता है। साथ ही, assert_instr(popcnt) विशेषता यह सुनिश्चित करती है कि रस्ट द्वारा समर्थित सभी x86 प्लेटफॉर्म पर आंतरिक popcnt में अलग हो जाए।

यदि कोई x86 प्लेटफॉर्म पर रस्ट का उपयोग कर रहा है जिसका रस्ट वर्तमान में समर्थन नहीं करता है, तो यह सुनिश्चित करने के लिए कि ये इंट्रिनिक्स उस लक्ष्य पर popcnt उत्पन्न करते हैं, यह सुनिश्चित करने के लिए core पोर्टिंग कर रहा है।

संपादित करें: @ newpavlov

इस प्रकार यदि क्रेट उपयोगकर्ता द्वारा popcnt सुविधा सक्षम नहीं की जाएगी और क्रेट लेखक #![cfg(target_feature = "popcnt")] का उपयोग करना भूल जाएगा, तो यह आंतरिक अप्रभावी असेंबली में संकलित हो जाएगा और इसके खिलाफ कोई सुरक्षा उपाय नहीं है।

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

सबसे पहले, चर्चा को पटरी से उतारने के लिए खेद है। बस अपने मुख्य बिंदु को दोहराना चाहता था, जो था "मैं पूरी तरह से एक gcc_asm! या clang_asm! या llvm_asm! मैक्रो (या किसी भी उचित उपसमुच्चय) को स्थिर रूप से संगत सिंटैक्स और शब्दार्थ के साथ स्थिर करने का समर्थन करता हूं, जबकि एक बेहतर समाधान पर काम किया जाता है। "

इनलाइन असेंबली की बात यह है कि यह एक पॉपकाउंट बेंचमार्क/डेमो है। मैं एक वास्तविक गारंटीकृत popcntl निर्देश चाहता हूं, जब संभव हो तो दोनों एक आधार रेखा के रूप में और इनलाइन असेंबली का उपयोग करने का तरीका बताने के लिए। मैं यह भी गारंटी देना चाहता हूं कि count_ones() संभव होने पर एक पॉपकाउंट निर्देश का उपयोग करता है ताकि जीसीसी और क्लैंग की तुलना में रस्टक भयानक न दिखे।

target_feature=popcnt को इंगित करने के लिए धन्यवाद। मैं इस बारे में सोचूंगा कि इसका उपयोग यहां कैसे किया जाए। मुझे लगता है कि मैं count_ones() बेंचना चाहता हूं, भले ही उपयोगकर्ता किस सीपीयू के लिए संकलन कर रहा हो और इस पर ध्यान दिए बिना कि उसके पास पॉपकाउंट निर्देश है या नहीं। मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि यदि लक्ष्य सीपीयू में पॉपकाउंट count_ones() इसका उपयोग करता है।

stdsimd / coresimd क्रेट अच्छे लगते हैं, और संभवतः इन बेंचमार्क के लिए सक्षम होना चाहिए। धन्यवाद! इस ऐप के लिए मैं मानक भाषा सुविधाओं के बाहर जितना संभव हो उतना कम उपयोग करना पसंद करूंगा (मैं पहले से ही lazy_static बारे में दोषी महसूस कर रहा हूं)। हालांकि, इन सुविधाओं को नज़रअंदाज करना बहुत अच्छा लगता है, और ऐसा लगता है कि ये "आधिकारिक" बनने की राह पर हैं।

@nbp द्वारा चारों ओर एक विचार तैरता है जहां कुछ कार्यान्वयन हो सकता है जो कोड के कुछ प्रतिनिधित्व से मशीन बाइट्स तक जाता है (एक प्रो-मैक्रो क्रेट या कुछ हो सकता है?) और फिर उन बाइट्स को सीधे कोड में विशेष स्थान में शामिल किया जाता है।

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

सीसी @eddyb

@nagisa यह मशीन कोड के सिर्फ एक चक से थोड़ा अधिक है, हालांकि, आपको इनपुट, आउटपुट और क्लॉबर रजिस्टरों के बारे में भी सावधान रहना होगा। यदि एएसएम खंड कहता है कि यह% rax में एक निश्चित चर चाहता है और यह% esi को पकड़ लेगा तो आपको यह सुनिश्चित करने की ज़रूरत है कि आसपास का कोड अच्छा चलता है। इसके अलावा अगर डेवलपर संकलक को रजिस्टरों को आवंटित करने देता है तो आप शायद स्पिलिंग और मूल्यों को स्थानांतरित करने से बचने के लिए आवंटन को अनुकूलित करना चाहेंगे।

@ सिमियास , वास्तव में आपको यह निर्दिष्ट करना होगा कि चर विशिष्ट रजिस्टरों से कैसे जुड़े हैं, और कौन से रजिस्टरों को बंद कर दिया गया है, लेकिन ये सभी किसी भी असेंबली भाषा, या किसी एलएलवीएम असेंबली भाषा को मानकीकृत करने से छोटा है।

बाइट अनुक्रमों पर मानकीकरण, असेंबली स्वाद को ड्राइवर/प्रो-मैक्रो में ले जाकर शायद सबसे आसान तरीका है।

उचित इनलाइन असेंबली के बजाय वर्बैटिम बाइट्स रखने का एक मुद्दा यह है कि कंपाइलर के पास अल्फा-नामकरण रजिस्टर करने का कोई विकल्प नहीं होगा, जिसकी मुझे उम्मीद नहीं है कि इनलाइन असेंबली लिखने वाले लोग या तो उम्मीद कर रहे हैं।

लेकिन अगर मैं कंपाइलर को इसे संभालने देना चाहता हूं तो यह रजिस्टर आवंटन के साथ कैसे काम करेगा? उदाहरण के लिए, GCC's (अत्याचारी) सिंटैक्स का उपयोग करना:

asm ("leal (%1, %1, 4), %0"
     : "=r" (five_times_x)
     : "r" (x));

कुछ इस तरह से मैंने संकलक को रजिस्टरों को आवंटित करने दिया, यह उम्मीद करते हुए कि यह मुझे वह देगा जो सबसे सुविधाजनक और कुशल है। उदाहरण के लिए x86 64 पर यदि five_time_x वापसी मूल्य है तो संकलक eax आवंटित कर सकता है और यदि x एक फ़ंक्शन पैरामीटर है तो यह पहले से ही कुछ रजिस्टर में उपलब्ध हो सकता है। बेशक संकलक केवल यह जानता है कि यह संकलन अनुक्रम में बहुत देर से रजिस्टरों को कैसे आवंटित करेगा (विशेषकर यदि यह केवल फ़ंक्शन पैरा और रिटर्न वैल्यू के रूप में छोटा नहीं है)।

क्या आपका प्रस्तावित समाधान कुछ इस तरह काम करेगा?

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

@nbp

वास्तव में आपको यह निर्दिष्ट करना होगा कि चर विशिष्ट रजिस्टरों से कैसे जुड़े हैं, और कौन से रजिस्टरों को बंद कर दिया गया है, लेकिन ये सभी किसी भी असेंबली भाषा, या किसी एलएलवीएम असेंबली भाषा को मानकीकृत करने से छोटा है।

तो यह कैसे किया जाएगा? मेरे पास हार्डकोडेड रजिस्टरों के साथ बाइट्स का अनुक्रम है जिसका मूल रूप से मतलब है कि इनपुट/आउट रजिस्ट्रार, क्लॉबर्स इत्यादि बाइट्स के इस अनुक्रम के अंदर हार्डकोड किए गए हैं।

अब मैं इस बाइट्स को अपने जंग बाइनरी में कहीं इंजेक्ट करता हूं। मैं रस्टसी को कैसे बता सकता हूं कि कौन से रजिस्टर इनपुट/आउटपुट हैं, कौन से रजिस्टरों को बंद कर दिया गया है, आदि? इनलाइन असेंबली को स्थिर करने की तुलना में हल करने के लिए यह एक छोटी सी समस्या कैसे है? यह मुझे लगता है कि यह वही है जो इनलाइन असेंबली करता है, बस थोड़ा कठिन हो सकता है क्योंकि अब किसी को लिखित असेंबली में इनपुट/आउटपुट क्लॉबर्स को दो बार निर्दिष्ट करने की आवश्यकता होती है, और जिस तरह से हम इस जानकारी को रस्टसी में पास करते हैं। इसके अलावा, rustc के पास इसे सत्यापित करने में आसान समय नहीं होगा, क्योंकि इसके लिए इसे बाइट्स के अनुक्रम को असेंबली में पार्स करने में सक्षम होना चाहिए, और फिर उसका निरीक्षण करना होगा। मुझे किसकी याद आ रही है?

@सिमियास

asm ("leal (%1, %1, 4), %0"
     : "=r" (five_times_x)
     : "r" (x));

यह संभव नहीं होगा, क्योंकि कच्चे बाइट्स रजिस्टरों के अल्फा नामकरण की अनुमति नहीं देते हैं, और रजिस्टरों को आगे कोड अनुक्रम द्वारा लागू करना होगा।

@ फ्लोरोब

कम से कम मेरे लिए, आधार हमेशा यह था कि सिस्टम असेंबलर द्वारा उपयोग की जाने वाली असेंबली भाषा स्वीकार की जाएगी।

मेरी समझ, यह है कि सिस्टम असेंबलर पर भरोसा करना कुछ ऐसा नहीं है जिस पर हम भरोसा करना चाहते हैं, बल्कि एएसएम के हिस्से के रूप में एक स्वीकृत दोष है! मैक्रो। एएसएम पर भी निर्भर! एलएलवीएम सिंटैक्स होना अतिरिक्त बैकएंड के विकास के लिए दर्दनाक होगा।

@gnzlbg

तो यह कैसे किया जाएगा? मेरे पास हार्डकोडेड रजिस्टरों के साथ बाइट्स का अनुक्रम है जिसका मूल रूप से मतलब है कि इनपुट/आउट रजिस्ट्रार, क्लॉबर्स इत्यादि बाइट्स के इस अनुक्रम के अंदर हार्डकोड किए गए हैं।

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

fn swap(a: u32, b: u32) -> (u32, u32) {
  unsafe{
    asm_raw!{
       bytes: [0x91],
       inputs: [(std::asm::eax, a), (std::asm::ecx, b)],
       clobbered: [],
       outputs: (std::asm::eax, std::asm::ecx),
    }
  }
}

यह कोड अनुक्रम कुछ कंपाइलर प्रक्रियात्मक मैक्रो का आउटपुट हो सकता है, जो इस तरह दिख सकता है:

fn swap(a: u32, b: u32) -> (u32, u32) {
  unsafe{
    asm_x64!{
       ; <-- (eax, a), (ecx, b)
       xchg eax, ecx
       ; --> (eax, ecx)
    }
  }
}

ये क्रम, किसी भी प्रतीक या पते को सीधे एम्बेड करने में सक्षम नहीं होंगे और उन्हें गणना और रजिस्टर के रूप में देना होगा। मुझे यकीन है कि हम यह पता लगा सकते हैं कि बाद में बाइट अनुक्रम के भीतर कुछ प्रतीक पतों को सम्मिलित करने की क्षमता को कैसे जोड़ा जाए।

इस दृष्टिकोण का लाभ यह है कि केवल रजिस्टरों और बाधाओं की सूची को मानकीकृत किया जाना है, और यह कुछ ऐसा है जो भविष्य के किसी भी बैकएंड द्वारा आसानी से समर्थित होगा।

@nbp

मेरी समझ, यह है कि सिस्टम असेंबलर पर भरोसा करना कुछ ऐसा नहीं है जिस पर हम भरोसा करना चाहते हैं, बल्कि एएसएम के हिस्से के रूप में एक स्वीकृत दोष है! मैक्रो। एएसएम पर भी निर्भर! एलएलवीएम सिंटैक्स होना अतिरिक्त बैकएंड के विकास के लिए दर्दनाक होगा।

मुझे नहीं लगता कि यह एक सटीक आकलन है? X86 असेंबली के लिए दो अलग-अलग सिंटैक्स के मामूली अपवाद के साथ, असेंबली सिंटैक्स काफी हद तक मानक और पोर्टेबल है। सिस्टम असेंबलर के साथ एकमात्र मुद्दा यह हो सकता है कि इसमें नए निर्देशों की कमी है, लेकिन यह एक विशिष्ट स्थिति है जिसे अनुकूलित करने के लायक नहीं है।

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

मैं मानता हूं कि इस सामान के लिए एलएलवीएम (या जीसीसी) सिंटैक्स बकवास है, लेकिन प्रीकंपिल्ड बाइट्स में जाने का मतलब है कि किसी भी एएसएम क्रेट को अब एक पूर्ण असेंबलर और संभवतः एक पूर्ण रजिस्टर आवंटक स्थापित करने की आवश्यकता है (या प्रोग्रामर को हाथ से आवंटित रजिस्टर बनाने की जरूरत है), या प्रयास करें सिस्टम असेंबलर का उपयोग करने के लिए। उस समय, ऐसा नहीं लगता कि यह वास्तव में बहुत अधिक मूल्य जोड़ रहा है।

@jcranmer

... लेकिन प्रीकंपील्ड बाइट्स में जाने का मतलब है कि किसी भी एएसएम क्रेट को अब एक पूर्ण असेंबलर और संभावित रूप से एक पूर्ण रजिस्टर आवंटक स्थापित करने की आवश्यकता है (या प्रोग्रामर को हाथ से आवंटित रजिस्टर बनाएं), या सिस्टम असेंबलर का उपयोग करने का प्रयास करें

https://github.com/CensoredUsername/dynasm-rs

यह टोकरा असेंबली कोड को इकट्ठा करने के लिए एक प्लगइन द्वारा नियंत्रित मैक्रो का उपयोग करता है और रनटाइम पर कच्चे असेंबली कोड के वैक्टर उत्पन्न करता है।

@nbp शायद मेरे उपयोग के मामले अजीबोगरीब हैं, लेकिन रजिस्टर का नाम बदलने की कमी और कंपाइलर को मेरे लिए रजिस्टर आवंटित करने की अनुमति देना एक सौदा-ब्रेकर होगा क्योंकि इसका या तो मतलब है कि मुझे रजिस्टरों की अपनी पसंद के साथ बहुत भाग्यशाली होने की आवश्यकता है और ऐसा होता है " हिट राइट" या कंपाइलर को मेरे मनमाने सम्मेलनों से मेल खाने के लिए रजिस्टरों को फेरबदल करने के लिए गैर-इष्टतम कोड का उत्सर्जन करना होगा।

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

और क्या होगा यदि एएसएम कोड बाहरी प्रतीकों को कॉल करता है जिसे लिंकर द्वारा हल किया जाएगा? आपको उस जानकारी को इधर-उधर करने की आवश्यकता है क्योंकि आप संकलन प्रक्रिया में देर होने तक संभवतः उन्हें हल नहीं कर सकते। आपको अपने बाइट सरणी के साथ संदर्भ पास करना होगा और लिंकर को बाद में उन्हें हल करने देना होगा।

@jcranmer

X86 असेंबली के लिए दो अलग-अलग सिंटैक्स के मामूली अपवाद के साथ, असेंबली सिंटैक्स काफी हद तक मानक और पोर्टेबल है।

मुझे यकीन नहीं है कि मैं समझता हूं कि आपका क्या मतलब है, जाहिर है कि एएसएम सिंटैक्स आर्किटेक्चर में पोर्टेबल नहीं है। और यहां तक ​​​​कि एक ही वास्तुकला के भीतर अक्सर भिन्नताएं और विकल्प होते हैं जो भाषा को इकट्ठा करने के तरीके को बदलते हैं।

मैं एक उदाहरण के रूप में एमआईपीएस दे सकता हूं, दो महत्वपूर्ण कॉन्फ़िगरेशन झंडे हैं जो असेंबलर व्यवहार को बदलते हैं: at और reorder । at कहता है कि कुछ छद्म निर्देशों को असेंबल करते समय असेंबलर को AT (असेंबलर अस्थायी) रजिस्टर का उपयोग करने की अनुमति है या नहीं। डेटा स्टोर करने के लिए स्पष्ट रूप से AT का उपयोग करने वाले कोड को at साथ असेंबल किया जाना चाहिए अन्यथा यह टूट जाएगा।

reorder परिभाषित करता है कि कोडर मैन्युअल रूप से शाखा विलंब स्लॉट को संभालता है या यदि वे उनसे निपटने के लिए असेंबलर पर भरोसा करते हैं। गलत reorder सेटिंग के साथ कोड असेंबल करना लगभग निश्चित रूप से फर्जी मशीन कोड उत्पन्न करेगा। जब आप एमआईपीएस असेंबली लिखते हैं तो आपको हर समय वर्तमान मोड से अवगत होना चाहिए यदि इसमें कोई शाखा निर्देश शामिल है। उदाहरण के लिए इस MIPS सूची का अर्थ जानना असंभव है यदि आप नहीं जानते कि reorder सक्षम है या नहीं:

    addui   $a0, 4
    jal     some_func
    addui   $a1, $s0, 3

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

   ldr   r2, =0x89abcdef

दूसरी ओर एमआईपीएस तत्काल मूल्य को दो 16 बिट मानों में विभाजित करता है और लुई/ओरी या लुई/एंडी कॉम्बो का उपयोग करता है। यह आमतौर पर li / la छद्म निर्देशों के पीछे छिपा होता है, लेकिन यदि आप noreorder के साथ कोड लिख रहे हैं और विलंब स्लॉट को बर्बाद नहीं करना चाहते हैं तो कभी-कभी आपको संभालना पड़ता है यह हाथ से जिसके परिणामस्वरूप अजीब दिखने वाला कोड होता है:

.set noreorder

   /* Display a message using printf */
   lui $a0, %hi(hello)
   jal printf
   ori $a0, %lo(hello)

.data

hello:
.string "Hello, world!\n"

%hi और %lo निर्माण क्रमशः hello प्रतीक के उच्च और निम्न 16 बिट के संदर्भ उत्पन्न करने के लिए असेंबली को बताने का एक तरीका है।

कुछ कोड को बहुत ही अजीब संरेखण बाधाओं की आवश्यकता होती है (उदाहरण के लिए जब आप कैश अमान्यता कोड से निपट रहे होते हैं, तो आपको यह सुनिश्चित करने की आवश्यकता होती है कि आप जिस शाखा पर बैठे हैं, उस पर ध्यान न दें)। और बाहरी प्रतीकों को संभालने की समस्या है जिसे इस बिंदु पर संकलन प्रक्रिया में हल नहीं किया जा सकता है जैसा कि मैंने पहले उल्लेख किया था।

मुझे यकीन है कि मैं अन्य आर्किटेक्चर के समूह के लिए विशिष्टताओं के साथ आ सकता हूं जिनसे मैं कम परिचित हूं। इन कारणों से मुझे यकीन नहीं है कि मैं मैक्रो/डीएसएल दृष्टिकोण के लिए बहुत आशावादी हूं। मैं समझता हूं कि कोड के बीच में एक यादृच्छिक अपारदर्शी स्ट्रिंग अक्षरशः सुपर सुरुचिपूर्ण नहीं है, लेकिन मैं वास्तव में नहीं देखता कि पूर्ण एएसएम सिंटैक्स को जंग में एकीकृत करने के लिए समर्थन जोड़ने पर अतिरिक्त सिरदर्द को छोड़कर हमें क्या मिलेगा एक नई वास्तुकला।

एक असेंबलर लिखना कुछ ऐसा है जो एक नज़र में मामूली लग सकता है लेकिन अगर आप सभी आर्किटेक्चर की सभी घंटियों, सीटी और विचित्रताओं का समर्थन करना चाहते हैं तो यह बहुत मुश्किल हो सकता है।

दूसरी तरफ बाइंडिंग और क्लॉबर्स को निर्दिष्ट करने का एक अच्छा तरीका बेहद मूल्यवान होगा (जीसीसी के ... पूर्ण वाक्यविन्यास की तुलना में)।

हाय दोस्तों,

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

लेकिन यह असेंबली चीज सिर्फ पागल है, मेरा मतलब है, यह तीन साल की अवधि की बातचीत है, विचारों और शिकायतों का एक समूह है, लेकिन ऐसा कुछ भी नहीं है जो न्यूनतम सहमति की तरह लगता है। तीन साल और आरएफसी नहीं, यह मौत के अंत जैसा लगता है। मैं एक विनम्र गणित पुस्तकालय विकसित कर रहा हूं (उम्मीद है कि दो या तीन बक्से में भौतिक होगा), और मेरे लिए (और मुझे संदेह है कि जंग में असेंबली लिखने में रुचि रखने वाले किसी भी अन्य साथी के लिए), सबसे महत्वपूर्ण बात वास्तव में सक्षम होना है करने के लिए कर दो! एक न्यूनतम गारंटी के साथ कि अगले दिन सब कुछ नहीं बदलने वाला है (यही अस्थिर चैनल है, और विशेष रूप से यह वार्तालाप, मुझे महसूस कराता है)।

मैं समझता हूं कि यहां हर कोई सबसे अच्छा समाधान चाहता है, और हो सकता है कि एक दिन कोई उसके साथ आए, लेकिन आज के लिए मेरा मानना ​​​​है कि वर्तमान मैक्रो ठीक है (ठीक है, शायद कुछ मायनों में थोड़ा सीमित है, लेकिन उम्मीद है कि ऐसा कुछ भी नहीं हो सकता है) वृद्धिशील तरीके से संबोधित किया जाए)। असेंबली लिखना सिस्टम भाषा में सबसे महत्वपूर्ण चीज की तरह है, एक बहुत ही आवश्यक विशेषता है, और हालांकि मैं ठीक होने तक cpp_build पर भरोसा कर रहा हूं, मुझे बहुत डर है कि अगर इसमें बहुत अधिक समय लगता है तो यह बन जाएगा हमेशा के लिए निर्भरता। मुझे नहीं पता क्यों, इसे एक तर्कहीन विचार कहते हैं, लेकिन मुझे लगता है कि असेंबली को कॉल करने के लिए सीपीपी को कॉल करना थोड़ा दुखद है, मुझे शुद्ध जंग समाधान चाहिए।

एफडब्ल्यूआईडब्ल्यू जंग यहां विशेष नहीं है , एमएसवीसी में x86_64 के लिए इनलाइन एएसएम नहीं है। उनके पास वास्तव में अजीब कार्यान्वयन है जहां आप ऑपरेंड के रूप में चर का उपयोग कर सकते हैं लेकिन यह केवल x86 के लिए काम करता है।

@josevalaad क्या आप इनलाइन असेंबली का उपयोग करने के बारे में और बात कर सकते हैं?

हम आम तौर पर इसे केवल ओएस जैसी स्थितियों में उपयोग करते हुए देखते हैं, जो आम तौर पर अन्य कारणों से भी रात में अटक जाते हैं, और फिर भी वे मुश्किल से asm! , इसलिए asm! को स्थिर करना एक नहीं रहा है कुछ ऐसा डिजाइन और विकसित करने के लिए उच्च प्राथमिकता जो एलएलवीएम के बाहर ठीक से जीवित रह सके और सभी को खुश कर सके।

इसके अतिरिक्त, अधिकांश चीजें एक्सपोज़्ड प्लेटफ़ॉर्म इंट्रिनिक्स का उपयोग करके की जा सकती हैं। x86 और x86_64 को स्थिर कर दिया गया है और अन्य प्लेटफॉर्म प्रगति पर हैं। यह अधिकांश लोगों की अपेक्षा है कि ये लक्ष्य के 95-99% को पूरा करने जा रहे हैं। कुछ इंट्रिनिक्स का उपयोग करने के उदाहरण के रूप में आप मेरे अपने क्रेट

हमने अभी एक जेमलोक पीआर का विलय किया है जो एलएलवीएम में कोड जनरेशन बग के आसपास काम करने के लिए इनलाइन असेंबली का उपयोग करता है - https://github.com/jemalloc/jemalloc/pull/1303 । किसी ने इस मुद्दे में इनलाइन असेंबली का उपयोग किया (https://github.com/rust-lang/rust/issues/53232#issue-349262078) रस्ट (LLVM) में एक कोड जनरेशन बग के आसपास काम करने के लिए जो जेट्ससी क्रेट में हुआ था। दोनों पिछले दो हफ्तों में हुए, और दोनों ही मामलों में उपयोगकर्ताओं ने इंट्रिनिक्स के साथ प्रयास किया लेकिन संकलक उन्हें विफल कर दिया।

जब सी कंपाइलर के लिए कोड जनरेशन अस्वीकार्य होता है, तो सबसे खराब स्थिति में उपयोगकर्ता इनलाइन असेंबली का उपयोग कर सकता है और सी में काम करना जारी रख सकता है।

जब यह स्थिर जंग में होता है, तो अभी हमें लोगों को एक अलग प्रोग्रामिंग भाषा का उपयोग करने के लिए कहना होगा या अनिश्चित समय की प्रतीक्षा करनी होगी (अक्सर वर्षों के क्रम में)। यह अच्छा नहीं है।

@eddyb खैर, मैं एक छोटी मैट्रिक्स बीजगणित पुस्तकालय लिख रहा हूँ। उस पुस्तकालय के अंदर, मैं बीएलएएस को लागू कर रहा हूं, शायद कुछ लैपैक (अभी तक नहीं) जंग में दिनचर्या, क्योंकि मैं चाहता था कि पुस्तकालय शुद्ध जंग कार्यान्वयन हो। यह अभी तक कुछ भी गंभीर नहीं है, लेकिन वैसे भी, मैं चाहता था कि उपयोगकर्ता कुछ एएसएम गति और मस्ती का चयन करने में सक्षम हो, विशेष रूप से जीईएमएम ऑपरेशन के साथ, जो आवश्यक होता है (वैसे भी, सबसे अधिक उपयोग किया जाता है, और यदि आप बीएलआईएस लोगों के दृष्टिकोण का पालन करते हैं यह वही है जो आपको चाहिए), कम से कम x86/x86_64. और वह है पूरी कहानी। जाहिर है मैं रात के चैनल का भी उपयोग कर सकता हूं, मैं सुविधा के स्थिरीकरण की व्यावहारिक दिशा में थोड़ा सा धक्का देना चाहता था।

@shepmaster उपयोग-मामलों के _plenty_ हैं जिनके लिए इंट्रिनिक्स पर्याप्त नहीं हैं। हाल के सामान के मेरे सिर के शीर्ष पर जहां मैंने सोचा "क्यों ओह, जंग में स्थिर एएसएम क्यों नहीं है?", कोई XACQUIRE/XRELEASE इंट्रिनिक्स नहीं है।

स्थिर इनलाइन एएसएम महत्वपूर्ण है और नहीं, इंट्रिनिक्स पर्याप्त नहीं हैं।

मेरा मूल बिंदु किसी को तेज कोड लिखने की क्षमता रखने में मदद करने का प्रयास कर रहा था। उन्होंने यह जानने का कोई उल्लेख नहीं किया कि इंट्रिनिक्स भी उपलब्ध थे, और यही सब मैंने साझा करना चाहा। बाकी पृष्ठभूमि की जानकारी थी।

मैं एक विशिष्ट दृष्टिकोण की वकालत भी नहीं कर रहा हूं, इसलिए कृपया मेरे साथ बहस करने का प्रयास न करें - इस दौड़ में मेरी कोई हिस्सेदारी नहीं है। मैं बस वही दोहरा रहा हूं जो वर्तमान दृष्टिकोण है जैसा कि मैं इसे समझता हूं । मैं एक ऐसी परियोजना में भाग लेता हूं

हां, ऐसे मामले हैं जिनके लिए अभी असेंबली की आवश्यकता है और ऐसे मामले हैं जिन्हें हमेशा इसकी आवश्यकता होगी, मैंने मूल रूप से कहा (स्पष्टता के लिए अतिरिक्त जोर):

यह अधिकांश लोगों की अपेक्षा है कि [आंतरिक] 95-99% लक्ष्यों को पूरा करने जा रहे हैं।

यह मेरी राय है कि यदि आप स्थिर विधानसभा देखना चाहते हैं, तो किसी को (या लोगों के समूह) को रस्ट टीम से आम सहमति प्राप्त करने की आवश्यकता होगी और फिर इसे साकार करने के लिए बहुत प्रयास करना होगा। .

यह अभी तक कुछ भी गंभीर नहीं है, लेकिन वैसे भी, मैं चाहता था कि उपयोगकर्ता कुछ एएसएम गति और मस्ती का चयन करने में सक्षम हो, विशेष रूप से जीईएमएम ऑपरेशन के साथ, जो आवश्यक होता है (वैसे भी, सबसे अधिक उपयोग किया जाता है, और यदि आप बीएलआईएस लोगों के दृष्टिकोण का पालन करते हैं यह वही है जो आपको चाहिए), कम से कम x86/x86_64.

मुझे अभी भी समझ में नहीं आया कि आपको इनलाइन असेंबली के बिना किन निर्देशों तक पहुंचने की आवश्यकता है। या यह केवल अंकगणितीय निर्देशों का एक विशिष्ट क्रम है?
यदि हां, तो क्या आपने इनलाइन असेंबली के विरुद्ध एक समान रस्ट स्रोत को बेंचमार्क किया है?

आपको इनलाइन असेंबली के बिना किन निर्देशों तक पहुंचने की आवश्यकता है?

ठीक है, जब आप गणित में असेंबली के बारे में बात कर रहे हैं, तो आप मूल रूप से SIMD रजिस्टरों और निर्देशों जैसे _mm256_mul_pd, _mm256_permute2f128_pd, आदि और वेक्टराइजेशन ऑपरेशन का उपयोग करने के बारे में बात कर रहे हैं जहां यह आगे बढ़ता है। बात यह है कि आप वैश्वीकरण के लिए अलग-अलग दृष्टिकोण ले सकते हैं, और आमतौर पर यह थोड़ा परीक्षण और त्रुटि है जब तक कि आप जिस प्रोसेसर को लक्षित कर रहे हैं और आपके मन में उपयोग के लिए एक अनुकूलित प्रदर्शन प्राप्त नहीं करते हैं। इसलिए आमतौर पर पुस्तकालय स्तर पर आपको पहले एएसएम कोड इंजेक्ट करने वाले प्रोसेसर से पूछताछ करनी होती है ताकि निर्देशों और रजिस्टरों के सेट को जानने के लिए, और फिर आपके गणित एएसएम कर्नेल के एक विशिष्ट संस्करण को सशर्त संकलित किया जा सके।

यदि हां, तो क्या आपने इनलाइन असेंबली के विरुद्ध एक समान रस्ट स्रोत को बेंचमार्क किया है?

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

टेलर क्रैमर ने सुझाव दिया कि मैं यहां पोस्ट करूं। मुझे क्षमा करें क्योंकि मैंने चर्चा की वर्तमान स्थिति के साथ तेजी से आने के लिए सभी टिप्पणियों को नहीं पढ़ा है; यह केवल हमारी स्थिति के समर्थन और बयान की आवाज है।

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

हम असेंबलर में कार्यों को परिभाषित कर सकते हैं, लेकिन मुझे कोई गंभीर नंगे धातु परियोजना नहीं है जो विशेष रूप से ऐसा करती है, क्योंकि इसमें जटिलता और प्रदर्शन दोनों के मामले में कमियां हैं। Redox 'asm!' का उपयोग करता है। लिनक्स, बीएसडी, मैकओएस, विंडोज आदि के सामान्य संदिग्ध, सभी इनलाइन असेंबलर का प्रचुर उपयोग करते हैं। जिरकोन और एसईएल4 करते हैं। यहां तक ​​कि प्लान 9 ने भी कुछ साल पहले हार्वे फोर्क में इस पर ध्यान दिया था।

प्रदर्शन-महत्वपूर्ण चीजों के लिए, फ़ंक्शन कॉल ओवरहेड कॉल किए गए फ़ंक्शन की जटिलता के आधार पर हावी हो सकता है। जटिलता के संदर्भ में, अलग-अलग असेंबलर कार्यों को परिभाषित करने के लिए केवल एक निर्देश को लागू करने, एक रजिस्टर पढ़ने या लिखने, या अन्यथा मशीन स्थिति में हेरफेर करने के लिए जो आमतौर पर उपयोगकर्ता-स्पेस प्रोग्रामर से छिपा होता है, गलत होने के लिए अधिक कठिन बॉयलरप्लेट का अर्थ है। किसी भी घटना में, हमें ऐसा करने के लिए कार्गो (या बाहरी बिल्ड सिस्टम या शेल स्क्रिप्ट या कुछ के साथ पूरक) के हमारे उपयोग में अधिक रचनात्मक होना होगा। शायद build.rs यहां मदद कर सकते हैं, लेकिन इसे लिंकर में फीड करना अधिक चुनौतीपूर्ण लगता है।

अगर असेंबलर टेम्पलेट में प्रतीकात्मक स्थिरांक के मूल्यों को कम करने का कोई तरीका था तो मुझे भी यह बहुत पसंद आएगा।

हम इनलाइन और मॉड्यूल-स्तरीय असेंबलर को स्थिर करने पर कुछ आंदोलन देखना पसंद करेंगे।

पिछले प्री-आरएफसी (https://internals.rust-lang.org/t/pre-rfc-inline-assembly/6443) ने 6 महीने पहले आम सहमति हासिल की थी (कम से कम अधिकांश मूलभूत मुद्दों पर), तो अगला कदम एक आरएफसी जमा करना है जो उस पर बनता है। यदि आप चाहते हैं कि यह तेजी से हो तो मैं इसके बारे में @Florob से संपर्क करने की सलाह

इसके लायक क्या है, मुझे विंडोज़ पर टीईबी संरचना में पॉइंटर प्राप्त करने के लिए एफएसजीएस रजिस्टरों तक सीधी पहुंच की आवश्यकता है, मुझे मनमाने ढंग से स्मृति स्थान पर bt लागू करने के लिए _bittest64 -जैसे आंतरिक की भी आवश्यकता है, इनमें से कोई भी मुझे इनलाइन असेंबली या बाहरी कॉल के बिना करने का कोई तरीका नहीं मिला।

यहां उल्लिखित तीसरा बिंदु मुझे चिंतित करता है, हालांकि, एलएलवीएम वास्तव में जस्ट क्रैश को पसंद करता है यदि कुछ गलत है तो कोई त्रुटि संदेश प्रदान नहीं करता है।

@MSxDOS

मुझे मनमाने ढंग से स्मृति स्थान पर बीटी लागू करने के लिए _bittest64-जैसे आंतरिक की भी आवश्यकता है, जिनमें से कोई भी मुझे इनलाइन असेंबली या बाहरी कॉल के बिना करने का कोई तरीका नहीं मिल सकता है।

उस एक को stdsimd जोड़ना कठिन नहीं होना चाहिए, क्लैंग इनलाइन असेंबली (https://github.com/llvm-mirror/clang/blob/c1c07cca8cae5f924cedaac7b202b0f3c167111d/test/CodeGen/bittest-intrin का उपयोग करके इन्हें लागू करता है। .c#L45) लेकिन हम इसका उपयोग एसटीडी लाइब्रेरी में कर सकते हैं और आंतरिक को सुरक्षित रस्ट में उजागर कर सकते हैं।

लापता इंट्रिनिक्स के बारे में stdsimd रेपो में एक मुद्दा खोलने के लिए प्रोत्साहित महसूस करें।

@josevalaad

ठीक है, जब आप गणित में असेंबली के बारे में बात कर रहे हैं, तो आप मूल रूप से SIMD रजिस्टरों और निर्देशों जैसे _mm256_mul_pd, _mm256_permute2f128_pd, आदि और वेक्टराइजेशन ऑपरेशन का उपयोग करने के बारे में बात कर रहे हैं जहां यह आगे बढ़ता है।

आह, मुझे संदेह था कि ऐसा हो सकता है। ठीक है, अगर आप इसे आज़माना चाहते हैं, तो आप असेंबली को std::arch आंतरिक कॉल में अनुवाद कर सकते हैं और देख सकते हैं कि आपको इससे वही प्रदर्शन मिलता है या नहीं।

यदि आप नहीं करते हैं , तो कृपया समस्याएँ दर्ज करें। एलएलवीएम जादू नहीं है, लेकिन कम से कम इंट्रिनिक्स एएसएम जितना अच्छा होना चाहिए।

@dancrossnyc अगर आपको मुझसे पूछने में कोई फर्क नहीं पड़ता है, तो क्या आपकी स्थिति में विशेष रूप से कोई उपयोगकेस/प्लेटफ़ॉर्म सुविधाएं हैं जिनके लिए इनलाइन असेंबली की

@MSxDOS शायद हमें "सेगमेंट" रजिस्टर पढ़ने के लिए

हो सकता है कि हमें कुछ डेटा संग्रह करना चाहिए और लोगों को वास्तव में asm! लिए क्या चाहिए, और देखें कि उनमें से कितने किसी अन्य तरीके से समर्थित हो सकते हैं।

हो सकता है कि हमें कुछ डेटा संग्रह करना चाहिए और लोगों को वास्तव में क्या चाहिए, इसका एक ब्रेकडाउन प्राप्त करना चाहिए!

मुझे इसके लिए asm! :

• कंपाइलर द्वारा प्रदान नहीं किए गए इंट्रिनिक्स के आसपास काम करना
• कंपाइलर बग/उप-इष्टतम कोड पीढ़ी के आसपास काम करना
• ऐसे कार्य करना जिन्हें एकल इंट्रिनिक्स कॉल के अनुक्रम के माध्यम से नहीं किया जा सकता है, उदाहरण के लिए, एक पढ़ा हुआ EFLAGS-संशोधित-लिखना EFLAGS जहां LLVM को पढ़ने और लिखने के बीच eflags को संशोधित करने की अनुमति है, और जहां LLVM यह भी मानता है कि उपयोगकर्ता संशोधित नहीं करेगा यह इसके पीछे है (अर्थात, EFLAGS के साथ सुरक्षित रूप से काम करने का एकमात्र तरीका रीड-मॉडिफाई-राइट ऑपरेशंस को एकल परमाणु asm! ब्लॉक के रूप में लिखना है)।

और देखें कि उनमें से कितनों को किसी अन्य तरीके से समर्थन दिया जा सकता है।

मुझे उन उपयोग मामलों में से किसी का समर्थन करने का कोई अन्य तरीका नहीं दिख रहा है जिसमें इनलाइन असेंबली का कोई रूप शामिल नहीं है लेकिन मेरा दिमाग खुला है।

प्री-आरएफसी थ्रेड में मेरी पोस्ट से कॉपी की गई, यहां कुछ इनलाइन असेंबली (एआरएम 64) है जिसका मैं अपने वर्तमान प्रोजेक्ट में उपयोग कर रहा हूं:

// Common code for interruptible syscalls
macro_rules! asm_interruptible_syscall {
    () => {
        r#"
            # If a signal interrupts us between 0 and 1, the signal handler
            # will rewind the PC back to 0 so that the interrupt flag check is
            # atomic.
            0:
                ldrb ${0:w}, $2
                cbnz ${0:w}, 2f
            1:
               svc #0
            2:

            # Record the range of instructions which should be atomic.
            .section interrupt_restart_list, "aw"
            .quad 0b
            .quad 1b
            .previous
        "#
    };
}

// There are other versions of this function with different numbers of
// arguments, however they all share the same asm code above.
#[inline]
pub unsafe fn interruptible_syscall3(
    interrupt_flag: &AtomicBool,
    nr: usize,
    arg0: usize,
    arg1: usize,
    arg2: usize,
) -> Interruptible<usize> {
    let result;
    let interrupted: u64;
    asm!(
        asm_interruptible_syscall!()
        : "=&r" (interrupted)
          "={x0}" (result)
        : "*m" (interrupt_flag)
          "{x8}" (nr as u64)
          "{x0}" (arg0 as u64)
          "{x1}" (arg1 as u64)
          "{x2}" (arg2 as u64)
        : "x8", "memory"
        : "volatile"
    );
    if interrupted == 0 {
        Ok(result)
    } else {
        Err(Interrupted)
    }
}

@Amanieu ध्यान दें कि @japaric ARM के लिए इंट्रिनिक्स की ओर काम कर रहा है । यह देखने लायक होगा कि क्या वह प्रस्ताव आपकी आवश्यकताओं को पूरा करता है।

@शेपमास्टर

@Amanieu ध्यान दें कि @japaric एआरएम के लिए

यह ध्यान देने योग्य है कि:

• यह कार्य इनलाइन असेंबली को प्रतिस्थापित नहीं करता है, यह केवल इसका पूरक है। यह दृष्टिकोण विक्रेता एपीआई को std::arch , ये एपीआई पहले से ही कुछ लोगों के लिए अपर्याप्त हैं।

• यह दृष्टिकोण केवल तभी प्रयोग योग्य होता है जब foo(); bar(); baz(); जैसे आंतरिक कॉल का अनुक्रम निर्देशों के उस अनुक्रम से अलग-अलग कोड उत्पन्न करता है - यह जरूरी नहीं है, और जब ऐसा नहीं होता है, तो कोड जो सही दिखता है वह सबसे अच्छा गलत उत्पादन करता है परिणाम, और सबसे खराब रूप से अपरिभाषित व्यवहार है (हमारे पास x86 और x86_64 में std पहले से ही बग थे, उदाहरण के लिए, https://github.com/rust- lang-nursery/stdsimd/blob/master/coresimd/x86/cpuid.rs#L108 - अन्य आर्किटेक्चर में भी ये मुद्दे हैं)।

• कुछ इंट्रिनिक्स में तत्काल मोड तर्क होते हैं, जिन्हें आप फ़ंक्शन कॉल के माध्यम से पारित नहीं कर सकते हैं, ताकि foo(3) काम न करे। इस समस्या का हर समाधान वर्तमान में एक अजीब समाधान है, और कुछ मामलों में, रस्ट में वर्तमान में कोई समाधान संभव नहीं है, इसलिए हम इनमें से कुछ इंट्रिनिक्स प्रदान नहीं करते हैं।

तो अगर विक्रेता एपीआई जंग में लागू करने योग्य हैं, std::arch पर उपलब्ध हैं, और किसी समस्या को हल करने के लिए जोड़ा जा सकता है, तो मैं मानता हूं कि वे इनलाइन असेंबली से बेहतर हैं। लेकिन समय-समय पर या तो एपीआई उपलब्ध नहीं होते हैं, शायद लागू करने योग्य भी नहीं हैं, और / या उन्हें सही ढंग से जोड़ा नहीं जा सकता है। हालांकि हम भविष्य में "कार्यान्वयन के मुद्दों" को ठीक कर सकते हैं, अगर आप जो करना चाहते हैं वह विक्रेता एपीआई द्वारा उजागर नहीं किया जाता है, या एपीआई को जोड़ा नहीं जा सकता है, तो यह दृष्टिकोण आपकी मदद नहीं करेगा।

एलएलवीएम के इंट्रिनिक्स (विशेष रूप से सिमड) के कार्यान्वयन के बारे में आश्चर्यजनक बात यह है कि वे इंटेल के इंट्रिनिक्स के स्पष्ट मानचित्रण के निर्देशों के अनुरूप नहीं हैं - वे कंपाइलर अनुकूलन की एक विस्तृत श्रृंखला के अधीन हैं। उदाहरण के लिए मुझे एक समय याद है जहां मैंने स्मृति से लोड करने के बजाय अन्य स्थिरांक से कुछ स्थिरांक की गणना करके स्मृति दबाव को कम करने का प्रयास किया था। लेकिन एलएलवीएम बस पूरी चीज को ठीक उसी मेमोरी लोड में वापस करने के लिए आगे बढ़ा, जिसे मैं टालने की कोशिश कर रहा था। एक अलग मामले में मैं पोर्ट5 दबाव को कम करने के लिए 16-बिट फेरबदल को 8-बिट फेरबदल के साथ बदलने की जांच करना चाहता था। फिर भी अपने अनंत ज्ञान में हमेशा-सहायक एलएलवीएम अनुकूलक ने देखा कि मेरा 8-बिट शफल वास्तव में 16-बिट शफल है और इसे बदल दिया गया है।

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

तो अगर विक्रेता एपीआई जंग में लागू करने योग्य हैं, std::arch पर उपलब्ध हैं, और किसी समस्या को हल करने के लिए जोड़ा जा सकता है, तो मैं मानता हूं कि वे इनलाइन असेंबली से बेहतर हैं

मैं पहले तो बस इतना था

95-99% लक्ष्यों को पूरा करें

और फिर

हां, ऐसे मामले हैं जिनके लिए अभी असेंबली की आवश्यकता है और ऐसे मामले हैं जिन्हें हमेशा इसकी आवश्यकता होगी, मैंने मूल रूप से कहा (स्पष्टता के लिए अतिरिक्त जोर):

यह अधिकांश लोगों की अपेक्षा है कि [आंतरिक] 95-99% लक्ष्यों को पूरा करने जा रहे हैं।

यह वही बात है जो @eddyb समानांतर में कह रही है। मैं स्पष्ट नहीं हूं कि क्यों कई लोग ऐसा व्यवहार कर रहे हैं जैसे मैं वर्तमान स्थिति की वास्तविकताओं को इंगित करने

मैंने

1. एक पोस्टर की ओर इशारा किया जिसने यह जानने का कोई जिक्र नहीं किया कि आंतरिक आज स्थिर आंतरिकता की ओर मौजूद है।
2. प्रस्तावित इंट्रिनिक्स पर एक और पोस्टर की ओर इशारा किया ताकि वे प्रस्ताव पर जल्दी प्रतिक्रिया दे सकें।

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

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

मुझे संदेह है कि प्रत्येक आर्किटेक्चर में एक मुश्किल-से-मॉडल सबसेट होता है, जिसे इनलाइन asm! से कुछ उपयोग मिलता है, और शायद हमें उन सबसेट पर ध्यान केंद्रित करना चाहिए, और फिर सामान्यीकरण करने का प्रयास करना चाहिए।

cc @rust-lang/lang

@eddyb _require_ एक मजबूत शब्द है, और मुझे यह कहने के लिए मजबूर होना पड़ेगा कि नहीं, हमें इनलाइन असेंबलर का उपयोग करने की सख्ती से आवश्यकता नहीं है। जैसा कि मैंने पहले उल्लेख किया है, हम शुद्ध असेंबली भाषा में प्रक्रियाओं को परिभाषित कर सकते हैं, उन्हें अलग से इकट्ठा कर सकते हैं, और उन्हें एफएफआई के माध्यम से हमारे जंग कार्यक्रमों में जोड़ सकते हैं।

हालाँकि, जैसा कि मैंने पहले कहा था, मुझे ऐसा कोई गंभीर OS-स्तरीय प्रोजेक्ट नहीं पता है जो ऐसा करता हो। इसका मतलब होगा बहुत सारी बॉयलर प्लेट (पढ़ें: गलती करने की अधिक संभावना), एक अधिक जटिल निर्माण प्रक्रिया (अभी हम काफी भाग्यशाली हैं कि हम एक साधारण cargo आमंत्रण और एक लिंक्ड और लगभग तैयार-टू-रन कर्नेल दूसरे छोर से बाहर निकलता है; हमें असेंबलर और लिंक को एक अलग चरण में आमंत्रित करना होगा), और चीजों को इनलाइन करने की क्षमता में भारी कमी, आदि; लगभग निश्चित रूप से एक प्रदर्शन हिट होगा।

कंपाइलर इंट्रिनिक्स जैसी चीजें कई मामलों में मदद करती हैं, लेकिन लक्ष्य आईएसए के पर्यवेक्षी निर्देश सेट जैसी चीजों के लिए, विशेष रूप से अधिक गूढ़ हार्डवेयर सुविधाएं (उदाहरण के लिए हाइपरवाइजर और एन्क्लेव फीचर्स), अक्सर इंट्रिनिक्स नहीं होते हैं और हम अंदर हैं एक no_std वातावरण। अक्सर जो आंतरिक तत्व होते हैं वे पर्याप्त नहीं होते हैं; उदाहरण के लिए, x86-इंटरप्ट कॉलिंग कन्वेंशन अच्छा लगता है, लेकिन आपको ट्रैप फ्रेम में सामान्य प्रयोजन रजिस्टरों के लिए परस्पर पहुंच प्रदान नहीं करता है: मान लीजिए कि मैं अनुकरण करने के इरादे से एक अपरिभाषित निर्देश अपवाद लेता हूं, और मान लीजिए कि नकली निर्देश एक मूल्य देता है %rax या कुछ में; कॉलिंग कन्वेंशन मुझे कॉल-साइट पर वापस भेजने का एक अच्छा तरीका नहीं देता है, इसलिए हमें अपना रोल करना पड़ा। इसका मतलब असेंबलर में अपना खुद का अपवाद हैंडलिंग कोड लिखना था।

तो ईमानदार होने के लिए नहीं, हमारे पास _require_ इनलाइन असेंबलर नहीं है, लेकिन यह पर्याप्त रूप से उपयोगी है कि इसे न रखना लगभग एक गैर-स्टार्टर होगा।

@dancrossnyc मैं अलग संयोजन, है कि परहेज, विधानसभा की तरह आप अपने प्रोजेक्ट, चाहे कितना आप इसे में लिंक में सभी पर जरूरत के बारे में विशेष रूप से उत्सुक हूँ।

आपके मामले में यह एक पर्यवेक्षक/हाइपरवाइजर/एन्क्लेव विशेषाधिकार प्राप्त आईएसए सबसेट प्रतीत होता है, क्या यह सही है?

अक्सर इंट्रिनिक्स नहीं होते हैं

क्या यह अनिवार्य रूप से है, यानी क्या निर्देशों में ऐसी आवश्यकताएं हैं जो अनुचित रूप से कठिन हैं या यहां तक ​​​​कि असंभव भी हैं जब आंतरिक कॉल के रूप में संकलित किया जाता है, उदाहरण के लिए एलएलवीएम?
या यह सिर्फ इसलिए है क्योंकि अधिकांश डेवलपर्स के लिए उपयोगी होने के लिए उन्हें बहुत विशेष-आवरण माना जाता है?

और हम एक no_std वातावरण में हैं

रिकॉर्ड के लिए, विक्रेता इंट्रिनिक्स std::arch और core::arch (पूर्व एक पुन: निर्यात है)।

x86-इंटरप्ट कॉलिंग कन्वेंशन अच्छा लगता है, लेकिन आपको ट्रैप फ्रेम में सामान्य प्रयोजन रजिस्टरों के लिए परस्पर पहुंच प्रदान नहीं करता है

cc @rkruppe क्या इसे LLVM में लागू किया जा सकता है?

@eddyb सही; हमें आईएसए के पर्यवेक्षक सबसेट की आवश्यकता है। मुझे डर है कि मैं इस समय हमारे विशिष्ट उपयोग के मामले के बारे में अधिक कुछ नहीं कह सकता।

क्या यह अनिवार्य रूप से है, यानी क्या निर्देशों में ऐसी आवश्यकताएं हैं जो अनुचित रूप से कठिन हैं या यहां तक ​​​​कि असंभव भी हैं जब आंतरिक कॉल के रूप में संकलित किया जाता है, उदाहरण के लिए एलएलवीएम?
या यह सिर्फ इसलिए है क्योंकि अधिकांश डेवलपर्स के लिए उपयोगी होने के लिए उन्हें बहुत विशेष-आवरण माना जाता है?

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

रिकॉर्ड के लिए, विक्रेता इंट्रिनिक्स दोनों std::arch और core::arch (पूर्व एक reexport है) में हैं।

यह जानना वाकई बहुत अच्छा है। धन्यवाद!

क्या यह एक कंपाइलर के लिए उचित होगा (उदाहरण के लिए) कुछ को एक आंतरिक के रूप में उजागर करना जो विशेषाधिकार प्राप्त निर्देश सबसेट का हिस्सा है और एक विशिष्ट प्रोसेसर संस्करण पर वातानुकूलित है? मैं ईमानदारी से नहीं जानता।

हम पहले से ही करते हैं। उदाहरण के लिए, xsave x86 निर्देश core::arch में लागू और प्रदर्शित किए जाते हैं, सभी प्रोसेसर पर उपलब्ध नहीं होते हैं, और उनमें से अधिकांश को विशेषाधिकार प्राप्त मोड की आवश्यकता होती है।

@gnzlbg xsave विशेषाधिकार प्राप्त नहीं है; क्या आपका मतलब xsaves ?

मैंने https://rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/arch/x86_64/index.html और अपने त्वरित स्वीप में देखे गए एकमात्र विशेषाधिकार प्राप्त निर्देशों के माध्यम से एक नज़र डाली (मैंने ऐसा नहीं किया संपूर्ण खोज) xsaves , xsaves64 , xrstors , और xrstors64 । मुझे संदेह है कि वे आंतरिक हैं क्योंकि वे सामान्य XSAVE* परिवार में आते हैं और वास्तविक मोड में अपवाद उत्पन्न नहीं करते हैं, और कुछ लोग वास्तविक-मोड कोड संकलित करने के लिए क्लैंग/एलएलवीएम का उपयोग करना चाहते हैं।

@dancrossnyc हाँ उनमें से कुछ वे हैं जिनका मेरा मतलब था (हम xsave , xsaves , xsaveopt , ... xsave मॉड्यूल में लागू करते हैं: https: //github.com/rust-lang-nursery/stdsimd/blob/master/coresimd/x86/xsave.rs)।

ये core , इसलिए आप इनका उपयोग x86 के लिए OS कर्नेल लिखने के लिए कर सकते हैं। उपयोगकर्ता-स्थान में वे बेकार हैं AFAICT (वे हमेशा एक अपवाद उठाएंगे), लेकिन हमारे पास इसके बारे में core में अंतर करने का कोई तरीका नहीं है। हम उन्हें केवल core में उजागर कर सकते थे और std नहीं, लेकिन चूंकि वे पहले से ही स्थिर हैं, इसलिए वह जहाज रवाना हो गया है। कौन जानता है, शायद कुछ ओएस किसी दिन रिंग 0 में सबकुछ चलाता है, और आप उन्हें वहां इस्तेमाल कर सकते हैं ...

@gnzlbg मैं नहीं जानता कि क्यों xsaveopt या xsave उपयोक्ता स्थान में एक अपवाद उत्पन्न करेगा: xsaves परिवार में एकमात्र ऐसा परिवार है जिसे अपवाद उत्पन्न करने के लिए परिभाषित किया गया है (#GP यदि CPL>0), और उसके बाद केवल संरक्षित मोड में (SDM vol.1 ch. 13; vol.2C ch. 5 XSAVES)। xsave और xsaveopt लागू करने के लिए उपयोगी हैं उदाहरण के लिए पूर्व-खाली उपयोगकर्ता-स्थान धागे, इसलिए आंतरिक के रूप में उनकी उपस्थिति वास्तव में समझ में आता है। मुझे संदेह है कि xsaves लिए आंतरिक या तो इसलिए था क्योंकि किसी ने विशेषाधिकार मुद्दे को महसूस किए बिना xsave परिवार से सब कुछ जोड़ा (यानी, यह मानते हुए कि यह उपयोगकर्ता स्थान से अपरिवर्तनीय था), या कोई इसे कॉल करना चाहता था वास्तविक मोड से। वह बाद वाला दूर की कौड़ी लग सकता है लेकिन मुझे पता है कि लोग क्लैंग और एलएलवीएम के साथ रियल-मोड फर्मवेयर बना रहे हैं।

मुझे गलत मत समझो; core में LLVM इंट्रिनिक्स की उपस्थिति बढ़िया है; अगर मुझे rdtscp के परिणामों को फिर से एक उपयोगी प्रारूप में प्राप्त करने के लिए निर्देशों के उस मूर्खतापूर्ण अनुक्रम को लिखना नहीं है, तो मुझे खुशी होगी। लेकिन जब आप कर्नेल या अन्य नंगे-धातु पर्यवेक्षी प्रकार की चीज़ लिख रहे हों तो इंट्रिनिक्स का वर्तमान सेट इनलाइन असेंबलर का विकल्प नहीं है।

@dancrossnyc जब मैंने xsave उल्लेख किया तो मैं कुछ ऐसे इंट्रिनिक्स की बात कर रहा था जो CPUID बिट्स XSAVE, XSAVEOPT, XSAVEC, आदि के पीछे उपलब्ध हैं। इनमें से कुछ इंट्रिनिक्स के लिए विशेषाधिकार प्राप्त मोड की आवश्यकता होती है।

क्या यह एक कंपाइलर के लिए उचित होगा (उदाहरण के लिए) कुछ को एक आंतरिक के रूप में उजागर करना जो विशेषाधिकार प्राप्त निर्देश सबसेट का हिस्सा है और एक विशिष्ट प्रोसेसर संस्करण पर वातानुकूलित है?

हम पहले से ही करते हैं और वे स्थिर जंग में उपलब्ध हैं।

मुझे संदेह है कि xsaves के लिए आंतरिक या तो इसलिए था क्योंकि किसी ने विशेषाधिकार के मुद्दे को महसूस किए बिना xsave परिवार से सब कुछ जोड़ा था

मैंने इन इंट्रिनिक्स को जोड़ा। हमने विशेषाधिकार के मुद्दों को महसूस किया और उन्हें वैसे भी जोड़ने का फैसला किया क्योंकि यह एक ओएस कर्नेल होने के लिए core आधार पर एक प्रोग्राम के लिए बिल्कुल ठीक है जो इनका उपयोग करना चाहता है, और वे उपयोगकर्ता स्थान में हानिरहित हैं (जैसे, यदि आप उनका उपयोग करने का प्रयास करें, आपकी प्रक्रिया समाप्त हो जाती है)।

लेकिन जब आप कर्नेल या अन्य नंगे-धातु पर्यवेक्षी प्रकार की चीज़ लिख रहे हों तो इंट्रिनिक्स का वर्तमान सेट इनलाइन असेंबलर का विकल्प नहीं है।

सहमत, इसलिए यह मुद्दा अभी भी खुला है;)

@gnzlbg क्षमा करें, मेरा मतलब xsave et al पर खरगोश- होली द्वारा इसे पटरी से उतारना नहीं है।

हालांकि, जैसा कि मैं बता सकता हूं, केवल इंट्रिनिक्स जिन्हें विशेषाधिकार प्राप्त निष्पादन की आवश्यकता होती है वे xsaves से संबंधित होते हैं और फिर भी यह हमेशा विशेषाधिकार प्राप्त नहीं xsaves और xrstors विशेषाधिकार प्राप्त निर्देश सेट का एक बहुत, बहुत छोटा हिस्सा हैं और दो निर्देशों के लिए इंट्रिनिक्स जोड़ना आम तौर पर ऐसा करने से गुणात्मक रूप से अलग है और मुझे लगता है कि सवाल यह है कि क्या यह उपयुक्त है _in सामान्य_। उदाहरण के लिए, VMX एक्सटेंशन के VMWRITE निर्देश पर विचार करें; मुझे लगता है कि एक आंतरिक कुछ ऐसा करेगा जैसे निर्देश निष्पादित करें और फिर "वापसी" rflags । यह एक आंतरिक के रूप में होने वाली एक अजीब तरह की विशिष्ट चीज है।

मुझे लगता है कि अन्यथा हम यहाँ सहमत हैं।

FWIW प्रति std::arch RFC हम वर्तमान में केवल std::arch इंट्रिनिक्स जोड़ सकते हैं जिसे विक्रेता अपने एपीआई में उजागर करते हैं। xsave के मामले में, इंटेल उन्हें अपने सी एपीआई पर उजागर करता है , इसलिए यह ठीक है कि वहां है। यदि आपको किसी ऐसे विक्रेता इंट्रिनिक्स की आवश्यकता है जो वर्तमान में उजागर नहीं हुआ है, तो एक मुद्दा खोलें, चाहे इसके लिए विशेषाधिकार प्राप्त मोड की आवश्यकता हो या नहीं, यह अप्रासंगिक है।

यदि विक्रेता इसके लिए एक आंतरिक का खुलासा नहीं करता है, तो std::arch इसके लिए जगह नहीं हो सकती है, लेकिन इसके लिए कई विकल्प हैं (इनलाइन असेंबली, ग्लोबल एएसएम, कॉलिंग सी, ...)।

क्षमा करें, मैं समझ गया कि आपने xsave लिए इंट्रिनिक्स लिखा है जिसका अर्थ इंटेल इंट्रिनिक्स है; मेरी पिछली टिप्पणियां अभी भी इस बात पर लागू होती हैं कि मुझे क्यों लगता है कि xsaves एक आंतरिक है (या तो इंटेल में एक कंपाइलर लेखक द्वारा दुर्घटना या क्योंकि कोई इसे वास्तविक मोड के लिए चाहता था; मुझे लगता है कि पूर्व को वास्तव में जल्दी से देखा जाएगा लेकिन फर्मवेयर अजीब चीजें करता है, इसलिए बाद वाला मुझे बिल्कुल आश्चर्यचकित नहीं करेगा)।

वैसे भी, हाँ, मुझे लगता है कि हम मौलिक रूप से सहमत हैं: इंट्रिनिक्स हर चीज के लिए जगह नहीं है, और इसलिए हम asm!() को स्थिर में ले जाना चाहते हैं। मैं यह सुनकर वास्तव में उत्साहित हूं कि इस क्षेत्र में प्रगति हो रही है, जैसा कि आपने कल कहा था, और अगर हम @Florob को धीरे से इसे स्टैक के शीर्ष के करीब बबल करने के लिए कुहनी

asm! लिए कुछ अतिरिक्त विवरण और उपयोग के मामले:

जब आप कोई ऑपरेटिंग सिस्टम, फ़र्मवेयर, कुछ खास प्रकार की लाइब्रेरी या कुछ अन्य प्रकार के सिस्टम कोड लिख रहे होते हैं, तो आपको प्लेटफ़ॉर्म-स्तरीय असेंबली तक पूर्ण पहुँच की आवश्यकता होती है। यहां तक ​​​​कि अगर हमारे पास इंट्रिनिक्स था जो हर आर्किटेक्चर में हर एक निर्देश को उजागर करता है जो जंग का समर्थन करता है (जिसे हम कहीं भी पास नहीं आते हैं), तो यह अभी भी कुछ स्टंट के लिए पर्याप्त नहीं होगा जो लोग नियमित रूप से इनलाइन असेंबली के साथ खींचते हैं।

यहां उन चीजों का एक छोटा सा अंश दिया गया है जो आप इनलाइन असेंबली के साथ कर सकते हैं जो आप आसानी से अन्य तरीकों से नहीं कर सकते हैं। इनमें से हर एक एक वास्तविक दुनिया का उदाहरण है जिसे मैंने देखा है (या कुछ मामलों में लिखा है), काल्पनिक नहीं।

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

+1ई6

@eddyb

ठीक है, मैं आंतरिक दृष्टिकोण का प्रयास करूंगा और देख सकता हूं कि यह कहां लेता है। आप शायद सही हैं और मेरे मामले के लिए यह सबसे अच्छा तरीका है। शुक्रिया!

@joshtriplett ने इसे

loop {
   :thumbs_up:
}

मैं कुछ अन्य उपयोग के मामलों को जोड़ूंगा:

• अजीब वास्तुशिल्प मोड में कोड लिखना, जैसे BIOS/EFI कॉल और 16-बिट रीयल-मोड।
• अजीब/असामान्य एड्रेसिंग मोड के साथ कोड लिखना (जो अक्सर 16-बिट रीयल-मोड, बूटलोडर्स इत्यादि में आता है)

@ मार्क-आईएम बिल्कुल! और एक बिंदु को सामान्य बनाना जिसमें हमारी दोनों सूचियों में उप-मामले हैं: कॉलिंग सम्मेलनों के बीच अनुवाद करना।

मैं इस मुद्दे के पक्ष में #53118 बंद कर रहा हूं और पीआर को यहां रिकॉर्ड के लिए कॉपी कर रहा हूं। ध्यान दें कि यह अगस्त से है, लेकिन एक संक्षिप्त रूप से संकेत मिलता है कि स्थिति नहीं बदली है:

इनलाइन एसेम्बली के अनुभाग में आमूल-चूल परिवर्तन की आवश्यकता है; अपनी वर्तमान स्थिति में इसका तात्पर्य है कि व्यवहार और वाक्य रचना rustc और सामान्य रूप से रस्ट भाषा से बंधी है। एलएलवीएम टूलचेन के साथ x86/x86_64 असेंबली के लिए बहुत अधिक संपूर्ण दस्तावेज विशिष्ट है। स्पष्ट होने के लिए, मैं स्वयं असेंबली कोड का उल्लेख नहीं कर रहा हूं, जो स्पष्ट रूप से प्लेटफ़ॉर्म-विशिष्ट है, बल्कि सामान्य वास्तुकला और इनलाइन असेंबली का उपयोग पूरी तरह से है।

जब एआरएम लक्ष्य की बात आती है तो मुझे इनलाइन असेंबली के व्यवहार के लिए एक आधिकारिक स्रोत नहीं मिला, लेकिन मेरे प्रयोग और एआरएम जीसीसी इनलाइन असेंबली दस्तावेज के संदर्भ में, निम्नलिखित बिंदु पूरी तरह से बंद प्रतीत होते हैं:

• एएसएम सिंटैक्स, एआरएम/एमआईपीएस (और अधिकांश अन्य सीआईएससी?) के रूप में पहले गंतव्य रजिस्टर के साथ इंटेल-एस्क सिंटैक्स का उपयोग करते हैं। मैं दस्तावेज़ीकरण को समझता/समझता हूं कि इनलाइन एएसएम ने एटी एंड टी सिंटैक्स लिया था जिसे वास्तविक प्लेटफॉर्म/कंपाइलर-विशिष्ट वाक्यविन्यास में स्थानांतरित किया गया था, और मुझे केवल एआरएम रजिस्टरों के साथ x86 रजिस्टरों के नामों को प्रतिस्थापित करना चाहिए।
• संबंधित रूप से, intel विकल्प अमान्य है, क्योंकि यह संकलन करते समय "अज्ञात निर्देश" त्रुटियों का कारण बनता है।
• एआरएम जीसीसी इनलाइन असेंबली दस्तावेज से अनुकूलन ( thumbv7em-none-eabi के खिलाफ arm-none-eabi-* टूलचेन के साथ निर्माण के लिए, ऐसा प्रतीत होता है कि इनलाइन असेंबली के प्रारूप के बारे में कुछ बुनियादी धारणाएं भी प्लेटफॉर्म-विशिष्ट हैं। विशेष रूप से, यह ऐसा लगता है कि एआरएम के लिए आउटपुट रजिस्टर (दूसरा मैक्रो तर्क) एक रजिस्टर संदर्भ के रूप में गिना जाता है, यानी $0 पहले आउटपुट रजिस्टर को संदर्भित करता है न कि पहला इनपुट रजिस्टर, जैसा कि x86 llvm निर्देशों के मामले में है।
• साथ ही, अन्य कंपाइलर-विशिष्ट विशेषताएं _not_ मौजूद हैं; मैं रजिस्टरों के लिए नामित संदर्भों का उपयोग नहीं कर सकता, केवल अनुक्रमणिका (उदाहरण के लिए asm("mov %[result],%[value],ror #1":[result] "=r" (y):[value] "r" (x)); अमान्य है)।
• (यहां तक ​​कि x86/x86_64 लक्ष्यों के लिए, इनलाइन असेंबली उदाहरण में $0 और $2 का उपयोग बहुत भ्रमित करने वाला है, क्योंकि यह स्पष्ट नहीं करता कि उन नंबरों को क्यों चुना गया था।)

मुझे लगता है कि जिस चीज ने मुझे सबसे ज्यादा प्रभावित किया वह है समापन कथन:

एएसएम का वर्तमान कार्यान्वयन! मैक्रो एलएलवीएम के इनलाइन असेंबलर अभिव्यक्तियों के लिए एक सीधा बाध्यकारी है, इसलिए क्लॉबर्स, बाधाओं आदि के बारे में अधिक जानकारी के लिए उनके दस्तावेज़ीकरण को भी देखना सुनिश्चित करें।

जो सर्वमान्य सत्य प्रतीत नहीं होता।

मैं दस्तावेज़ीकरण को समझता/समझता हूं कि इनलाइन एएसएम ने एटी एंड टी सिंटैक्स लिया था जिसे वास्तविक प्लेटफॉर्म/कंपाइलर-विशिष्ट वाक्यविन्यास में स्थानांतरित किया गया था, और मुझे केवल एआरएम रजिस्टरों के साथ x86 रजिस्टरों के नामों को प्रतिस्थापित करना चाहिए।

इंटेल बनाम एटी एंड टी सिंटैक्स की धारणा केवल x86 पर मौजूद है (हालांकि ऐसे अन्य मामले भी हो सकते हैं जिनके बारे में मुझे जानकारी नहीं है)। यह इस मायने में अद्वितीय है कि वे दो अलग-अलग भाषाएं हैं जो समान बाइनरी कोड का प्रतिनिधित्व करने के लिए समान निमोनिक्स का सेट साझा करती हैं। GNU पारिस्थितिकी तंत्र ने x86 दुनिया के लिए एटी एंड टी सिंटैक्स को प्रमुख डिफ़ॉल्ट के रूप में स्थापित किया है, यही कारण है कि इनलाइन asm डिफ़ॉल्ट है। आप गलत हैं कि यह एलएलवीएम के इनलाइन असेंबलर अभिव्यक्तियों के लिए बहुत सीधा बाध्यकारी है जो बदले में टेक्स्ट असेंबली प्रोग्राम में ज्यादातर सादा टेक्स्ट (प्रतिस्थापन प्रसंस्करण के बाद) डंप करता है। इनमें से कोई भी आज के asm!() लिए या उसके बारे में अद्वितीय (या प्रासंगिक भी) नहीं है क्योंकि यह पूरी तरह से प्लेटफ़ॉर्म-विशिष्ट है और x86 दुनिया से परे पूरी तरह से अर्थहीन है।

संबंधित रूप से, intel विकल्प अमान्य है, क्योंकि यह संकलन करते समय "अज्ञात निर्देश" त्रुटियों का कारण बनता है।

यह ऊपर वर्णित "गूंगा"/साधारण सादा पाठ प्रविष्टि का प्रत्यक्ष परिणाम है। चूंकि त्रुटि संदेश इंगित करता है कि .intel_syntax निर्देश असमर्थित है। जीसीसी के साथ इंटेल-स्टाइल इनलाइन-एएसएम का उपयोग करने के लिए यह एक पुराना और प्रसिद्ध कामकाज है (जो एट स्टाइल उत्सर्जित करता है): कोई इनलाइन एएसएम ब्लॉक की शुरुआत में बस .intel_syntax लिख देगा, फिर कुछ इंटेल- स्टाइल एएसएम और अंत में .att_syntax के साथ असेंबलर को वापस एटीटी मोड में सेट करने के लिए समाप्त करें ताकि यह एक बार फिर से (निम्नलिखित) कंपाइलर-जेनरेट कोड को सही ढंग से संसाधित कर सके। यह एक गंदा हैक है और मुझे याद है कि कम से कम एलएलवीएम कार्यान्वयन में लंबे समय से कुछ अजीब विचित्रताएं थीं, इसलिए ऐसा लगता है कि आप इस त्रुटि को देख रहे हैं क्योंकि इसे अंततः हटा दिया गया था। अफसोस की बात है कि यहां कार्रवाई का एकमात्र सही तरीका "intel" विकल्प को rustc से हटाना है।

ऐसा प्रतीत होता है कि इनलाइन असेंबली के प्रारूप के बारे में कुछ बुनियादी धारणाएं भी प्लेटफॉर्म-विशिष्ट हैं

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

मैं रजिस्टरों के लिए नामित संदर्भों का उपयोग नहीं कर सकता, केवल अनुक्रमणिका

अफसोस की बात है कि एलएलवीएम के इनलाइन एएसएम कार्यान्वयन के बीच काफी बड़ा बेमेल है जो कि रस्टक उजागर करता है और जीसीसी (जो क्लैंग अनुकरण करता है) के कार्यान्वयन के बीच है। asm!() साथ आगे बढ़ने के निर्णय के बिना इसमें सुधार करने के लिए बहुत कम प्रेरणा है - इसके अलावा, मैंने बहुत समय पहले प्रमुख विकल्पों को रेखांकित किया asm!() के साथ फंसने वाले हैं। सभ्य कामकाज हैं:

• इष्टतम कोड उत्पन्न करने के लिए अनुकूलक पर भरोसा करें (थोड़ी सी कुहनी से आप आमतौर पर वही प्राप्त कर सकते हैं जो आप कभी भी स्वयं कच्ची असेंबली लिखे बिना चाहते हैं)
• इंट्रिनिक्स का उपयोग करें, एक और काफी सुंदर समाधान जो लगभग हर तरह से इनलाइन एएसएम से बेहतर है (जब तक आपको निर्देश चयन और शेड्यूलिंग पर सटीक नियंत्रण की आवश्यकता नहीं है)
• सी ऑब्जेक्ट को इनलाइन एएसएम से जोड़ने के लिए cc क्रेट को build.rs से आमंत्रित करें
  
  
  
  • मूल रूप से केवल build.rs से अपनी पसंद के किसी भी असेंबलर को आमंत्रित करें, एक सी कंपाइलर का उपयोग करना ओवरकिल की तरह लग सकता है लेकिन आपको build.rs सिस्टम के साथ एकीकृत करने की परेशानी से बचाता है
  
  

ये समाधान बहुत विशिष्ट किनारे के मामलों के एक छोटे से सेट को छोड़कर सभी पर लागू होते हैं। यदि आप उनमें से एक को मारते हैं (सौभाग्य से मैंने अभी तक नहीं किया है) तो आप भाग्य से बाहर हैं।

मैं मानता हूं कि प्रलेखन काफी कमजोर है लेकिन इनलाइन एएसएम से परिचित किसी भी व्यक्ति के लिए यह काफी अच्छा है। यदि आप नहीं हैं, तो शायद आपको इसका उपयोग नहीं करना चाहिए । मुझे गलत मत समझो - आपको निश्चित रूप से प्रयोग करने और सीखने के लिए स्वतंत्र महसूस करना चाहिए, लेकिन asm!() अस्थिर और उपेक्षित है और क्योंकि वास्तव में अच्छे कामकाज हैं, यदि संभव हो तो मैं किसी भी गंभीर परियोजना में इसका उपयोग करने के खिलाफ दृढ़ता से सलाह दूंगा .

C ऑब्जेक्ट को इनलाइन asm . से जोड़ने के लिए build.rs से cc क्रेट को इनवाइट करें

आप सादे असेंबली फ़ाइलों को बनाने के लिए cc से build.rs टोकरा भी लगा सकते हैं, जो अधिकतम मात्रा में नियंत्रण देता है। मैं दृढ़ता से ऐसा करने की अनुशंसा करता हूं यदि इसके ऊपर के दो "समाधान" आपके उपयोग-मामले के लिए काम नहीं करते हैं।

@ मुख्य-- लिखा है:

ये समाधान बहुत विशिष्ट किनारे के मामलों के एक छोटे से सेट को छोड़कर सभी पर लागू होते हैं। यदि आप उनमें से एक को मारते हैं (सौभाग्य से मैंने अभी तक नहीं किया है) तो आप भाग्य से बाहर हैं।

मेरा मतलब है, पूरी तरह से भाग्य से बाहर नहीं। आपको बस रस्ट के inline asm । मेरे पास एक किनारे का मामला है कि आपके सूचीबद्ध कामकाज में से कोई भी यहां शामिल नहीं

(मेरे पास एक और उपयोग का मामला है: मैं किसी दिन सी के बजाय रस्ट का उपयोग करके सिस्टम प्रोग्रामिंग कंप्यूटर आर्किटेक्चर और सामान को पढ़ाना चाहूंगा। इनलाइन असेंबली नहीं होने से यह और अधिक अजीब हो जाएगा।)

काश, हम रस्ट में इनलाइन असेंबली को प्राथमिकता देते और इसे बाद में जल्द से जल्द स्थिर करते। शायद यह रस्ट 2019 का लक्ष्य होना चाहिए। मैं आपकी अच्छी टिप्पणी में पहले सूचीबद्ध किसी भी समाधान के साथ ठीक हूं: मैं उनमें से किसी की समस्याओं के साथ रह सकता हूं। असेंबली कोड को इनलाइन करने में सक्षम होना मेरे लिए हर जगह C के बजाय रस्ट लिखने की एक शर्त है: मुझे वास्तव में इसे स्थिर होने की आवश्यकता है।

काश, हम रस्ट में इनलाइन असेंबली को प्राथमिकता देते और इसे बाद में जल्द से जल्द स्थिर करते। शायद यह रस्ट 2019 का लक्ष्य होना चाहिए।

कृपया रस्ट 2019 ब्लॉग पोस्ट लिखें और इस चिंता को व्यक्त करें। मुझे लगता है कि अगर हम में से बहुत से लोग ऐसा करते हैं, तो हम रोडमैप को प्रभावित कर सकते हैं।

ऊपर मेरी टिप्पणी को स्पष्ट करने के लिए - समस्या यह है कि दस्तावेज़ीकरण यह नहीं बताता है कि asm!(..) मैक्रो की सामग्री को "गहराई से" कैसे पार्स/बातचीत किया जाता है। मैं x86 और MIPS/ARM असेंबली से परिचित हूं लेकिन माना जाता है कि llvm का अपना असेंबली भाषा प्रारूप था। मैंने पहले x86 के लिए इनलाइन असेंबली का उपयोग किया है, लेकिन यह स्पष्ट नहीं था कि सी और एएसएम को ब्रिगेड करने के लिए एएसएम का कमीनाकरण किस हद तक चला गया। रस्ट इनलाइन असेंबली सेक्शन में शब्दों के आधार पर मेरा अनुमान (अब अमान्य) यह था कि LLVM का अपना ASM प्रारूप था जिसे या तो at&t या इंटेल मोड में x86 असेंबली की नकल करने के लिए बनाया गया था, और आवश्यक रूप से दिखाए गए x86 उदाहरणों की तरह दिखता था।

(विस्तारित मैक्रो आउटपुट का अध्ययन करने से मुझे क्या मदद मिली, जिसने स्पष्ट किया कि क्या चल रहा था)

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

सी ऑब्जेक्ट को इनलाइन एएसएम से जोड़ने के लिए cc क्रेट को build.rs से आमंत्रित करें

क्रॉस-लैंग्वेज एलटीओ पर हाल की प्रगति मुझे आश्चर्यचकित करती है कि क्या इस एवेन्यू के कुछ डाउनसाइड्स को कम किया जा सकता है, इस "बाहरी असेंबली ब्लॉब" को प्रभावी ढंग से रेखांकित किया जा सकता है। ( शायद नहीं )

सी ऑब्जेक्ट को इनलाइन एएसएम से जोड़ने के लिए cc क्रेट को build.rs से आमंत्रित करें

क्रॉस-लैंग्वेज एलटीओ पर हाल की प्रगति मुझे आश्चर्यचकित करती है कि क्या इस एवेन्यू के कुछ डाउनसाइड्स को कम किया जा सकता है, इस "बाहरी असेंबली ब्लॉब" को प्रभावी ढंग से रेखांकित किया जा सकता है।

यहां तक ​​​​कि अगर यह काम करता है, तो मैं सी में अपनी इनलाइन असेंबली नहीं लिखना चाहता हूं। मैं इसे जंग में लिखना चाहता हूं। :-)

मैं सी में अपनी इनलाइन असेंबली नहीं लिखना चाहता हूं।

आप .s और .S फ़ाइलों को सीधे संकलित और लिंक कर सकते हैं (उदाहरण के लिए यह टोकरा देखें ), जो मेरी पुस्तक में सी से काफी दूर हैं। :)

अगर इस एवेन्यू के कुछ डाउनसाइड्स को कम किया जा सकता है

मेरा मानना ​​​​है कि यह वर्तमान में संभव नहीं है क्योंकि क्रॉस-लैंग्वेज एलटीओ एलएलवीएम आईआर होने पर निर्भर करता है और असेंबली इसे उत्पन्न नहीं करेगी।

मेरा मानना ​​​​है कि यह वर्तमान में संभव नहीं है क्योंकि क्रॉस-लैंग्वेज एलटीओ एलएलवीएम आईआर होने पर निर्भर करता है और असेंबली इसे उत्पन्न नहीं करेगी।

आप LLVM IR मॉड्यूल में असेंबली को मॉड्यूल लेवल असेंबली में स्टफ कर सकते हैं।

क्या किसी को पता है कि नवीनतम प्रस्ताव/वर्तमान स्थिति क्या है? चूंकि वर्ष का विषय "परिपक्वता और जो हमने शुरू किया है उसे पूरा करना" है, यह अंततः asm को समाप्त करने का एक शानदार अवसर प्रतीत होता है।

पिछले फरवरी में एक नए (स्थिर होने के लिए) सिंटैक्स की अस्पष्ट योजनाओं पर चर्चा की गई थी: https://paper.dropbox.com/doc/FFI-5NmXV30TGiSsr9dIxpqpq

उन नोटों के अनुसार @joshtriplett और @Amanieu ने RFC लिखने के लिए साइन अप किया।

नए सिंटैक्स की स्थिति क्या है?

इसे RFC'ed और रात को लागू करने की आवश्यकता है

पिंग @joshtriplett @Amanieu मुझे बताएं कि क्या मैं यहां चीजों को स्थानांतरित करने में मदद कर सकता हूं! मैं शीघ्र ही संपर्क में रहूंगा।

@cramertj AFAICT कोई भी इसे आगे बढ़ा सकता है, यह अनब्लॉक है और किसी के कदम उठाने और काम में लगाने की प्रतीक्षा कर रहा है। समग्र डिज़ाइन को स्केच करने वाला एक प्री-आरएफसी है, और अगले चरण इसे लागू करने और यह देखने के लिए हो सकते हैं कि क्या यह वास्तव में काम करता है, या तो एक प्रो मैक्रो के रूप में, एक कांटा में, या एक अलग अस्थिर विशेषता के रूप में।

कोई शायद उस पूर्व-आरएफसी को उचित आरएफसी में बदलने और इसे जमा करने का प्रयास कर सकता है, लेकिन मुझे संदेह है कि कार्यान्वयन के बिना ऐसा आरएफसी आश्वस्त हो सकता है।

संपादित करें: स्पष्ट होने के लिए, मैं विशेष रूप से पूर्व-आरएफसी के कुछ हिस्सों को इस तरह समझाता हूं:

अतिरिक्त रूप से रजिस्टर कक्षाओं के लिए मैपिंग को उपयुक्त के रूप में जोड़ा जाता है (cf. llvm-constraint 6)

जहां लैंग-रेफ में दर्जनों आर्क-विशिष्ट रजिस्टर वर्ग हैं। एक आरएफसी इन सभी को बाहर नहीं निकाल सकता है, और यह सुनिश्चित कर रहा है कि वे सभी काम करते हैं जैसे उन्हें माना जाता है, या सार्थक हैं, या एलएलवीएम में पर्याप्त "स्थिर" हैं, जो यहां से उजागर हो सकते हैं, आदि। एक कार्यान्वयन से लाभ होगा जो कोई भी कर सकता है बस इन में प्रयास करें।

क्या RISC-V इनलाइन असेंबली यहां #![feature(asm)] साथ समर्थित है?

मेरी जानकारी के अनुसार, समर्थित प्लेटफॉर्म पर सभी असेंबली समर्थित हैं; यह एलवीएम कंपाइलर के एएसएम समर्थन के लिए काफी कच्ची पहुंच है।

हां, आरआईएससी-वी समर्थित है। आर्किटेक्चर-विशिष्ट इनपुट/आउटपुट/ क्लोबर बाधा वर्ग

हालांकि, एक चेतावनी है - यदि आपको इनपुट/आउटपुट/क्लॉबर बाधाओं में अलग-अलग रजिस्टरों में बाधा डालने की आवश्यकता है, तो आपको आर्किटेक्चरल रजिस्टर नामों (x0-x31, f0-f31) का उपयोग करना होगा, न कि एबीआई नाम। असेंबली खंड में ही, आप किसी भी प्रकार के रजिस्टर नाम का उपयोग कर सकते हैं।

जैसा कि इन अवधारणाओं के लिए कोई नया है, क्या मैं बस इतना कह सकता हूं ... यह पूरी चर्चा _silly_ लगती है। यह कैसे है कि एक भाषा (असेंबली) जिसे इसके मशीन कोड के साथ 1 से 1 मैपिंग माना जाता है, इतना सिरदर्द का कारण बनता है?

मैं बहुत उलझन में हूँ:

• यदि आप एएसएम लिख रहे हैं, तो क्या इसे हर आर्किटेक्चर _और बैकएंड_ के लिए फिर से लिखना नहीं चाहिए ( #[cfg(...)] मानव द्वारा) आप समर्थन करने का प्रयास कर रहे हैं?
• इसका मतलब है कि "वाक्यविन्यास" प्रश्न विवादास्पद है ... बस उस वास्तुकला के लिए वाक्यविन्यास का उपयोग करें और संकलक का बैकएंड उपयोग करने के लिए होता है।
• रस्ट को केवल सही रजिस्टरों में बाइट्स डालने में सक्षम होने के लिए एसटीडी असुरक्षित कार्यों की आवश्यकता होगी और जो भी आर्किटेक्चर के खिलाफ संकलित किया जा रहा है उसके लिए स्टैक पर पुश/पॉप करें - फिर से, इसे हर आर्किटेक्चर और यहां तक ​​​​कि हर बैकएंड के लिए फिर से लिखना पड़ सकता है।

मुझे लगता है कि पिछली संगतता एक मुद्दा है, लेकिन बड़ी संख्या में बग और तथ्य यह है कि यह कभी स्थिर नहीं हुआ था, शायद इसे बैकएंड के साथ पास करना बेहतर होगा। एलएलवीएम या जीसीसी या किसी और की गलतियों को ठीक करने की कोशिश करने के व्यवसाय में जंग नहीं होनी चाहिए। जंग आर्किटेक्चर और कंपाइलर के लिए मशीन कोड उत्सर्जित करने के व्यवसाय में है ... और एएसएम मूल रूप से वह कोड है!

यहां कोई प्रगति नहीं होने का कारण यह है कि कोई भी इस मुद्दे को ठीक करने में समय नहीं लगा रहा है। किसी सुविधा को स्थिर करने का यह एक अच्छा कारण नहीं है।

इस सूत्र को पढ़ते हुए, मेरे मन में एक विचार आया और इसे पोस्ट करना पड़ा। क्षमा करें यदि मैं एक पुरानी पोस्ट का उत्तर दे रहा हूं, लेकिन मुझे लगा कि यह इसके लायक है:

@ मुख्य-- ने कहा:

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

हो सकता है कि इनलाइन एएसएम के बजाय, हमें वास्तव में यहां एलएलवीएम के लिए फ़ंक्शन एट्रिब्यूट्स की आवश्यकता है जो ऑप्टिमाइज़र को बताती है: "थ्रूपुट के लिए इसे अनुकूलित करें", "विलंबता के लिए इसे अनुकूलित करें", "बाइनरी आकार के लिए इसे अनुकूलित करें"। मुझे पता है कि यह समाधान अपस्ट्रीम है, लेकिन यह न केवल आपकी विशेष समस्या को स्वचालित रूप से हल करेगा (निम्न-विलंबता प्रदान करके लेकिन अन्यथा एल्गोरिदम के आइसोमोर्फिक कार्यान्वयन), यह जंग प्रोग्रामर को प्रदर्शन विशेषताओं पर अधिक बढ़िया नियंत्रण रखने की अनुमति देगा यह उनके लिए मायने रखता है।

@ felix91gr यह

@ मार्क-आईएम बिल्कुल नहीं। इसलिए मैंने एक शाब्दिक उद्धरण रखा है! मैं

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

सीसी https://github.com/CraneStation/cranelift/issues/444#issuecomment -531574394

इनलाइन असेंबली में आने वाले परिवर्तनों के आलोक में, इस अंक की अधिकांश चर्चा अब प्रासंगिक नहीं है। इस प्रकार, मैं इनलाइन असेंबली के प्रत्येक स्वाद के लिए दो अलग-अलग ट्रैकिंग मुद्दों के पक्ष में इस मुद्दे को बंद करने जा रहा हूं:

• एलएलवीएम-शैली इनलाइन असेंबली के लिए ट्रैकिंग समस्या ( llvm_asm ) #70173
• इनलाइन असेंबली के लिए ट्रैकिंग समस्या ( asm! ) #72016