😤 🖕🏽 💕 एसटीएम 32 और अन्य माइक्रोकंट्रोलर्स पर मेमोरी प्रोफाइलिंग: स्टैटिक स्टैक साइज एनालिसिस 🥀 ⚱️ 💛

नमस्कार, हेब्र!

पिछले लेख में , मैंने खुद इसका उल्लेख किया था और टिप्पणियों में पूछा था - ठीक है, ठीक है, वैज्ञानिक प्रहार विधि का उपयोग करके, हमने स्टैक के आकार का चयन किया, ऐसा लगता है कि कुछ भी नहीं गिर रहा है, लेकिन क्या हम किसी तरह अधिक मज़बूती से मूल्यांकन कर सकते हैं कि यह किसके बराबर है और कौन इतना खा रहा है?

हम संक्षेप में उत्तर देते हैं: हाँ, लेकिन नहीं।

नहीं, स्थैतिक विश्लेषण के तरीकों का उपयोग करना कार्यक्रम द्वारा आवश्यक स्टैक के आकार को सटीक रूप से मापना असंभव है - लेकिन, फिर भी, ये विधियां काम में आ सकती हैं।

जवाब थोड़ा लंबा है - कट के नीचे।

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

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

फ़ंक्शन अन्य फ़ंक्शन के अंदर कॉल करते हैं जिन्हें स्टैक की भी आवश्यकता होती है
कभी-कभी फ़ंक्शन अन्य फ़ंक्शन को उनके प्रत्यक्ष संदर्भ से नहीं, बल्कि एक फ़ंक्शन के लिए एक सूचक द्वारा कॉल करते हैं
सिद्धांत रूप में, यह संभव है - हालांकि इसे हर तरह से टाला जाना चाहिए - एक पुनरावर्ती फ़ंक्शन कॉल जब A कॉल B, B कॉल C, और C स्वयं कॉल करता है A फिर से कॉल करता है
किसी भी समय एक रुकावट हो सकती है, जिसमें से हैंडलर वही कार्य करता है जो स्टैक का अपना टुकड़ा चाहता है
यदि आपके पास व्यवधान का एक पदानुक्रम है, तो रुकावट के अंदर एक और व्यवधान हो सकता है!

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

अब एक तेल चित्रकला की कल्पना करें:

फ़ंक्शन ए, स्टैक पर 100 बाइट्स खाने, फ़ंक्शन बी को कॉल करता है, जिसे 50 बाइट्स की आवश्यकता होती है
बी के निष्पादन के समय, ए, स्वयं, स्पष्ट रूप से, अभी तक समाप्त नहीं हुआ है, इसलिए इसकी 100 बाइट्स को मुक्त नहीं किया गया है, इसलिए हमारे पास पहले से ही स्टैक पर 150 बाइट्स हैं
फंक्शन B फंक्शन C को कॉल करता है, और यह एक पॉइंटर के अनुसार ऐसा करता है, जो प्रोग्राम लॉजिक के आधार पर, 5 से 50 बाइट्स स्टैक के उपभोग करने वाले आधा दर्जन विभिन्न कार्यों को इंगित कर सकता है।
रनटाइम सी पर, एक बाधा एक भारी हैंडलर के साथ होती है जो अपेक्षाकृत लंबे समय तक चलती है और स्टैक के 20 बाइट्स का उपभोग करती है
बाधा प्रसंस्करण के दौरान, एक और उच्च प्राथमिकता वाला अवरोधन होता है, जिसके हैंडलर में 10 बाइट्स स्टैक की आवश्यकता होती है

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

जाहिर है, किसी भी स्वचालित स्टैटिक कोड विश्लेषक के लिए यह कार्य अत्यधिक करने के करीब है, और यह केवल ऊपरी अनुमान के लगभग अनुमान में ही किया जा सकता है:

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

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

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

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

GNU / gcc टूलचिन में इसके लिए दो अत्यंत उपयोगी उपकरण हैं:

झंडा-उपयोग-उपयोग
cflow उपयोगिता

यदि आप gf ध्वज (उदाहरण के लिए, CFLAGS के साथ लाइन में Makefile के लिए -fstack- उपयोग) जोड़ते हैं, तो प्रत्येक संकलित फ़ाइल% फ़ाइल नाम% .c के लिए संकलक फ़ाइल% फ़ाइल नाम% .su बनाएगा, जिसके अंदर सरल और स्पष्ट पाठ होगा।

उदाहरण के लिए, इस विशाल पाद के लिए target.su को लें :

target.c:159:13:save_settings 8 static target.c:172:13:disable_power 8 static target.c:291:13:adc_measure_vdda 32 static target.c:255:13:adc_measure_current 24 static target.c:76:6:cpu_setup 0 static target.c:81:6:clock_setup 8 static target.c:404:6:dma1_channel1_isr 24 static target.c:434:6:adc_comp_isr 40 static target.c:767:6:systick_activity 56 static target.c:1045:6:user_activity 104 static target.c:1215:6:gpio_setup 24 static target.c:1323:6:target_console_init 8 static target.c:1332:6:led_bit 8 static target.c:1362:6:led_num 8 static

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

उसी समय, ध्यान, यह फ़ाइल वास्तव में उन कार्यों के लिए स्टैक की वास्तविक खपत के बारे में सटीक जानकारी प्रदान नहीं करती है जिनसे अन्य कार्यों को बुलाया जाता है !

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

यहाँ हमें अधिक परिमाण का भार प्राप्त होता है, मैं इसका केवल एक ही लक्ष्य के लिए हिस्सा दूंगा।

 olegart@oleg-npc /mnt/c/Users/oleg/Documents/Git/dap42 (umdk-emb) $ cflow src/stm32f042/umdk-emb/target.c adc_comp_isr() <void adc_comp_isr (void) at src/stm32f042/umdk-emb/target.c:434>: TIM_CR1() ADC_DR() ADC_ISR() DMA_CCR() GPIO_BSRR() GPIO_BRR() ADC_TR1() ADC_TR1_HT_VAL() ADC_TR1_LT_VAL() TIM_CNT() DMA_CNDTR() DIV_ROUND_CLOSEST() NVIC_ICPR() clock_setup() <void clock_setup (void) at src/stm32f042/umdk-emb/target.c:81>: rcc_clock_setup_in_hsi48_out_48mhz() crs_autotrim_usb_enable() rcc_set_usbclk_source() dma1_channel1_isr() <void dma1_channel1_isr (void) at src/stm32f042/umdk-emb/target.c:404>: DIV_ROUND_CLOSEST() gpio_setup() <void gpio_setup (void) at src/stm32f042/umdk-emb/target.c:1215>: rcc_periph_clock_enable() button_setup() <void button_setup (void) at src/stm32f042/umdk-emb/target.c:1208>: gpio_mode_setup() gpio_set_output_options() gpio_mode_setup() gpio_set() gpio_clear() rcc_peripheral_enable_clock() tim2_setup() <void tim2_setup (void) at src/stm32f042/umdk-emb/target.c:1194>: rcc_periph_clock_enable() rcc_periph_reset_pulse() timer_set_mode() timer_set_period() timer_set_prescaler() timer_set_clock_division() timer_set_master_mode() adc_setup_common() <void adc_setup_common (void) at src/stm32f042/umdk-emb/target.c:198>: rcc_periph_clock_enable() gpio_mode_setup() adc_set_clk_source() adc_calibrate() adc_set_operation_mode() adc_disable_discontinuous_mode() adc_enable_external_trigger_regular() ADC_CFGR1_EXTSEL_VAL() adc_set_right_aligned() adc_disable_temperature_sensor() adc_disable_dma() adc_set_resolution() adc_disable_eoc_interrupt() nvic_set_priority() nvic_enable_irq() dma_channel_reset() dma_set_priority() dma_set_memory_size() dma_set_peripheral_size() dma_enable_memory_increment_mode() dma_disable_peripheral_increment_mode() dma_enable_transfer_complete_interrupt() dma_enable_half_transfer_interrupt() dma_set_read_from_peripheral() dma_set_peripheral_address() dma_set_memory_address() dma_enable_circular_mode() ADC_CFGR1() memcpy() console_reconfigure() tic33m_init() strlen() tic33m_display_string()

और वह आधा पेड़ भी नहीं है।

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

और जब हम अभी भी संकेत और इंटरप्ट, झुकाव द्वारा फ़ंक्शन फ़ंक्शन कॉल में नहीं लेते हैं। नेस्टेड (और विशेष रूप से इस कोड में, वे नेस्टेड हो सकते हैं)।

जैसा कि आप अनुमान लगा सकते हैं, हर बार जब आप कोड बदलते हैं, तो इसे हल्के ढंग से, मुश्किल से डालना - यही कारण है कि आमतौर पर कोई भी ऐसा नहीं करता है।

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

एसटीएम 32 और अन्य माइक्रोकंट्रोलर्स पर मेमोरी प्रोफाइलिंग: स्टैटिक स्टैक साइज एनालिसिस

More articles: