MethodImplOptions.InternalCall का क्या मतलब है?

Question

बीसीएल में कई विधियों को [MethodImpl(MethodImplOptions.InternalCall)] विशेषता के साथ चिह्नित किया गया है। यह indicates कि "विधि सामान्य भाषा रनटाइम के भीतर ही लागू की जाती है"।

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

public static double Pow(double x, double y) 
{ 
    ldarg.0 
    ldarg.1 
    pow // Dedicated CIL instruction 
    ret 
} 

:

उदाहरण के लिए, Math.Pow इस तरह से (यह केवल एक नमूना मेरी बात समझाने के लिए सी # + आईएल और आईएल ही अगर यह बुरा है की मेरी अनौपचारिक मिश्रण बहाना) लिखा गया हो सकता वर्तमान तरीके के बजाय:

[MethodImpl(MethodImplOptions.InternalCall)] 
public static double Pow(double x, double y); 

MethodImplOptions.InternalCall क्यों मौजूद है?

Answer 1

मुझे लगता है कि एक बड़ा कारण यह है कि एक नया आईएल निर्देश बनाने में काफी मुश्किल है और यह बाहरी लोगों (ILGenerator, ilasm, ildasm, PEVerify, Reflector, PostSharp, ... सहित कई टूल को प्रभावित कर सकता है)।

लेकिन एक नया InternalCall विधि बनाना? सी # में विधि लिखने जितना सरल है (मुझे लगता है, मैंने रोटर को सत्यापित करने के लिए नहीं देखा) और यह किसी भी चीज़ को प्रभावित नहीं करता है।

और यह सिर्फ इसे बनाने के बारे में नहीं है, मुझे लगता है कि यह रखरखाव पर लागू होता है।

Answer 2

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

सिद्धांत रूप में, जब सीएलआर जेआईटी Pow के लिए नमूना कोड आपके पोस्ट में शामिल है, तो इसे pow निर्देश के लिए खुद को मूल कोड जारी करना होगा, क्योंकि कोई मूल निर्देश नहीं है (या है ना? कुछ साल पहले से नए x86 निर्देश सेट के साथ अद्यतित)। प्रदर्शन बिंदु के दृष्टिकोण से देखते हुए, कार्यान्वयन बिंदु से भी, pow कोड के लिए बस इसे "पेस्ट" की तुलना में, mscorlib में कॉल करना बहुत आसान है।

या, वे सामान्य mscorlib कार्यों के लिए एक लुकअप टेबल हो सकते थे जो InternalCall हैं और फ़ंक्शन को कॉल के साथ निर्देश को प्रतिस्थापित करते हैं। लेकिन फिर, सभी InternalCall उतना ही आसान नहीं है।

मुझे लगता है कि यह सुविधा के लिए एक व्यापार बंद था; दोनों तरफ, सीएलआर रखरखाव के लिए, एक और समान सीएलआई मानक और कॉलर्स को कुछ लचीलापन की अनुमति देने के लिए।

नीचे की रेखा यह है कि मैंने सीएलआर विकसित नहीं किया है और यह मेरे सिर के ऊपर से है। मैंने कुछ किया होगा, मुझे लगता है।

Answer 3

विधि मूल, मूल मूल, रनटाइम में ही लागू होती है। मत भूलना, सीएलआर सभी के बाद सी ++ से आता है। यह कंपाइलर की तरह है। वास्तविक दुनिया में, सीआईएल वास्तव में निष्पादित नहीं है। यह जेआईटी-टेड है और फिर एक सी/सी ++ रनटाइम द्वारा एक कंपाइलर की तरह निष्पादित किया जाता है। Math.Pow शायद सबसे अधिक [अटकलें] देशी सी/सी ++ math.h पाउ विधि में एक कॉल है, और यह कार्यान्वयन-परिभाषित है - अब नेट और मोनो सीएलआर लागू करते हैं।

UnityEngine.dll में, [MethodImpl(MethodImplOptions.InternalCall)] अधिकांश देशी बाहरी तरीकों पर उपयोग किया जाता है। ये सी ++ विधियां सीधे मोनो सी ++ सीएलआर लाइब्रेरी का उपयोग करती हैं और वे पी/इनवॉके के मुकाबले ज्यादा अंतरंग तरीके से सी # के साथ सह-संचालन कर सकती हैं। और जिस तरह से अधिक प्रदर्शनकर्ता (PInvoke कुछ कार्यान्वयन विवरण छुपाता है और कुछ समझने में कठोर बनाता है)

हालांकि, [MethodImpl(MethodImplOptions.InternalCall)] का उपयोग करने का एकमात्र तरीका यह है कि यदि आप सीएलआर रनटाइम स्वयं हैं - मैंने केवल इस तरह मोनो का परीक्षण किया है। मुझे नहीं पता कि माइक्रोसॉफ्ट के सीएलआर कार्यान्वयन को बदलने के लिए भी संभव है, लेकिन मोनो के साथ आप इस सुविधा का दुरुपयोग करने के लिए स्वतंत्र हैं।

इसके अलावा, [MethodImpl(MethodImplOptions.Unmanaged)] के साथ यह गड़बड़ न करें - यह पूरी कहानी है।

आंतरिक कॉल के बारे में अधिक और कैसे मोनो काम करता है, यहाँ: http://www.mono-project.com/docs/advanced/embedding/

अस्वीकरण: मैं एकता या मोनो से संबंधित नहीं हूँ!