diff options
Diffstat (limited to 'src/intro.tex')
| -rw-r--r-- | src/intro.tex | 43 |
1 files changed, 26 insertions, 17 deletions
diff --git a/src/intro.tex b/src/intro.tex index 112e7b4..195566a 100644 --- a/src/intro.tex +++ b/src/intro.tex @@ -116,14 +116,16 @@ isolation between subsystems. \section{RISC-V Software Execution Environments and Harts} The behavior of a RISC-V program depends on the execution environment -in which it runs. A RISC-V execution environment interface (EEI) +in which it runs. The execution environment defines the initial state of the program, the number and type of harts in the environment including the privilege modes supported by the harts, the accessibility and attributes of memory and I/O regions, the behavior of all legal instructions executed on each hart (i.e., the -ISA is one component of the EEI), and the handling of any interrupts +ISA is one component of the execution environment), +and the handling of any interrupts or exceptions raised during execution including environment calls. -Examples of EEIs include the Linux application binary interface (ABI), +An execution environment may conform to a common standard, +such as the Linux application binary interface (ABI) or the RISC-V supervisor binary interface (SBI). The implementation of a RISC-V execution environment can be pure hardware, pure software, or a combination of hardware and software. For example, opcode traps @@ -147,14 +149,15 @@ implementations include: \end{itemize} \begin{commentary} - A bare hardware platform can be considered to define an EEI, where + A bare hardware platform determines a complete execution environment, where the accessible harts, memory, and other devices populate the environment, and the initial state is that at power-on reset. - Generally, most software is designed to use a more abstract - interface to the hardware, as more abstract EEIs provide greater - portability across different hardware platforms. Often EEIs are - layered on top of one another, where one higher-level EEI uses - another lower-level EEI. + Generally, most software is designed to conform to a more abstract + standard for a RISC-V execution environment, such as the Linux ABI, + to provide greater portability across different hardware platforms. + Often these execution environment standards are layered on top of + one another, with a higher-level standard constraining the generality + permitted by one or more lower-level standards. \end{commentary} From the perspective of software running in a given execution @@ -162,7 +165,8 @@ environment, a hart is a resource that autonomously fetches and executes RISC-V instructions within that execution environment. In this respect, a hart behaves like a hardware thread resource even if time-multiplexed onto real hardware by the execution environment. -Some EEIs support the creation and destruction of additional harts, +Some execution environments support the +creation and destruction of additional harts, for example, via environment calls to fork new harts. The execution environment is responsible for ensuring the eventual forward @@ -668,11 +672,12 @@ exception or an interrupt. The instruction descriptions in following chapters describe conditions that can raise an exception during execution. The general behavior of -most RISC-V EEIs is that a trap to some handler occurs when an +most RISC-V execution environments is +that a trap to some handler occurs when an exception is signaled on an instruction (except for floating-point exceptions, which, in the standard floating-point extensions, do not cause traps). The manner in which interrupts are generated, routed -to, and enabled by a hart depends on the EEI. +to, and enabled by a hart depends on the execution environment. \begin{commentary} Our use of ``exception'' and ``trap'' is compatible with that in the IEEE-754 @@ -686,7 +691,7 @@ by a hart at runtime can have four different effects: \begin{description} \item[Contained Trap:] The trap is visible to, and handled by, software running inside the execution environment. For example, - in an EEI providing both supervisor and user + in an execution environment providing both supervisor and user mode on harts, an ECALL by a user-mode hart will generally result in a transfer of control to a supervisor-mode handler running on the same hart. Similarly, in the same environment, when a hart is @@ -710,8 +715,10 @@ by a hart at runtime can have four different effects: \item[Fatal Trap:] The trap represents a fatal failure and causes the execution environment to terminate execution. Examples include failing a virtual-memory page-protection check or allowing - a watchdog timer to expire. Each EEI should define how execution - is terminated and reported to an external environment. + a watchdog timer to expire. + The execution environment determines how execution is terminated + and whether and how the termination is reported to an external + environment. \end{description} Table~\ref{table:trapcharacteristics} shows the characteristics of each @@ -733,7 +740,8 @@ kind of trap. \label{table:trapcharacteristics} \end{table} -The EEI defines for each trap whether it is handled precisely, though +The execution environment determines for each +trap whether it is handled precisely, though the recommendation is to maintain preciseness where possible. Contained and requested traps can be observed to be imprecise by software inside the execution environment. Invisible traps, by @@ -745,7 +753,8 @@ if known-errorful instructions do not cause immediate termination. Because this document describes unprivileged instructions, traps are rarely mentioned. Architectural means to handle contained traps are defined in the privileged architecture manual, along with other -features to support richer EEIs. Unprivileged instructions that are +features to support richer execution environments. +Unprivileged instructions that are defined solely to cause requested traps are documented here. Invisible traps are, by their nature, out of scope for this document. Instruction encodings that are not defined here and not defined by |