पैंतीस साल पहले जारी एक माइक्रोप्रोसेसर में बग को कैसे खोजें

यह विश्वास करना कठिन है, लेकिन कभी-कभी प्रोसेसर में त्रुटियां अनिवार्य रूप से प्रोसेसर की तुलना में अधिक समय तक रहती हैं। हाल ही में मैं 16-बिट माइक्रोप्रोसेसर 1801BM1A के उदाहरण से इस बारे में आश्वस्त हुआ, जिसके आधार पर USSR में एक समय में घरेलू कंप्यूटरों का BK-0010 / 11M परिवार बनाया गया था। इस बारे में हबेरा के परिवार ने बार-बार लिखा।

बेकाशे की सक्रिय जीवन की अवधि 80 के दशक के अंत में आती है - पिछली शताब्दी के 90 के दशक की शुरुआत। इन वर्षों में, कई एकल उत्साही लोगों के प्रयासों के साथ-साथ मंडली के सदस्यों और सहयोगियों के समूहों के माध्यम से, बीसी आवेदन कार्यक्रमों का मुख्य सरणी विकसित किया गया था: खेल, उपयोगिताओं, विभिन्न "डॉस" (डिस्क ऑपरेटिंग सिस्टम)। सॉफ्टवेयर के विकास के समानांतर, बाह्य उपकरणों का निर्माण किया गया, जिसके तहत उनका सिस्टम सॉफ्टवेयर लिखा गया था। सामान्य तौर पर, इन 16-बिट पीडीपी जैसे कंप्यूटरों का पारिस्थितिकी तंत्र समान सिद्धांतों के अनुसार विकसित हुआ, उदाहरण के लिए, इंटेल 8080 पर आधारित शुरुआती 8-बिट ओपन आर्किटेक्चर और एस -100 बस विकसित हुए। बाद में, जैसे-जैसे हम सीडी की उपयोगितावादी भूमिका से दूर होते गए, प्रोग्रामिंग में फोकस डिमोसिन की ओर बढ़ गया।

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

शायद कालानुक्रमिक क्रम में इस कहानी को बताने के लिए समझ में आता है। सबसे पहले, मुझे तुरंत ध्यान देना चाहिए कि मैं "अनुभव के साथ प्रोग्रामर" बिल्कुल नहीं हूं, न तो व्यवसाय के द्वारा, न ही बीसी के उत्साही लोगों के एक समूह से संबंधित हूं, जिनके बारे में मैंने ऊपर लिखा था। मैं ईसा पूर्व दौर में आया था, आंशिक रूप से बचपन और युवा (एनालॉग और डिजिटल इलेक्ट्रॉनिक्स, पत्रिका यंग टेक्नीशियन , UT-88 और अन्य शिल्प और खामियों) के शौक के लिए उदासीनता के माध्यम से, और आंशिक रूप से वास्तुकला और कमांड सिस्टम PDP-11 में उनकी रुचि के माध्यम से। मेरे पास BK "हार्डवेयर में" नहीं है और मैं आमतौर पर BK के लिए कार्यक्रम चलाता हूं और इसे Android के लिए टेबलेट पर bkemu एमुलेटर में डिबग करता हूं ।

कुछ समय पहले, मैं ली-चेन वांग-ए के लेखक , कैलीडोस्कोप कार्यक्रम में दिलचस्पी रखने लगा। प्रोग्राम को मशीन कोड में 1976 में Cromemco Dazzler ग्राफिक्स अडैप्टर के साथ Altair 8800 कंप्यूटर के भाग के रूप में Intel 8080 माइक्रोप्रोसेसर के लिए लिखा गया था। मैं ली-चेन वांग-एक एल्गोरिथ्म को विस्तार से पार्स करना चाहता था और, उसी समय, इसे ई.पू. मुझे यह कहना चाहिए कि बहुरूपदर्शक को ई.पू. में पोर्ट करने की इच्छा पहले के डेमोक्रैस्टर्स के बीच व्यक्त की गई थी, और यहां तक ​​कि एल्गोरिथ्म को पार्स करने के प्रयास भी थे, लेकिन वे असफल थे।

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

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

अगली कुछ रातों को BK-0011M पर सिस्टम डॉक्यूमेंटेशन और सर्किट आरेख से घटने की कोशिश में बिताया गया, जहाँ ध्वनि के साथ कोई त्रुटि हो सकती है। बीसी में ध्वनि काफी सरल रूप से आयोजित की जाती है: ऑक्टल एड्रेस 177716 (टेप रिकॉर्डर कंट्रोल रजिस्टर) के साथ I / O रजिस्टर में 6 ठी बिट बफर से पीजोइलेक्ट्रिक स्पीकर (बीपर) तक आउटपुट होता है। 6 वीं श्रेणी के अलावा, समान रजिस्टर के बिट्स 2 और 5 4 प्रतिरोधों के साथ सबसे सरल डिजिटल-से-एनालॉग कनवर्टर से जुड़े हैं। इस कनवर्टर के आउटपुट से, ध्वनि टेप रिकॉर्डर पर जा सकती है। सब कुछ असाधारण रूप से स्पष्ट और तार्किक है, लेकिन इस रजिस्टर में डेटा आउटपुट पर लागू करने की कोशिश करने वाले बिट मास्क के संयोजनों की परवाह किए बिना, वास्तविक बीके पर कोई हठी ध्वनि नहीं थी। समानांतर में, मेरे द्वारा ज्ञात सभी बीके एमुलेटर स्थापित और परीक्षण किए गए थे - और ध्वनि सभी में काम करती थी!

कुछ बिंदु पर, मैं भी लगभग डेमीर को समझाने में कामयाब रहा कि उसका बीके दोषपूर्ण था, लेकिन व्यवहार को एक और लाइव BK-0011M, साथ ही BK-0010 पर दोहराया गया। मैं विचारों से बाहर भाग गया, और बीसी-थीम पर टेलीग्राम चैनल के निवासियों ने भी, कुछ भी नहीं बता सका ... हालांकि, घटना ने हमेशा की तरह मदद की। एक प्रयोग के दौरान, दामिर ने एमुलेटर पर एक डेमो लॉन्च किया ताकि यह सुनिश्चित हो सके कि एमुलेटर में ध्वनि है। और यहां उन्होंने ध्यान दिया कि एमुलेटर में न केवल ध्वनि है, बल्कि बीसी पर भी नहीं है, लेकिन एमुलेटर में और लाइव बीसी पर चित्र अलग हैं! यहां मुझे आपको याद दिलाना होगा कि मेरे कार्यक्रम में चित्र और ध्वनि दोनों एक ही कोड द्वारा उत्पन्न होते हैं। तदनुसार, इस समय मैं गलत जगह एक कारण की तलाश में था: कारण उस कोड में था जो स्क्रीन सामग्री के लिए डेटा उत्पन्न करता था।

डैमिर ने मुझे एक स्क्रीनशॉट भेजा, और यह स्पष्ट हो गया कि एल्गोरिथ्म उच्चतम 4 बिट्स की शून्य सामग्री के साथ बाइट्स पैदा करता है, और, संयोग से, ये बिट्स ध्वनि के लिए आउटपुट थे (यानी, हमेशा शून्य)। हालाँकि, एल्गोरिथ्म ने इस तरह से व्यवहार करने का कारण अस्पष्ट रहा। यह कोड में जगह है (PDP-11 से कोडांतरक मैक्रो 11, r0-r5 रेनिस्टर पंजीकृत करता है।)!)

; renamed registers a = %0 b = %1 c = %2 d = %3 e = %4 h = %5 ... ... asr b ; sets CF bic #177760, b bis b, c bis (h)+, c ; screen address in c movb (c), a ; get a byte from screen RAM bcc 1$ ; check CF bic #177760, a ; keep bits 0-3, clear rest bisb d, a ; fill bits 4-7 br 2$ 1$: bic #177417, a ; keep bits 4-7, clear rest bisb e, a ; fill bits 0-3 2$: ... ... 

किसी कारण से, वास्तविक ईसा पूर्व में, $ 1 के निशान पर एक सशर्त कूद हमेशा प्रदर्शन किया जाता था। अर्थात्, bcc निर्देश को हमेशा कैरी फ्लैग को रीसेट के रूप में माना जाता है, हालांकि ASR शिफ्ट निर्देश इस ध्वज को 0 या 1 पर सेट कर सकता है। यह कैसे हो सकता है, क्योंकि प्रोसेसर प्रलेखन के अनुसार, न तो BIC, न ही BIS, और न ही MOVB ध्वज ले जाने को प्रभावित करना चाहिए!

इसके अलावा, सभी एमुलेटरों में (जो प्रोसेसर के लिए प्रलेखन के अनुसार लिखे गए थे!) यह इतना है: ये निर्देश सी ध्वज नहीं हैं। यह स्पष्ट हो गया कि वास्तविक प्रोसेसर 1801BM1A प्रलेखन के अनुसार इस मामले में काम नहीं करता है। इसकी पुष्टि करना बाकी है।

शुरुआत के लिए, एक स्पष्ट त्वरित सुधार:

  ... asr b ; sets CF mfps -(sp) ; store PSW on stack bic #177760, b bis b, c bis (h)+, c ; screen address in c movb (c), a ; get a byte from screen RAM mtps (sp)+ ; restore PSW from stack bcc 1$ ; check CF ... 

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

  ... mov #1, r1 jsr pc, test clr r1 jsr pc, test halt test: mov #40000, r2 ; r2 points to screen RAM mov #dummy, r5 ; r5 points to dummy = 200 ; *** begin *** asr r1 ; affects CF bic #177760, r1 bis r1, r2 bis (r5)+, r2 movb (r2), r0 ; *** end *** jsr pc, prt rts pc prt: mov #msg1, r0 bcs l1 mov #msg2, r0 l1: emt 64 rts pc msg1: .asciz /Flag CF set/ msg2: .asciz /Flag CF clear/ dummy: .word 200 ... 

और परीक्षण ... काम नहीं किया! स्क्रीन पर कार्यक्रम छपा

फ्लैग सीएफ सेट
फ्लैग सीएफ स्पष्ट

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

  ... mov #1, r1 jsr pc, test clr r1 jsr pc, test halt test: mov #40000, r2 mov #dummy, r5 ; *** begin *** asr r1 ; affects CF bic #177760, r1 bis r1, r2 bis (r5)+, r2 movb (r2), r0 bcc l1 ; *** end *** mov #msg1, r0 emt 64 rts pc l1: mov #msg2, r0 emt 64 rts pc msg1: .asciz /Flag CF set/ msg2: .asciz /Flag CF clear/ dummy: .word 200 ... 

और अब यह परीक्षण पहले ही वास्तविक BK-0011M पर मुद्रित हो चुका है:

फ्लैग सीएफ स्पष्ट
फ्लैग सीएफ स्पष्ट

एमुलेटर पर, पहले की तरह,

फ्लैग सीएफ सेट
फ्लैग सीएफ स्पष्ट

आगे तकनीक का मामला है। क्रमिक सरलीकरण के माध्यम से, इस तरह के एक न्यूनतम परीक्षण प्राप्त किया गया था जिस पर एक बग को पुन: पेश किया जाता है (मैं पूरे स्रोत को उद्धृत करता हूं):

  .title test .psect code .=.+1000 mov #15, r0 emt 63 sec jsr pc, test clc jsr pc, test halt test: movb r0, r0 bcc l1 mov #msg1, r0 emt 64 rts pc l1: mov #msg2, r0 emt 64 rts pc msg1: .asciz /Flag CF set/ msg2: .asciz /Flag CF clear/ .end 

एक वास्तविक BK-0011M पर, यह परीक्षण प्रदर्शित करता है

फ्लैग सीएफ स्पष्ट
फ्लैग सीएफ स्पष्ट

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

फ्लैग सीएफ सेट
फ्लैग सीएफ स्पष्ट

इससे एक परिष्कृत परिकल्पना तैयार करना संभव हो गया (मैं खुद को टेलीग्राम चैनल से उद्धृत करता हूं):

... बग के बारे में: ऐसा लगता है कि व्यवहार साफ हो गया है। जैसा कि मैं कल्पना करता हूं, MOVB src, dst (वैसे, ऐसा लगता है कि ऑपरेंड महत्वपूर्ण नहीं हैं), कुछ वास्तुशिल्प विशेषताओं के कारण, प्रोसेसर के अंदर C ध्वज को अस्थायी रूप से खराब कर देता है, लेकिन वसाहीन रूप से नहीं, क्योंकि प्रतिशत इस ध्वज की एक प्रति को बचाने के लिए लगता है। परिणामस्वरूप, अगर MOVB और सशर्त शाखा के बीच अन्य कमांड हैं (C को प्रभावित नहीं कर रहे हैं), उदाहरण के लिए, NOP, तो व्यवहार दस्तावेज में वर्णित है।

आगे क्या हुआ? इसके अलावा, चैनल के सहकर्मियों ने व्याचेस्लाव (@ K1801BM1, उस दिग्गज व्यक्ति को लाने में मदद की, जिसने पहले इस प्रोसेसर को ट्रांजिस्टर स्तर पर उलट दिया था) चर्चा के लिए। व्याचेस्लाव (युओट) की प्रतिक्रिया जब उन्होंने एक वास्तविक 1801BM1A (वर्तनी और विराम चिह्न संरक्षित) के साथ एक स्टैंड पर व्यवहार का परीक्षण किया:

स्टानिस्लाव मास्लोवस्की:
प्रजनन के लिए कम से कम दो आज्ञाओं की आवश्यकता होती है
सी में Movb और सशर्त कूद
ठीक है, इससे पहले, फ्लैग सी को एक ज्ञात स्थिति पर सेट करें

Yuot:
हमेशा रीसेट के साथ ध्वज प्राप्त होता है

स्टानिस्लाव मास्लोवस्की:
हां
अब nop डालें

Yuot:
अब कभी नहीं

Yuot:
प्रत्यावर्ती ० १
यह कुछ शर्म की बात है

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

अंत में, मैं इस बग की चर्चा में भाग लेने के लिए, और लेख के पाठ पर की गई टिप्पणियों के लिए BK0010 / 11M वर्ल्ड टेलीग्राम चैनल के ग्राहकों को धन्यवाद देना चाहूंगा। लेख के लिए शीर्षक तस्वीर Manwe_SandS के सौजन्य से है। अधिक दिलचस्प बात यह है कि, मनवे उसी बग की खोज करने के करीब था, लगभग उसी समय जब दामिर और मैं ध्वनि समस्या को हल करने के लिए संघर्ष कर रहे थे!

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

इस पर मैं समाप्त कर दूंगा। मुझे उम्मीद है कि यह दिलचस्प था।