Exercise 2: What Breaks If ISVOWEL Called a Nested Subroutine Without Saving R7 — Possible Solution
====================================================================

THE SETUP
------------------------------
COUNTLOOP executes JSR ISVOWEL. Per assembly1-7, this sets R7 to
"return-to-COUNTLOOP" — the address of the instruction right after
JSR ISVOWEL in the main program.

Now suppose ISVOWEL itself, somewhere in its body, executed
JSR LOGCHAR (to log each character) WITHOUT first saving R7 to the
stack, exactly as this chapter's tip-box warns against.

WHAT HAPPENS STEP BY STEP
------------------------------
1. JSR LOGCHAR runs. Per assembly1-7, this OVERWRITES R7 with a new
   value: "return-to-ISVOWEL" — the address right after the
   JSR LOGCHAR line, inside ISVOWEL's own body. The original
   "return-to-COUNTLOOP" address is now gone; nothing preserved it.

2. LOGCHAR finishes and executes its own RET. RET just jumps to
   whatever R7 currently holds — which is "return-to-ISVOWEL" — so
   execution correctly resumes right after JSR LOGCHAR, back inside
   ISVOWEL. This step looks completely fine on its own.

3. ISVOWEL finishes its vowel check and executes its own RET. But R7
   was NEVER restored to "return-to-COUNTLOOP" — it still holds
   "return-to-ISVOWEL" from step 1, because nothing in between ever
   set it back. So this RET jumps to "return-to-ISVOWEL" AGAIN —
   which is a location INSIDE ISVOWEL's own body, not back in
   COUNTLOOP at all.

THE EFFECT ON COUNTLOOP
------------------------------
COUNTLOOP never regains control. Instead, execution jumps back into
the middle of ISVOWEL (right after where JSR LOGCHAR was), and from
there falls through ISVOWEL's own remaining instructions again,
likely hitting the same JSR LOGCHAR a second time, then the same
broken RET a second time — the program is now stuck re-executing part
of ISVOWEL's own body in a loop it was never designed to have,
completely disconnected from COUNTLOOP and the rest of the main
program. This is exactly the class of bug assembly1-7's own warn-box
described: "the symptom shows up far from the actual mistake" — the
actual error (a missing save/restore) is invisible at the point where
things go wrong; what's visible is just a program that mysteriously
stops advancing through the buffer.

THE FIX
------------------------------
Exactly per assembly1-7's calling convention: ISVOWEL would need to
push R7 onto the stack immediately upon entry (before its own
JSR LOGCHAR), and pop it back immediately before its own RET —
restoring the original "return-to-COUNTLOOP" value that JSR LOGCHAR
would otherwise have destroyed.

WHY THIS WORKS AS AN ANSWER
------------------------------
It traces R7's value through all three steps precisely, identifies
the exact moment "return-to-COUNTLOOP" is lost, and explains the
resulting infinite-loop-like symptom in COUNTLOOP's own terms —
tying the failure directly back to assembly1-7's stated rule and its
own "symptom far from the mistake" warning.