सी भाषा: #DEFINEd मान 8-बिट गुणा को गड़बड़ करता है। क्यूं कर?

Question

मैं निम्नलिखित सी कोड है:

#define PRR_SCALE 255 
... 
uint8_t a = 3; 
uint8_t b = 4; 
uint8_t prr; 
prr = (PRR_SCALE * a)/b; 
printf("prr: %u\n", prr); 

यदि मैं यह संकलन (एक msp430 मंच संकलक का उपयोग कर, एक छोटा सा एम्बेडेड ओएस के लिए contiki कहा जाता है), जबकि मैं उम्मीद 191. (uint8_t typedef है 'परिणाम 0 है एक अहस्ताक्षरित चार)

के रूप में एड अगर मैं के लिए इसे बदल:

uint8_t a = 3; 
uint8_t b = 4; 
uint8_t c = 255; 
uint8_t prr; 
prr = (c * a)/b; 
printf("prr: %u\n", prr); 

इसे सही ढंग से काम करता है और प्रिंट 191.

01,235,

उबंटू बॉक्स पर जीसीसी का उपयोग करके इस 'सामान्य' के एक साधारण संस्करण को संकलित करना दोनों मामलों में सही मूल्य प्रिंट करता है।

मुझे बिल्कुल यकीन नहीं है कि यह क्यों है। मैं पहले से एक चर के लिए DEFINED मान निर्दिष्ट करके इसे बाधित कर सकता हूं, लेकिन मैं ऐसा नहीं करता।

क्या कोई जानता है कि यह क्यों है? शायद इसके बारे में कुछ और जानकारी के लिंक के साथ?

Answer 1

संक्षिप्त उत्तर: आप कंपाइलर छोटी है। (ओवरफ्लो के साथ कोई समस्या नहीं है, जैसा कि अन्य ने सुझाव दिया है।)

दोनों मामलों में, अंकगणित int में किया जाता है, जो कम से कम 16 बिट लंबे होने की गारंटी है। पूर्व स्निपेट में ऐसा इसलिए है क्योंकि 255int है, बाद में यह integral promotion की वजह से है।

जैसा कि आपने देखा है, जीसीसी इसे सही तरीके से संभालती है।

Answer 2

255 को एक पूर्णांक अक्षर के रूप में संसाधित किया जा रहा है और पूरी अभिव्यक्ति को हस्ताक्षरित चार आधारित के बजाय int आधारित होने का कारण बनता है। दूसरा मामला इस प्रकार को सही होने के लिए मजबूर करता है। अपने #define बदलते इस प्रकार का प्रयास करें:

#define PRR_SCALE ((uint8_t) 255) 

Answer 3

मुझे यकीन है कि नहीं कर रहा हूँ क्यों परिभाषित काम नहीं करता है, लेकिन आप uint8_t चर के साथ रोलओवर में चल रहा हो सकता है। 255 uint8_t (2^8 - 1) के लिए अधिकतम मान है, इसलिए यदि आप इसे 3 से गुणा करते हैं, तो आप कुछ सूक्ष्म रोलओवर समस्याओं में भागने के लिए बाध्य हैं।

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

चेक क्या हुआ अगर (इससे आप क्या चाहते हैं की तरह व्यवहार नहीं होगा) इस तरह से अपनी अभिव्यक्ति को तोड़ने होता है:

prr = c * a; // rollover! 
prr = prr/b; 

तुम सिर्फ एक बड़ा डेटाप्रकार उपयोग करने की आवश्यकता हो सकती है।

Answer 4

एक अंतर यह मैं मामले -1 में सोच सकते हैं,

PRR_SCALE शाब्दिक मूल्य ROM या कोड क्षेत्र में जा सकते हैं। और एमयूएल ओपेकोड में कुछ अंतर हो सकता है,

case-1: [register], [rom] 
case -2: [register], [register] 

यह बिल्कुल समझ में नहीं आता है।

Answer 5

यदि प्रश्न में संकलक mspgcc है, तो इसे संकलित प्रोग्राम की एक असेंबलर सूची को बाइनरी/हेक्स फ़ाइल के साथ एक साथ रखना चाहिए। अन्य कंपाइलरों को ऐसा करने के लिए अतिरिक्त कंपाइलर झंडे की आवश्यकता हो सकती है। या शायद बाइनरी पर एक अलग डिस्सेबलर भी चलाया जा सकता है।

यह जगह एक विवरण देखने के लिए जहां है। संकलक अनुकूलन करने के लिए कारण, वास्तविक प्रोसेसर के समक्ष प्रस्तुत कोड मूल सी कोड के लिए नहीं बहुत समानता हो सकता है (लेकिन आम तौर पर एक ही काम करता है)।

दोषपूर्ण कोड का प्रतिनिधित्व करने वाले कुछ असेंबलर निर्देशों के माध्यम से कदम उठाने से समस्या का कारण प्रकट होना चाहिए।

मेरा अनुमान है कि संकलक किसी भी तरह से पूरी गणना को अनुकूलित करता है परिभाषित स्थिरता संकलन समय पर एक ज्ञात हिस्सा है। 255 * एक्स को x < < 8-x (जो तेज़ और छोटा है) अनुकूलित अनुकूलित असेंबलर कोड के साथ कुछ गलत हो रहा है।

मैं अपने सिस्टम पर दोनों संस्करणों को संकलित करने के समय लगा। सक्रिय अनुकूलन के साथ, mspgcc निम्नलिखित कोड का उत्पादन:

#define PRR_SCALE 255 
uint8_t a = 3; 
uint8_t b = 4; 
uint8_t prr; 
prr = (PRR_SCALE * a)/b; 
    40ce: 3c 40 fd ff  mov #-3, r12 ;#0xfffd 
    40d2: 2a 42   mov #4, r10 ;r2 As==10 
    40d4: b0 12 fa 6f  call __divmodhi4 ;#0x6ffa 
    40d8: 0f 4c   mov r12, r15 ; 
printf("prr: %u\n", prr); 
    40da: 7f f3   and.b #-1, r15 ;r3 As==11 
    40dc: 0f 12   push r15  ; 
    40de: 30 12 c0 40  push #16576  ;#0x40c0 
    40e2: b0 12 9c 67  call printf  ;#0x679c 
    40e6: 21 52   add #4, r1 ;r2 As==10 

हम देख सकते हैं, संकलक सीधे 255 * करने के लिए -3 (0xfffd) 3 का परिणाम गणना करता है। और यहाँ समस्या है। किसी भी तरह 255 को 255 हस्ताक्षरित 16 बिट के बजाय -1-हस्ताक्षरित 8-बिट के रूप में व्याख्या किया जाता है। या इसे पहले 8 बिट तक पार्स किया गया है और फिर 16 बिट तक साइन-विस्तार किया गया है। जो कुछ भी।

इस विषय पर एक चर्चा mspgcc मेलिंग सूची में पहले ही शुरू हो चुकी है।