\documentclass{article}
\input{6828-preamble}

\begin{document}
\psetnum{7}
\date{2004/09/30}

\begin{pset}
  \begin{problem}
    The new value for the PC is \texttt{0304}, taken from memory
    location \texttt{034}. The new value for the PSW is taken from the
    next word.
  \end{problem}

  \begin{problem}
    The user stack is unmodified by the trap. The PC and PSW are
    pushed onto the kernel stack.
  \end{problem}

  \begin{problem}
    The stack looks like:
\begin{verbatim}
141770: 030346 -- new PSW -- pushed by MOV in C function ``trap''
141774: 000002 -- old PC  --  pushed by hardware during trap
141776: 170000 -- old PSW --  pushed by hardware during trap
\end{verbatim}
  \end{problem}

  \begin{problem}
    The assembly \texttt{trap} procedure calls the \texttt{call}
    procedure, which sets up the stack (see below), then uses
    autoincrement-deferred addressing to jump to the C \texttt{trap}
    procedure via doubly-indirect addressing. It jumps to the location
    pointed to by the word in the location stored in R0. R0 contains
    the PC after the \texttt{JSR} on line 762, which happens to
    contain the location of the C \texttt{trap} procedure, because the
    \texttt{JSR} is inexplicably followed by \texttt{\_trap}. Thus, the
    deferred addressing \texttt{JSR} on line 785 jumps to
    \texttt{\_trap}.\footnote{If I ever write code this cryptic, please
    shoot me.}
  \end{problem}
  
  \begin{problem}
At the time the C \texttt{trap} is invoked, the stack looks like:
\begin{verbatim}
sim> e -v 141760-141776
141760: 000430   return PC
141762: 000006   dev      -- type of trap (from nps)
141764: 177760   sp       -- user stack pointer
141766: 141766   r1       -- saved value of R1
141770: 030346   nps      -- new PS, after trap
141772: 000000   r0       -- saved value of R0
141774: 000002   pc       -- PC from trap
141776: 170000   ps       -- saved PS
\end{verbatim}
  \end{problem}
\end{pset}

\end{document}