كيفية العثور على خطأ في المعالج الدقيق صدر قبل خمسة وثلاثين عاما

من الصعب تصديق ذلك ، لكن في بعض الأحيان تعيش الأخطاء في المعالجات بشكل أساسي أطول من المعالجات نفسها. في الآونة الأخيرة ، كنت مقتنعًا بهذا على سبيل المثال من خلال المعالجات الدقيقة 16 بت 1801BM1A ، والتي تم على أساسها إنشاء مجموعة أجهزة الكمبيوتر المنزلية BK-0010 / 11M في الاتحاد السوفيتي في وقت واحد. عن هذه العائلة على حبري كتب مرارا وتكرارا.

تقع فترة حياة بيكاشيك النشطة في نهاية الثمانينيات - بداية التسعينيات من القرن الماضي. في هذه السنوات ، من خلال جهود العديد من المتحمسين الفرديين ، وكذلك مجموعات من أعضاء الدوائر والمتعاونين ، تم تطوير المجموعة الرئيسية من برامج تطبيقات BC: الألعاب ، والمرافق ، ومختلف "DOSs" (أنظمة تشغيل القرص). بالتوازي مع تطوير البرمجيات ، تم إنشاء الأجهزة الطرفية التي بموجبها تم كتابة برنامج النظام الخاص بهم. بشكل عام ، تم تطوير النظام الإيكولوجي لأجهزة الكمبيوتر التي تشبه PDP ذات 16 بت وفقًا لمبادئ مشابهة ، على سبيل المثال ، تم تطوير بنيات 8 بت المفتوحة على أساس Intel 8080 و S-100 bus. في وقت لاحق ، وبينما نبتعد عن الدور النفعي لمؤتمر نزع السلاح ، تحول التركيز في البرمجة نحو الديموزين.

يمكن تقدير حجم البرنامج BC قبل زيارة المواقع العامة مع مجموعات من البرامج . بطبيعة الحال ، بالمقارنة ، على سبيل المثال ، مع ZX- الطيف ، وهذا الحجم هو أكثر تواضعا بكثير. ومع ذلك ، حتى هذا الحجم ، على ما يبدو ، كان يجب أن يكون كافيًا للالتفاف على جميع الزوايا المتصورة وكراني رمز الآلة. هل من الممكن العثور على شيء غير عادي في سلوك المعالج ، بعد أكثر من ثلاثين عامًا من الممارسة في استخدامه؟ كما اتضح - نعم! هذا سوف يناقش أدناه.

ربما يكون من المنطقي سرد ​​هذه القصة بترتيب زمني. بادئ ذي بدء ، يجب أن أشير على الفور إلى أنني لست على الإطلاق "مبرمجًا يتمتع بالخبرة" ، لا بالاحتلال ولا بالانتماء إلى مجموعة من عشاق BC ، الذين كتبت عنهم أعلاه. جئت إلى كولومبيا البريطانية بطريقة ملتوية ، جزئياً من خلال الحنين إلى هوايات الطفولة والشباب (الإلكترونيات التناظرية والرقمية ، ومجلة Young Technician ، و UT-88 وغيرها من الصناعات اليدوية والعيوب) ، وجزئي من خلال اهتمامي بالهندسة ونظام القيادة PDP-11 . ليس لدي BK "في الأجهزة" وأقوم عادةً بتشغيل برامج لـ BK وتصحيحها في محاكي bkemu على جهاز لوحي يعمل بنظام Android.

منذ بعض الوقت ، أصبحت مهتمة ببرنامج Kaleidoscope ، من تأليف Li-Chen Wang Wang . تمت كتابة البرنامج في رمز الجهاز في عام 1976 ، لمعالج Intel 8080 المصغر كجزء من جهاز كمبيوتر Altair 8800 مع محول رسومات Cromemco Dazzler . كنت أرغب في تحليل خوارزمية Li-Chen Wang-a بالتفصيل ، وفي الوقت نفسه ، نقلها إلى BC. يجب أن أقول إن الرغبة في نقل المشكال إلى كولومبيا البريطانية قد تم التعبير عنها بين علماء المساحة في وقت سابق ، وحتى كانت هناك محاولات لتحليل الخوارزمية ، لكنها لم تنجح.

في مقالتي التالية ، ربما سأقوم بتحليل هذه الخوارزمية بالتفصيل (ولصبر الصبر ، سأنشر رابطًا إلى مصادر Kaleidoscope عبر النظام الأساسي تحت libSDL في C). بالنسبة للمستقبل ، سيكون من الكافي الإشارة إلى أن المشكلة قد تم حلها ، وتم نقل المشكال بنجاح إلى BC. علاوة على ذلك ، تمت إضافة توليد الصوت إلى الخوارزمية الموجودة على القرص المضغوط ، وبما أنه يتم إنشاء كل من الصورة والصوت بواسطة نفس الرمز ، يمكننا القول أن الصورة نفسها تبدو (العرض التوضيحي كله يناسب أقل من 256 بايت من رمز الجهاز ، و ، آمل أن يتم تقديمه للجمهور في CAFe Demoparty 2019 في قازان في أواخر أكتوبر).

بعد أن انتهيت من كتابة وتصحيح برنامجي في المحاكي ، التفتت إلى Damir ("Adamych") Nasyrov (وهو أحد منظمي CAFe Demoparty وشخص مشهور بين علماء المنزليات) مع طلب التحقق من تنفيذ البرنامج في BC قبل الزمن الحقيقي. كنت مهتمًا بشكل خاص باستنساخ الصوت ، نظرًا لأن التوقيت في المحاكي قد يختلف عن توقيت الأجهزة الحقيقية. تخيل خيبة أملي عندما أخبرني دامير أن هناك صورة حقيقية قبل الميلاد ، لكن لا يوجد صوت!

أمضيت الليالي القليلة القادمة في محاولة للطرح من وثائق النظام على BK-0011M ومخطط الدارة ، حيث يمكن أن يكون هناك خطأ في الصوت. يتم تنظيم الصوت في BC بكل بساطة: يتم إخراج البت السادس في سجل I / O مع العنوان الثماني 177716 (سجل التحكم في تسجيل الشريط) من خلال مخزن مؤقت لسماعة كهرضغطية (الصافرة). بالإضافة إلى الفئة السادسة ، يتم توصيل البتات 2 و 5 من نفس السجل بأبسط محول رقمي إلى تمثيلي مع 4 مقاومات. من إخراج هذا المحول ، يمكن أن يذهب الصوت إلى مسجل الشريط. كل شيء واضح ومنطق بشكل استثنائي ، ولكن لم يكن هناك صوت عنيد على BK حقيقي ، بغض النظر عن مجموعات أقنعة البت التي حاولت تطبيقها على إخراج البيانات في هذا السجل. في موازاة ذلك ، تم تثبيت واختبار جميع محاكيات BK التي عرفتها - وكان الصوت يعمل في الجميع!

في مرحلة ما ، تمكنت تقريبًا من إقناع دامير بأن BK له كان خاطئًا ، ولكن تم تكرار السلوك على BK-0011M مباشرة ، وكذلك على BK-0010. لقد نفدت الأفكار ، ولم يستطع سكان قناة البرق في موضوع BC أيضًا أن يقولوا أي شيء ... ومع ذلك ، فقد ساعد الحادث ، كالعادة. في أحد التجارب ، أطلق دامير عرضًا تجريبيًا على المحاكي للتأكد من وجود صوت في المحاكي. وهنا تمكن من ملاحظة أنه لا يوجد صوت في المحاكي فقط ، ولكن ليس في BC ، ولكن أيضًا الصور الموجودة في المحاكي وعلى BC الحية مختلفة! هنا يجب أن أذكرك أنه في برنامجي يتم إنشاء كل من الصورة والصوت بواسطة نفس الرمز. وفقًا لذلك ، كنت أبحث طوال هذا الوقت عن سبب في المكان الخطأ: كان السبب في الكود الذي أنشأ البيانات الخاصة بمحتويات الشاشة.

أرسل لي دامير لقطة شاشة ، وأصبح من الواضح أن الخوارزمية تنتج بايتات ذات محتويات صفرية من أعلى 4 بتات ، ومن قبيل الصدفة ، تم إخراج هذه البتات إلى الصوت (أي ، دائمًا الأصفار). ومع ذلك ، فإن السبب وراء سلوك الخوارزمية بهذه الطريقة ظل غامضا. هذا هو المكان في الكود (مجمع 11 من PDP-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$: ... ... 

لسبب ما ، على BC قبل الميلاد ، تم إجراء قفزة مشروطة عند علامة $ 1. وهذا يعني أن تعليمة bcc تعتبر دائمًا علامة الحمل على أنها إعادة ضبط ، على الرغم من أن تعليمات تحول ASR يمكن أن تحدد هذه العلامة على 0 أو 1. كيف يمكن أن يكون ذلك ، لأنه وفقًا لوثائق المعالج ولا BIC أو BIS أو MOVB يجب أن تؤثر على حمل العلم؟!

علاوة على ذلك ، في جميع برامج المحاكاة (التي تمت كتابتها وفقًا للوثائق الخاصة بالمعالج!) إنه كذلك: لا تمس هذه الإرشادات العلم C. أصبح من الواضح أن المعالج الحقيقي 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 ... 

حفظ الإشارات على المكدس مباشرة بعد تعليمات الإزاحة واستعادتها قبل القفزة الشرطية حل المشكلة على الفور ، مما أظهر أنني كنت على المسار الصحيح. يبقى تضييق "دائرة المشتبه بهم". لاختبار الفرضية ، تمت كتابة مثل هذا الاختبار الصناعي لأول مرة (هنا لم تتم إعادة تسمية السجلات ؛ تم حذف التهيئة الأولية حتى لا تشوش الكود ؛ emt 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 ... 

والاختبار ... لم ينجح! برنامج مطبوع على الشاشة

مجموعة CF العلم
علم CF واضح

ما تحولت؟ اتضح أن الافتراض الأولي بأن جزء الكود بين البداية والنهاية يفسد علامة C ويحتاج إلى توضيح. ما هو الفرق بين هذا الاختبار ورمز المصدر؟ وحقيقة أن تعليمات أخرى ظهرت بين كتلة الأوامر "المشبوهة" والقفز الشرطي. لا يؤثر على العلامة 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 حقيقي:

علم CF واضح
علم CF واضح

على المحاكي ، كما كان من قبل ،

مجموعة CF العلم
علم CF واضح

كذلك مسألة التكنولوجيا. عن طريق التبسيط التدريجي ، تم الحصول على مثل هذا الاختبار الحد الأدنى الذي تم استنساخه خطأ (أقتبس المصدر بأكمله):

  .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 حقيقي ، يعرض هذا الاختبار

علم CF واضح
علم CF واضح

أي أن تعليمات MOVB التي كانت مباشرة أمام تعليمات الفرع الشرطي كانت هي المسؤولة ، وظهور المعامل الأول غير مهم. على سبيل المثال ، إذا تم إدراج NOP بين MOVB و BCC ، فسوف يعود السلوك إلى السلوك الموثق ، وسيطبع البرنامج

مجموعة CF العلم
علم CF واضح

هذا جعل من الممكن صياغة فرضية مكررة (أقتبس من قناة التلغراف):

... فيما يتعلق بالأخطاء: يبدو أن السلوك قد تم مسحه. كما أتخيل ، MOVB src ، dst (بالمناسبة ، يبدو أن المعاملات ليست مهمة) ، بسبب بعض الميزات المعمارية ، يفسد مؤقتًا العلامة C داخل المعالج ، ولكن ليس بشكل قاتل ، لأن النسبة المئوية يبدو أنها تحفظ نسخة من هذه العلامة. نتيجة لذلك ، إذا كان بين أوامر MOVB والفرع الشرطي أوامر أخرى (لا تؤثر على C) ، على سبيل المثال ، NOP ، فإن السلوك كما هو موضح في الوثائق.

ماذا حدث بعد ذلك؟ علاوة على ذلك ، ساعد زملاء من القناة في جلب Vyacheslav (@ K1801BM1 ، الرجل الأسطوري الذي عكس هذا المعالج سابقًا على مستوى الترانزستور) إلى المناقشة. رد فعل فياتشيسلاف (Yuot) عندما اختبر السلوك على موقف مع 1801BM1A الحقيقي (الإملاء وعلامات الترقيم المحفوظة):

ستانيسلاف ماسلوفسكي:
هناك حاجة إلى أمرين على الأقل للتكاثر
movb والقفز الشرطي في C
حسنًا ، قبل ذلك ، اضبط العلامة C على حالة معروفة

Yuot:
يتم الحصول على العلم مع إعادة تعيين دائما

ستانيسلاف ماسلوفسكي:
نعم
أدخل الآن nop

Yuot:
الآن أبدا

Yuot:
بالتناوب 0 1
هذا بعض العار

بمساعدة Vyacheslav ، تم العثور على التفاصيل ، أي أن السبب في هذا الخطأ هو أنه في المعالج ، بالإضافة إلى PSW ، هناك سجل 4 بت آخر ، والذي عادة ما يخزن نسخة من الأعلام من PSW. هذا السجل مرتبط بالبرامج الثابتة الآلية والانتقالات الشرطية تأخذ قيم العلم منه. عند تنفيذ الإرشادات MVB و SWAB و MFPS مع سجل المستقبِل ، نظرًا لخصائص معالجة ملحق الإشارة وبسبب خطأ في الرمز الصغير ، يتم تجاهل نسخة من العلامة C في هذا السجل ولا تعمل التحولات الشرطية التي تستخدم هذه العلامة بشكل صحيح. ومع ذلك ، باتباع الإرشادات أدناه ، تتم استعادة قيمة السجل المؤقت من PSW. هذا هو السبب ، الإدراج NOP يستعيد السلوك الصحيح.

في الختام ، أود أيضًا أن أشكر المشتركين في قناة التلغراف BK0010 / 11M World لمشاركتهم في مناقشة هذا الخطأ ، وعلى التعليقات التي أبديت على نص المقال. الصورة عنوان المقال هي من باب المجاملة Manwe_SandS . والأمر الأكثر إثارة للاهتمام هو أن مانوي كان على وشك اكتشاف نفس الخطأ ، في الوقت نفسه تقريبًا الذي كنت فيه أنا وأنا دامير نكافح لحل مشكلة الصوت!

الآن يعود الأمر إلى الحجم الصغير (مجرد مزاح) - اجعل جميع المحاكيات متوافقة مع السلوك الفعلي للمعالج. بعد كل شيء ، لا يمكن إصلاح المعالج نفسه ، للأسف.

على هذا سأنتهي. آمل أن تكون مثيرة للاهتمام.