Exercise 1: Why TRAP Uses a Vector Table Instead of a Direct Jump — Possible Solution
====================================================================

WHAT BR/JSR DO INSTEAD
------------------------------
BR and JSR compute their target addresses directly from a PC-relative
offset baked into the instruction -- the address is derived, at
execution time, purely from arithmetic on the PC. Both are jumping to
locations inside YOUR OWN program, which you (or the assembler on
your behalf) already know the relative position of.

WHY TRAP CAN'T WORK THE SAME WAY
------------------------------
Per this chapter's own "OS/Hardware Boundary" section, TRAP jumps
into operating system service routines -- code your program doesn't
own and, more importantly, was never written to know the exact
memory location of. Your program only needs to know a small,
stable trap NUMBER (like x20 for GETC) -- not where the OS actually
placed that routine's real code in memory. If TRAP worked like BR/JSR
and required a fixed offset baked into your instruction, your program
would break the instant the OS's internal layout changed, even
slightly.

WHAT THE VECTOR TABLE ACTUALLY BUYS YOU
------------------------------
The vector table adds one layer of indirection: TRAP x20 looks up
whatever address is CURRENTLY stored at vector table entry x20, and
jumps there. This means the OS is free to place its actual GETC
routine anywhere in memory, or even move it between versions, as long
as it keeps updating vector table entry x20 to point at the right
place. Your program's own TRAP x20 instruction never has to change --
it always just says "whatever GETC currently is," and the vector
table is the one place that translation actually happens. This is
exactly the OS/hardware boundary the chapter describes: your program
depends on a stable, small set of trap NUMBERS, not on any specific
memory address belonging to the OS's own implementation.

WHY THIS WORKS AS AN ANSWER
------------------------------
It contrasts BR/JSR's direct, offset-based addressing (used for code
your own program owns) against TRAP's indirection through a lookup
table (used for OS code your program doesn't own or control the
location of), and explains the practical benefit of that indirection
using the chapter's own OS/hardware boundary framing.