คำสั่ง 68030 ที่ไม่ถูกต้องซึ่งบังเอิญช่วยให้ Mac Classic II บูตได้

 (downtowndougbrown.com)
2 คะแนน โดย GN⁺ 2025-01-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mac Classic II เกือบจะเขียนไปยังแอดเดรสที่ผิดพลาดจาก บั๊กกระโดดออกนอกขอบเขต ใน ROM แต่ CPU Motorola MC68030 จริงกลับรันคำสั่งที่ไม่มีเอกสารอธิบายและเปลี่ยนรีจิสเตอร์ A1 ทำให้หลีกเลี่ยงการแครชได้
  • ปัญหานี้ถูกเปิดเผยเมื่อเปิดใช้ การกำหนดแอดเดรส 32 บิต ในอีมูเลชัน Classic II ของ MAME โดยจะขึ้น Sad Mac และ Chimes of Death ขณะที่ในโหมดกำหนดแอดเดรส 24 บิตจะดูเหมือนบูตได้ตามปกติ
  • เส้นทาง InstallSoundIntHandler ใน ROM นำ BoxFlag 17 ของ Classic II ไปใช้กับตารางสาขาที่มี 16 รายการ ทำให้กระโดดไปยัง 0x40A43B94 ซึ่งตำแหน่งนี้เดิมเป็นกลางคำสั่ง MOVEA.L
  • ชุดไบต์ 0C EC 08 A9 00 04 คล้ายกับ CAS D1,D2,$0004(A4) แต่เป็น คำสั่งตระกูล CAS ที่ไม่ถูกต้อง เพราะมีการตั้งค่าบิตสงวนไว้ และบน 68030 จริงมันเปลี่ยนค่า A1 จาก FFFF8FBA เป็น 40A4BBB2
  • เมื่อตรวจสอบกับเครื่อง Classic II จริงโดยใช้ ROM ดัดแปลง 3 แบบ พบว่าถ้าลบคำสั่งนี้ด้วย NOP ฮาร์ดแวร์จริงก็จะล้มเหลวพร้อม Sad Mac เช่นกัน และ MAME จึงต้องเลี่ยงด้วยการแพตช์ ROM ชั่วคราวจนกว่าจะรู้พฤติกรรมที่ถูกต้อง

การบูตล้มเหลวของ Classic II ที่ถูกเปิดเผยใน MAME

  • MAME เป็นที่รู้จักกันดีในฐานะอีมูเลเตอร์เกมอาร์เคด แต่ก็รองรับการอีมูเลต Mac รุ่นที่ใช้ 68000 ด้วย
  • ระหว่างแก้ไขฟังก์ชันใน MAME ที่ใช้เรียกดีบักเกอร์ด้วยคีย์ลัด command+power ก็พบพฤติกรรมแปลกใน Classic II
    • Classic II มีปุ่มอินเทอร์รัปต์จริง และยังมีไมโครคอนโทรลเลอร์ “Egret” 68HC05 ที่จัดการคีย์บอร์ด เมาส์ และอื่น ๆ
    • ใน MacsBug มีโค้ดที่ส่งคำสั่งเพื่อเปิดใช้งานคีย์ลัด command+power
  • Classic II บูตได้ปกติใน โหมดกำหนดแอดเดรส 24 บิต แต่เมื่อเปิด โหมดกำหนดแอดเดรส 32 บิต ที่จำเป็นต่อการโหลด MacsBug จะขึ้น Sad Mac และ Chimes of Death
  • ตามเอกสาร Apple Tech Info Library รหัส Sad Mac 0000000F หมายถึง exception และ 00000001 หมายถึง bus error
    • บน Mac ตระกูล 68k นั้น bus error มักหมายถึงการเข้าถึงแอดเดรสที่ผิด เช่น การพยายามเข้าถึงการ์ดขยายที่ไม่มีอยู่จริง

แกะรอย ROM: เส้นทางเริ่มต้น sound interrupt

  • ในดีบักเกอร์ของ MAME มีการตั้ง breakpoint ที่แอดเดรสตัวจัดการ bus error 0x40A026F0 แล้วไล่เส้นทางการเรียกด้วย ROM symbol map
    • แอดเดรสนี้ถูกระบุเป็น GenExcps ใน ROM map
    • รูทีนจัดการข้อผิดพลาดร่วมถูกระบุชื่อว่า ToDeepShit
  • คำสั่งที่ทำให้เกิด bus error คือโค้ดต่อไปนี้ที่ 0x40A43B9C
move.b #$90, ($1c00,A1)
  • โค้ดนี้อยู่ในรูทีนที่ ROM map ระบุชื่อว่า InstallSoundIntHandler และเกี่ยวข้องกับการเริ่มต้น sound interrupt ของ Classic II
  • จริง ๆ แล้ว Classic II มีสถาปัตยกรรมใกล้กับตระกูล Macintosh LC มากกว่า Macintosh Classic ดั้งเดิม และใช้ EAGLE gate array ที่คล้ายกับชิป V8 ของ LC
    • นี่จึงเป็นเหตุผลที่ในโค้ด ROM มีชื่ออย่าง V8SndIntPatch1
    • EAGLE มีฟังก์ชันที่เทียบได้กับ Apple Sound Chip (ASC) เวอร์ชันย่อส่วนอยู่ภายใน

ปัญหาตารางสาขาที่ผิดพลาดและรีจิสเตอร์ A1

  • V8SndIntPatch1 ใช้ตัวเลือก gestaltHardwareAttr ของ Gestalt trap หรือก็คือ 'hdwr' เพื่อตรวจสอบคุณสมบัติของฮาร์ดแวร์
    • ถ้าไม่มีบิต gestaltHasASC ก็จะคืนค่าทันที
    • ใน Classic II มีการตั้งค่าบิต gestaltHasASC ไว้
  • หลังจากนั้นโค้ดจะอ่านค่า BoxFlag จาก 0xCB3 ใน RAM แล้วใส่ลงใน D0
    • ค่า BoxFlag ของ Classic II คือ 0x11 หรือ 17
  • โค้ดสาขาที่เป็นปัญหาจะคูณ D0 เป็นสองเท่าแล้วใช้เป็นออฟเซ็ตกระโดดแบบ PC-relative
add.w d0,d0
jmp loc_40A43B72(pc,d0.w)
  • เนื่องจากแต่ละคำสั่ง BRA.S ยาว 2 ไบต์ จึงออกแบบให้คูณค่า BoxFlag เป็นสองเท่าเพื่อนำไปใช้เป็นดัชนีของตารางสาขา
  • แต่ตารางจริงมีเพียง 16 รายการสำหรับ BoxFlag 0~15 เท่านั้น และค่า 17 ของ Classic II จึงอยู่นอกขอบเขต
    • เป้าหมายการกระโดดที่คำนวณได้คือ 0x40A43B72 + 0x22 = 0x40A43B94
    • ตำแหน่งนี้ไม่ใช่จุดเริ่มต้นของคำสั่งที่ตั้งใจไว้ แต่เป็นกลางคำสั่ง MOVEA.L
  • เดิมที MOVEA.L ควรจะโหลดแอดเดรสที่ถูกต้องเข้า A1 แต่เมื่อกระโดดเข้ากลางคำสั่ง A1 จึงคงค่าเดิมจากการคำนวณกระโดดแบบ relative ก่อนหน้าไว้ที่ 0xFFFF8FBA
  • จากนั้นเมื่อรัน move.b #$90, ($1c00,A1) แอดเดรสปลายทางสำหรับการเขียนจะกลายเป็น 0xFFFF8FBA + 0x1C00 = 0xFFFFABBA ซึ่งเป็นแอดเดรสที่ไม่ถูกต้องบน Classic II

พฤติกรรม 68030 ที่ไม่มีเอกสารอธิบาย

  • ชุดไบต์ที่การกระโดดออกนอกขอบเขตไปถึงคือดังนี้
0C EC 08 A9 00 04
  • ทั้ง IDA และ GNU objdump ไม่สามารถ disassemble ตำแหน่งนี้เป็นคำสั่งปกติได้อย่างถูกต้อง
  • เมื่อนำชุดไบต์เดียวกันไปรันใน MacsBug บน Macintosh IIci มันถูกแสดงผลคล้าย CAS.W D1,D2,$0004(A4) แต่หลังรันแล้วค่า A1 กลับเปลี่ยนไป
    • A1 เปลี่ยนจาก 0xFFFF8FBA ไปเป็นค่าที่ดูเหมือนแอดเดรสใน RAM
    • พบว่าค่า A1 ใหม่ขึ้นกับ A1 เดิม, A7 และ program counter
  • ตาม Motorola M68000 Family Programmer’s Reference Manual เวิร์ดแรกดูคล้ายคำสั่ง CAS แต่ในเวิร์ดที่สองมีบิต 3 บิตที่ควรเป็น 0 กลับถูกตั้งเป็น 1
  • เพราะฉะนั้นคำสั่งนี้จึงไม่ใช่ CAS ที่ถูกต้องตามเอกสาร แต่เป็น คำสั่งที่ไม่ถูกต้องซึ่งเปิดบิตสงวนไว้
  • บน 68030 จริง CPU ไม่ได้จัดการคำสั่งนี้เป็น illegal instruction exception แต่กลับทำ read-modify-write bus cycle ที่ A4+4
    • ถ้าตั้ง A4 เป็นแอดเดรสที่ไม่ถูกต้อง MacsBug จะแสดง bus error ระหว่างทำ read-modify-write ที่ A4+4
    • และ A1 ซึ่งปกติไม่ควรถูกเปลี่ยนโดย CAS ที่ถูกต้อง ก็กลับถูกเปลี่ยนด้วย

การตรวจสอบกับฮาร์ดแวร์ Classic II จริง

  • เพื่อพิสูจน์สมมติฐานนี้ ผู้เขียนได้ซื้อและซ่อม Classic II ที่ผลิตในปี 1991 แล้วเปลี่ยน ROM เป็น SST29EE010 EEPROM แบบโปรแกรมได้
    • คาปาซิเตอร์แบบติดผิวบน Mac รุ่นเก่าอาจมีน้ำยารั่วที่กัดกร่อนได้ จึงต้องถอดและซ่อมก่อนจ่ายไฟ
    • ใช้งาน logic board แยกจาก CRT และ analog board พร้อมใช้ตัวแปลง VGA ที่ทำจาก Raspberry Pi Pico เพื่อตรวจสอบภาพบนหน้าจอ
  • มีการใส่โค้ดแอสเซมบลี 68030 สำหรับแสดงค่า A1 ลงในพื้นที่ว่างของ ROM แล้วสร้าง ROM ดัดแปลง 3 แบบ
    • Custom ROM 1: แทนที่ MOVE.B ที่ 0x40A43B9C ซึ่งทำให้ Sad Mac ใน MAME ด้วยโค้ดแสดงค่า A1
    • Custom ROM 2: แทนที่คำสั่งคล้าย CAS ที่ 0x40A43B94 ซึ่งเป็นเป้าหมายของการกระโดดออกนอกขอบเขต ด้วยโค้ดแสดงค่า A1
    • Custom ROM 3: แทนที่คำสั่งคล้าย CAS ที่ 0x40A43B94 ด้วย NOP
  • Custom ROM 1 แสดงว่าโค้ดจุดนี้ถูกรันบนฮาร์ดแวร์จริงเช่นกัน และค่า A1 ณ จุดที่ MAME แครชคือ 0x40A4BBB2
    • ค่านี้เป็นแอดเดรสใน ROM จึงไม่เหมาะจะใช้เป็นปลายทางการเขียน แต่ถึงพยายามเขียนก็ไม่ทำให้เกิด bus error
  • Custom ROM 2 แสดงว่า A1 ก่อนการกระโดดออกนอกขอบเขตมีค่า 0xFFFF8FBA ตรงกับที่เห็นใน MAME
    • แปลว่าการกระโดดออกนอกขอบเขตเกิดขึ้นจริง
    • และสอดคล้องกับสมมติฐานที่ว่าคำสั่งคล้าย CAS ที่ตามมาคือสิ่งที่เปลี่ยน A1
  • Custom ROM 3 แสดงว่าเมื่อเอาคำสั่งคล้าย CAS ออก Classic II จริงก็ล้มเหลวพร้อม Sad Mac เช่นกัน
    • ในการทดสอบนี้ ฮาร์ดแวร์จริงขึ้น Sad Mac เดียวกันแม้อยู่ในโหมด 24 บิต
    • การที่ MAME ไม่ส่ง bus error กับการเขียนผิดพลาดในโหมด 24 บิต จึงเป็นพฤติกรรมที่ผ่อนปรนกว่าฮาร์ดแวร์จริง

ปัญหาที่ยังเหลืออยู่ใน MAME และวงการอีมูเลชัน

  • พฤติกรรมที่ค้นพบนี้เป็นกรณีที่ คำสั่ง MC68030 ที่ไม่มีเอกสารอธิบาย ทำ read-modify-write bus cycle และยังเปลี่ยนรีจิสเตอร์ A1 ด้วย
  • บั๊กใน ROM ของ Classic II ถูกซ่อนอยู่ได้เพราะพฤติกรรมนี้ และเครื่องจริงจึงทำงานได้ตามปกติ
  • โค้ดชิ้นเดียวกันนี้ยังพบใน ROM ของ Macintosh IIvx ที่ใหม่กว่า แต่ใน ROM นั้นมีการขยายขนาด jump table และกรณีของ Classic II จะกระโดดไป RTS ทันที
  • ด้วยพฤติกรรมนี้ จึงดูมีความเป็นไปได้สูงว่ายังไม่มีอีมูเลเตอร์หรือ implementation โคลนของ Motorola MC68030 ที่สมบูรณ์แบบ 100%
    • สามารถเขียนโค้ดสั้น ๆ ที่รันคำสั่งนี้แล้วตรวจค่า A1 เพื่อแยกแยะ 68030 จริงออกจากอีมูเลเตอร์ได้
  • จนกว่าจะเข้าใจพฤติกรรมของคำสั่งนี้อย่างถูกต้อง MAME จึงเลือก แพตช์บั๊ก ROM ของ Classic II เพื่อให้บูตได้
  • แยกอีกประเด็นหนึ่ง คีย์ลัด command+power ทำงานได้บน Classic II จริงเมื่อมีการติดตั้ง MacsBug แต่ใน MAME ยังใช้งานไม่ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-27
ความเห็นจาก Hacker News

  • พฤติกรรมของ MC68030 ที่ค้นพบอาจไม่ใช่คำสั่ง “ของจริง” ที่ผู้ออกแบบ CPU ตั้งใจสร้างไว้ แต่เป็นผลจากการที่ลอจิกภายใน CPU เผลอทำงานเมื่อเจอกับ illegal instruction และได้รับอินพุตแบบ don’t-care
    ปกติแล้ว CPU ควรตรวจจับ illegal instruction และโยน exception ออกมา แต่ดูเหมือนว่าในบางกรณีจะไม่เป็นเช่นนั้น
    หน้า 8-9 ของ https://www.nxp.com/docs/en/reference-manual/MC68030UM.pdf ระบุว่ามีการนิยาม illegal instruction จากแพตเทิร์นบิตของ “word แรก”
    คำสั่งครั้งนี้มี 3 word โดย word แรกถูกต้อง และบิตแปลกอยู่ใน word ที่สอง จึงมีความเป็นไปได้สูงว่า 68030 ไม่ได้ตรวจสอบ word ที่สอง แล้วเดินหน้าต่อด้วยลอจิกที่ใช้ implement คำสั่ง CAS

    • CPU จำลองที่เรียนในวิชาสถาปัตยกรรมคอมพิวเตอร์สมัยมหาวิทยาลัย แบ่ง opcode ออกเป็นหลายฟิลด์บิต โดยบิตบางตัวจะไปเปิดการทำงานพื้นฐานอย่าง adder
      opcode ที่ “ใช้ได้” ก็เป็นเพียงชุดค่าผสมที่มีประโยชน์พอจะเขียนลงเอกสาร ส่วนชุดที่ “ใช้ไม่ได้” ก็คือค่าผสมที่ไร้ประโยชน์หรือไม่มีความหมาย
      มองแบบนี้แล้ว illegal/mystery opcode ไม่ใช่ข้อยกเว้นที่น่าประหลาดใจ แต่แทบจะเป็นสิ่งที่หลีกเลี่ยงไม่ได้
    • ผมไม่ใช่ผู้เชี่ยวชาญ 68k แต่ดูเหมือนว่า word แรกอย่างเดียวจะถูกมองเป็น opcode และ word ที่สองใช้เลือก D register สำหรับ CAS
      ปกติคงคาดหวังว่าบิต 0 ที่ไม่มีความหมายตามเอกสารจะถูกเพิกเฉยไปทั้งหมด
      แต่ใน 68030 บิตเหล่านั้นอาจจำเป็นต้องเป็น 0 จริง ๆ และถ้ามีบิตถูกเปิดขึ้นมา ก็อาจไปกระตุ้นลอจิกฮาร์ดไวร์ของคำสั่งอื่น เหมือน illegal opcode ของ 6502

  • CAS เป็นตัวปัญหามาโดยตลอด และน่าจะเป็นคำสั่งที่ผมได้รับบั๊กรายงานจากฝั่งอีมูเลชันมากที่สุดด้วย
    เกม King of Fighters รุ่นเก่าเคยมีบั๊กที่ตรวจสอบ carry flag ของคำสั่ง SBCD “ผิด” และนำไปใช้กับการลดตัวจับเวลารอบและการจบรอบ
    แม้จะเป็นพฤติกรรมที่ไม่ได้บันทึกไว้ แต่ถ้าไม่อีมูเลต arithmetic status flag ของการคำนวณเลขฐานสิบแบบไบนารี KOF ก็จะมีตัวจับเวลารอบวนจาก 00 กลับไป 99 ไม่จบเสียที
    SNK นี่คือเทพแห่ง ชิป 68000 จริง ๆ

    • ในฐานะแฟนเรโทรอาเขตและ 68k ผมอยากฟังเพิ่มว่า SNK ใช้ 68K ได้ถึงขีดสุด อย่างไรบ้าง

  • เป็นการเดินทางที่ยาวมากจริง ๆ
    ทุกวันนี้ผมอาจไม่มีความอดทนจะมุดลงโพรงกระต่ายลึกขนาดนั้นแบบผู้เขียนแล้ว แต่ผมเข้าใจความ ภูมิใจจากการค้นคว้าจนรู้จริง ต่างจากแค่คิดว่าตัวเองรู้ได้มากเลย

    • ในฐานะผู้เขียน ผมมีแนวโน้มจะจมลงไปกับ การวิเคราะห์เชิงลึก แบบนี้พอสมควรถ้าไปเจออะไรเข้า
      ถึงจะใช้เวลามาก แต่ถ้าไปจนสุดทางได้ก็คุ้มค่ามากจริง ๆ

  • ผ่านมา 30 กว่าปีแล้ว ผมก็ยังทึ่งอยู่เสมอว่า UI ของดีบักเกอร์บน Mac สามารถมีประสิทธิภาพได้มากขนาดนั้นบนความละเอียดหน้าจอที่เล็กมาก
    รู้สึกได้ถึงงานฝีมือจริง ๆ

  • CPU แทบทุกตัวมี คำสั่งที่ไม่ได้บันทึกไว้ในเอกสาร และ 68k ก็ไม่ใช่ข้อยกเว้น
    เพียงแต่ในยุคนั้น คนที่มีทั้งความสนใจและความรู้ระดับล่างพอจะขุดเรื่องแบบนี้ ส่วนใหญ่ไปโฟกัสที่ x86/PC กันหมด ซึ่ง x86/PC ก็อาจถือได้ว่าเป็นสถาปัตยกรรมที่เปิดกว้างและเสถียรกว่าฝั่ง Apple มาก
    ไมโครโค้ดของ 8088 และ 8086 ถูก disassemble เมื่อไม่กี่ปีก่อนและมีการศึกษากันมากพอสมควร รวมถึงมีความพยายามทำ simulation ระดับทรานซิสเตอร์ด้วย
    โครงสร้างของพื้นที่ opcode บน x86 ก็ถูกสำรวจไว้อย่างละเอียดในเอกสารอย่าง
    http://ref.x86asm.net/geek.html
    https://gist.github.com/seanjensengrey/f971c20d05d4d0efc0781...
    ตอนนี้ยังไม่รู้แน่ชัดว่าคำสั่งนี้ทำอะไรเป๊ะ ๆ
    จากการทดสอบอย่างจำกัด ดูเหมือนว่าค่าผลลัพธ์ของ A1 จะขึ้นกับค่าเดิมของ A1, ค่า A7 และ program counter แต่ก็ยังไม่แน่นอน
    ถ้ามีใครทำโปรแกรมที่ลองใส่ค่าหลาย ๆ แบบให้กับรีจิสเตอร์และข้อมูลในหน่วยความจำเพื่ออนุมานพฤติกรรมที่แน่ชัดได้ ก็อาจทำให้อีมูเลชันแม่นยำขึ้นอีก
    ตอนนี้ MAME ยังแพตช์บั๊กนี้ใน ROM เพื่อให้ Classic II บูตได้ไปก่อน จนกว่าจะมีคนเห็นว่ามันคุ้มค่าพอจะขุดต่อ
    โดยส่วนตัวผมคิดว่ามันคุ้มค่าพอที่จะศึกษาให้ชัดเพื่อ ความแม่นยำของอีมูเลชัน
    ผมไม่ได้คุ้นกับ 68k มากนัก แต่บิตของคำสั่งให้เบาะแสอยู่ สมมติฐานหนึ่งคือบิต 5:3 ของ word ที่สองดูคล้าย mode field อีกชุดหนึ่ง และแทนที่จะเป็นโหมด 000 เพื่อเลือก Dn register กลับกลายเป็นว่า 101 ใช้เลือก (d16, An) อีกครั้ง ส่วนฟิลด์ Dc ที่มีค่า 001 ก็อาจถูกตีความเป็น A1

    • ขอแก้นิดหน่อยว่า 68k ไม่ใช่สถาปัตยกรรมของ Apple อยู่แล้ว
      68030 เป็น CPU เอนกประสงค์ที่ยอดเยี่ยมมากตัวหนึ่งในยุคนั้น และยังถูกใช้ใน Amiga 3000, Atari Falcon, Sun 3, NeXT Cube ฯลฯ ด้วย
    • ตอนที่ Mac Classic ยังมีความหมายอยู่ PC ยังไม่ได้ยิ่งใหญ่ขนาดนั้นในโลกคอมพิวเตอร์ตามบ้าน และฝั่ง x86/PC เองก็ยังมีคนขุดเรื่องแบบนี้ไม่มาก
      ฝั่งเดโมซีนยังคงหมกมุ่นกับคอมพิวเตอร์บ้าน 8 บิตอยู่ ส่วนคนที่ใช้ระบบ 16 บิตในบ้านก็มักโฟกัสไปที่ Atari กับ Amiga
      ที่ PC และ x86 เริ่มบูมในบ้านกันจริง ๆ คือหลังจากที่ VGA และการ์ดเสียง กลายเป็นองค์ประกอบมาตรฐานของ PC

  • ตอนเด็ก ๆ ผมเคยมี Amiga 2000 ที่ใช้โปรเซสเซอร์ 68000
    ตอนที่ได้ยินข่าว 68020 หรือ 68030 ผมตื่นเต้นมาก และหลังจากนั้นก็รู้สึกแบบเดียวกันกับสถาปัตยกรรม RISC
    เวลาให้ Amiga พูดประโยคอย่าง “Hello, how are you?” ด้วยเสียงเหมือนหุ่นยนต์ เพื่อน ๆ จะตื่นตะลึงกันเหมือนเพิ่งไปดวงจันทร์มา
    ไม่เคยนึกเลยว่าไม่ถึง 40 ปีต่อมา เราจะได้คุยกับคอมพิวเตอร์ด้วยภาษาธรรมชาติผ่าน LLM และใช้ Python, VS Code กับ LLM เป็นเครื่องมือทำงานอัตโนมัติแทบทุกอย่างที่ต้องการ
    เป็นยุคที่บ้าคลั่งจริง ๆ

  • คิดถึง ตระกูล 68000
    มันเป็นชิปที่ยอดเยี่ยมจริง ๆ

    • คิดถึง แอสเซมบลี 68000
      มันชัดเจนและมีเหตุมีผลอย่างที่งานวิศวกรรมที่ดีควรจะเป็น แค่อ่านผ่าน ๆ ก็เข้าใจได้ทันทีว่าเกิดอะไรขึ้น
      ตรงกันข้าม แอสเซมบลี x86 ส่วนใหญ่ดูเหมือนกองลูกเล่นแปลก ๆ ที่คนฉลาดฝืนเขียนออกมาหลังอดนอนมาทั้งคืน
      แนวคิดแบบเอารีจิสเตอร์มาลบกับตัวเองเพื่อให้ได้ 0 นี่เกินไปจริง ๆ

  • สงสัยว่านี่เป็น การป้องกันการคัดลอก เพื่อไม่ให้รันบนบางระบบโดยเฉพาะ หรือเป็นอาการที่เกิดขึ้นบน 68030 ทุกตัว

    • จากเนื้อหาในบทความ ดูว่าไม่น่าใช่การป้องกันการคัดลอก
      รายการสำหรับเครื่องนั้นหายไปจาก jump table ที่เกี่ยวข้อง และน่าจะเป็นไปได้ว่าทีมที่ทำ ROM ลืมเพิ่มรายการใหม่กันหมด แต่กลับทำงานได้แม้ไม่มีรายการในตารางโดยบังเอิญล้วนๆ
    • Apple เริ่มลองทำ planned obsolescence ทีละนิดอยู่แล้ว

  • บน Mac ยุคปัจจุบัน เรื่องแบบนี้ดูเหมือนจะเป็นไปไม่ได้อีกต่อไป
    ทุกวันนี้ เอกสารทางเทคนิค ของ Apple แย่มาก

    • มองว่าเหตุผลที่ Apple ไม่ให้เอกสารฮาร์ดแวร์ระดับนี้ ก็เพราะ Mac สมัยใหม่ไม่มี ความสามารถในการขยายระบบ ในระดับเทียบเท่ากันแล้ว
      ไม่ได้เปิด system bus ออกมาเป็นคอนเน็กเตอร์ให้ผู้ใช้เสียบการ์ดและให้นักพัฒนาภายนอกโต้ตอบกับฮาร์ดแวร์โดยตรงเหมือนเมื่อก่อน
      บน Mac ยุคใหม่ สิ่งที่โปรแกรมใน user space จัดการได้มี USB กับ Thunderbolt
      แน่นอนว่าไม่ได้ปฏิเสธว่าเอกสารของ API บางส่วนใน macOS รุ่นใหม่ก็ห่วยมาก
      ถ้าไปเจอหน้าเก่าที่มีหัวเว็บเป็นไล่เฉดสีน้ำเงินและเขียนว่า “Apple documentation archive” ก็จะรู้ทันทีว่าคุณได้เจอของดีเข้าแล้ว
    • ในสภาพแวดล้อมสมัยใหม่ มองว่าความน่าจะเป็นที่บั๊กแบบนี้จะหลุดเข้าเฟิร์มแวร์หรือซอฟต์แวร์ที่ปล่อยออกมานั้นต่ำกว่ามาก
      address space ใหญ่กว่ามาก และที่อยู่ส่วนใหญ่ก็ไม่ได้ถูกแมปไว้ ดังนั้นถ้าทำ memory operation ไปยังที่อยู่ขยะก็มักจะล้มเหลว และคำสั่งที่ไม่ถูกต้องก็น่าจะล้มเหลวเช่นกัน
      บั๊กที่ไปอ่าน jump table ด้วยดัชนีนอกช่วงแบบนี้ยังเกิดในซอฟต์แวร์สมัยใหม่ได้ แต่แทนที่จะวิ่งต่อแบบในกรณีนี้ โปรเซสน่าจะตายมากกว่า
      อ้างอิงเพิ่มเติมคือ WebAssembly มี linear address space เดียวและทุกที่อยู่สามารถอ่านและเขียนได้ จึงมีโอกาสเกิดบั๊กประเภทนี้ได้มากกว่า
      ถ้าที่อยู่ขยะยังอยู่ในช่วง ก็อาจอ่าน เขียน หรือทำ CAS ผิดที่แล้วรอดต่อไปได้
      แต่คำสั่งที่ไม่ถูกต้องแบบในบทความต้นฉบับจะทำให้โหลดโมดูล WASM ไม่สำเร็จ ดังนั้นจึงไม่เหมือนกับปัญหาใน Mac ROM นี้แบบ 1:1

  • สงสัยว่า 040/060 รองรับ “คำสั่งที่ไม่มีเอกสาร” นี้ด้วยหรือไม่

    • บน 040 ดูเหมือนว่ามันทำอะไรบางอย่างที่เกี่ยวกับ D1 จริง
      A1 ไม่ได้ถูกแตะเลย และแม้จะไม่ได้ทดสอบต่อ แต่ก็อาจเป็นไปได้ว่ามันแค่ถูกจัดการเป็น CAS ปกติ
      ตอน step คำสั่งนี้ครั้งแรกใน MacsBug บน LC 475 ระบบเกิด system error แต่หลังจากนั้นก็ไม่มีปัญหา
    • ลองเช็กบน Amiga ที่ใช้ 060 แล้ว ดูเหมือนว่าคำสั่งนี้จะไม่แก้ไข A register ใดๆ
      เป็นผลจากการทดสอบอย่างรวดเร็วมากกับ instruction word นั้นเพียงอย่างเดียว