\HeadingLevelB{Computational Model}
\label{sec:resources}

A simplified model presented in Figure~\ref{fig:computer_model} frames this work. Following sections refine this model into a detailed description of the Intel architecture.

\begin{figure}[htpb]
  \centering
  \includegraphics[width=65mm]{figures/computer_model.pdf}
  \caption{
    A high-level view of the architected memory resources of a
    CPU. The system bus also links memory-mapped and I/O devices,
    such as keyboards, which are
    also connected to the processor via the system bus.
  }
  \label{fig:computer_model}
\end{figure}


The building blocks for the model presented here come from the book
\citep{saltzer2009systemdesign}, which introduces the key abstractions in a
computer system, and  then focuses on the techniques used to build software
systems on top of these abstractions.

The memory is an array of individually addressable storage locations, indexed
via natural numbers, and implements the abstraction depicted in
Figure~\ref{fig:memory_abstraction}. Its salient feature is that the result of
reading a memory cell at an address must equal the most recent value written to that
memory cell by a given program.

\begin{figure}[htpb]
  \centering
  \begin{tabularx}{\columnwidth}{| X |}
  \hline
  \textsc{write}(\textit{addr}, \textit{value}) $ \rightarrow \varnothing $ \\
  Store \textit{value} in the storage cell identified by \textit{addr}. \\
  \hline
  \textsc{read}(\textit{addr}) $ \rightarrow $ \textit{value} \\
  Return the \textit{value} argument to the most recent \textsc{write} call
  referencing \textit{addr}. \\
  \hline
  \end{tabularx}
  \caption{The memory abstraction}
  \label{fig:memory_abstraction}
\end{figure}

A logical processor repeatedly reads \textit{instructions} from the
computer's memory and executes them, according to the flowchart in
Figure~\ref{fig:processor_execution}.

\begin{figure}[htpb]
  \centering
  \includegraphics[width=85mm]{figures/processor_execution.pdf}
  \caption{
    A processor fetches instructions from the memory and executes them. The RIP
    register holds the address of the instruction to be executed.
  }
  \label{fig:processor_execution}
\end{figure}

The processor has an internal memory, referred to as the
\textit{register file}. The register file consists of \textit{Static Random
Access Memory}~(SRAM) cells, generally known as \textit{registers}, which are
significantly faster than DRAM cells, but also a lot more expensive.

An instruction performs a simple computation on its inputs and stores the
result in an output location. The processor's registers make up an
\textit{execution context} that provides the inputs and stores the outputs for
most instructions. For example, \texttt{ADD RDX, RAX, RBX} performs an integer
addition, where the inputs are the registers RAX and RBX, and the result is
stored in the output register RDX.

The registers mentioned in Figure~\ref{fig:processor_execution} are the
\textit{instruction pointer}~(RIP), which stores the memory  address of the
next instruction to be executed by the processor, and the
\textit{stack pointer}~(RSP), which stores the memory address of the topmost
element in the call stack used by the processor's procedural programming
support. The other execution context registers are described in
\S~\ref{sec:address_spaces} and \S~\ref{sec:registers}.

Under normal circumstances, the processor repeatedly reads an instruction from
the memory address stored in RIP, executes the instruction, and updates RIP to
point to the following instruction. Unlike many RISC architectures, the Intel
architecture uses a variable-size instruction encoding, so the size of an
instruction is not known until the instruction has been read from memory.

While executing an instruction, the processor may encounter a \textit{fault},
which is a situation where the instruction's preconditions are not met. When
a fault occurs, the instruction does not store a result in the output location.
Instead, the instruction's result is considered to be the fault that occurred.
For example, an integer division instruction \texttt{DIV} where the divisor is
zero results in a Division Fault (\#DIV).

When an instruction results in a fault, the processor stops its normal
execution flow, and performs the fault handler process documented in
\S~\ref{sec:faults}. In a nutshell, the processor first looks up the address of
the code that will handle the fault, based on the fault's nature, and sets up
the execution environment in preparation to execute the fault handler.

The processors are connected to each other and to the memory via a
\textit{system bus}, which is a broadcast network that implements the
abstraction in Figure~\ref{fig:bus_abstraction}.

\begin{figure}[htpb]
  \centering
  \begin{tabularx}{\columnwidth}{| X |}
  \hline
  \textsc{send}(\textit{op}, \textit{addr}, \textit{data})
  $ \rightarrow \varnothing $ \\
  Place a message containing the operation code \textit{op}, the bus address
  \textit{addr}, and the value \textit{data} on the bus. \\
  \hline
  \textsc{read}() $ \rightarrow $ (\textit{op}, \textit{addr},
  \textit{value}) \\
  Return the message that was written on the bus at the beginning of this
  clock cycle. \\
  \hline
  \end{tabularx}
  \caption{The system bus abstraction.}
  \label{fig:bus_abstraction}
\end{figure}

During each clock cycle, at most one of the devices connected to the system bus
can send a message, which is received by all other devices connected to the
bus. Each device attached to the bus decodes the operation codes and addresses
of all messages sent on the bus and ignores the messages that do not
require its involvement.

For example, when the processor wishes to read a memory location, it sends a
message with the operation code \textsc{read-request} and the bus address
corresponding to the desired memory location. The memory sees the message on
the bus and performs the \textsc{read} operation. At a later time, the memory
responds by sending a message with the operation code \textsc{read-response},
the same address as the request, and the data value set to the result of the
\textsc{read} operation.

The computer communicates with the outside world via I/O devices, such as
keyboards, displays, and network cards, which are connected to the system bus.
Devices mostly respond to requests issued by the processor. However, devices
also have the ability to issue \textit{interrupt requests} that notify the
processor of outside events, such as the user pressing a key on a keyboard.

Interrupt triggering is discussed in \S~\ref{sec:interrupts}. On modern
systems, devices send interrupt requests by issuing writes to special bus
addresses. Interrupts are considered to be \textit{hardware exceptions}, just
like faults, and are handled in a similar manner.
