Exercise 2: Page Faults vs. Silent 6502 Stack Wraparound — Possible Solution ==================================================================== THE SHARED UNDERLYING PROBLEM ------------------------------ Both scenarios are the same fundamental category of hazard: a running program touching a piece of memory it has no legitimate business touching. Per cpu8bit1-3's own warn-box, pushing too many values onto the 6502's page-1 stack causes SP to silently wrap from $00 back to $FF, overwriting real data that was already sitting there — with "no error, no warning, just corrupted data." Per this chapter's own explanation, a program on x86-64 accessing a virtual address with no valid mapping in its own page table is the same basic situation: code reaching for memory beyond what it's actually entitled to use. HOW THE 6502 HANDLES IT ------------------------------ It doesn't, in any real sense. Per cpu8bit1-3, SP is just an ordinary 8-bit register being incremented and decremented like any other value — there is no hardware watching for "this is about to overwrite something important." The invalid access succeeds mechanically, silently corrupting real data, and the program continues running as if nothing went wrong, right up until that corrupted data causes a seemingly unrelated failure somewhere else entirely. HOW X86-64 HANDLES IT ------------------------------ Per this chapter's own explanation, x86-64's hardware actively checks every single memory access against the current process's own page table. An access to an address with no valid mapping doesn't succeed at all — it's actively detected and REFUSED, raising a page fault (a real, controlled CPU exception) at the exact moment the invalid access is attempted, rather than allowing it to happen and silently corrupt something. WHY THIS IS GENUINE ARCHITECTURAL PROGRESS ------------------------------ The 6502's own failure mode (silent corruption, symptom appearing far from the actual mistake) is precisely the kind of debugging nightmare this whole arc has flagged more than once as a real, serious hazard. x86-64's page fault converts that same category of mistake from "invisible until something else breaks" into "caught immediately, at the exact instruction that caused it" — a real, measurable improvement in how the same underlying class of bug is handled, decades later, once the hardware was actually designed to detect it. WHY THIS WORKS AS AN ANSWER ------------------------------ It identifies the shared underlying problem precisely (a program accessing memory it shouldn't), explains the 6502's own complete lack of detection using cpu8bit1-3's own stated mechanics, explains x86-64's own active detection using this chapter's stated mechanics, and frames the difference as a genuine improvement in WHEN and HOW the mistake becomes visible, not just a difference in terminology.