diff --git a/src/central-execution-engine-spec.adoc b/src/central-execution-engine-spec.adoc index a8a3f84..f73dc6b 100644 --- a/src/central-execution-engine-spec.adoc +++ b/src/central-execution-engine-spec.adoc @@ -7,7 +7,6 @@ This document presents the public interface of an _Execution Engine_ of the {cen This means that the amount of information pertaining to the internals of an _Execution Engine_ hardware implementation are kept at a minimum except when a choice in the public interface is specifically made to simplify said implementation. include::execution-engine-spec/glossary.adoc[] -include::execution-engine-spec/data-manipulation.adoc[] -include::execution-engine-spec/ee-modes.adoc[] +include::execution-engine-spec/intro.adoc[] include::execution-engine-spec/registers.adoc[] include::execution-engine-spec/instructions.adoc[] \ No newline at end of file diff --git a/src/execution-engine-spec/data-manipulation.adoc b/src/execution-engine-spec/data-manipulation.adoc deleted file mode 100644 index ab1836f..0000000 --- a/src/execution-engine-spec/data-manipulation.adoc +++ /dev/null @@ -1,16 +0,0 @@ -== Data Manipulation -=== Data Width -All the registers of the {central-arch-name} are 32bit wide. - -=== Address Width -Memory addresses are 24bit wide thus an _Execution Engine_ can address up to 16MB of memory. - -=== Memory Alignment -The {central-arch-name} uses byte-addressable memory. Under the hood, memory accesses are done on a memory-word boundary. -A memory-word is 32bit wide. To maximize performance, memory accesses should be done on a 32bit alignment. - -NOTE: The term "`memory accesses`" encompasses both read and write operations. - -=== Endianness -Data is encoded in memory with the little endian scheme. For a given value, the least significant byte (LSB) is stored in the lowest address and the most significant byte (MSB) in the highest. - diff --git a/src/execution-engine-spec/ee-modes.adoc b/src/execution-engine-spec/ee-modes.adoc deleted file mode 100644 index 734a41c..0000000 --- a/src/execution-engine-spec/ee-modes.adoc +++ /dev/null @@ -1,11 +0,0 @@ -== Execution Engine Modes - -User-mode:: - Lowest privilege level. User programs execute in this mode. These programs can access services provided in a higher privilege level by making supervisor calls (SVCs). - -System-mode:: - Highest privilege level (on par with fault-mode). The kernel executes its code in this mode. Control is passed to code executing in this mode when exceptions occur or when a user program makes a supervisor call (SVC). - -Fault-mode:: - Code only executes in this mode when a double fault occurs, i.e. when an exception is generated in system-mode code. The code executing under this mode should do the bare minimum to log or report the error and then reset/halt the system. - diff --git a/src/execution-engine-spec/glossary.adoc b/src/execution-engine-spec/glossary.adoc index 515623a..14a590f 100644 --- a/src/execution-engine-spec/glossary.adoc +++ b/src/execution-engine-spec/glossary.adoc @@ -2,6 +2,21 @@ == Glossary [glossary] -Central Processing Unit:: An hardware unit containing one or more _Execution Engines_, a memory controller, an interrupt controller, an operator facility controller and various other minor components. -Execution Engine:: The hardware responsible for the execution of user-written code, be it kernel code or user program code. An _Execution Engine_ contains a fetch unit, a decode unit, a micro-instruction sequencer, an Arithmetic & Logic Unit, various registers and subsystems. An _Execution Engine_ is analogous to an _hart_ in the RISC-V nomenclature or to a _core_ in other CPU specifications. +[horizontal] +Processing Complex:: + The hardware enclosure and the hardware inside said enclosure. + Composed of _Processing Units_, memory modules & controllers, an I/O subsystem, an _HMC_ communications controller and various other components. + +Processing Unit:: + An hardware unit containing one or more _Execution Engines_, cache controllers, an interrupt controller, ... + +Execution Engine:: + The hardware responsible for the execution of user-written code, be it kernel code or user program code. + An _Execution Engine_ contains a fetch unit, a decode unit, a micro-instruction sequencer, an Arithmetic & Logic Unit, various registers and subsystems. + An _Execution Engine_ is analogous to an _hart_ in a RISC-V processor or to a _core_ in other CPU specifications. + +HMC:: + Stands for Hardware Management Console. + This is a console directly attached to the _Processor Complex_ that is used to manage the different aspects of the hardware. + For example, the HMC is reponsible for loading the _Boot Code_ into main memory and instructing the _Processing Units_ to begin executing code at a given address. diff --git a/src/execution-engine-spec/instructions.adoc b/src/execution-engine-spec/instructions.adoc index e0906f6..46ac711 100644 --- a/src/execution-engine-spec/instructions.adoc +++ b/src/execution-engine-spec/instructions.adoc @@ -1,5 +1,7 @@ == Instructions - === Instruction Encoding Formats +Multiple instruction encoding formats are used to encode multiple kinds of instructions. +The source (rs1 and rs2) and destination (rd) registers are kept at the same position in all formats to simplify decoding. + +include::images/instruction-formats.adoc[] -include::images/instruction-formats.adoc[] \ No newline at end of file diff --git a/src/execution-engine-spec/intro.adoc b/src/execution-engine-spec/intro.adoc new file mode 100644 index 0000000..b697c54 --- /dev/null +++ b/src/execution-engine-spec/intro.adoc @@ -0,0 +1,92 @@ +== Introduction +=== Overview +The {central-arch-name} is a 32-bits architecture meaning that most of the registers present in an _execution engine_ are 32-bits wide. + +=== Memory +The {central-arch-name} uses byte-addressable memory. +While an _execution engine_ handles data 32-bits wide, memory addresses are only 24-bits wide. +An _Execution Engine_ can thus address up to 16MB of main memory. + +NOTE: We use the terms "`memory`" and "`main memory`" interchangably. Main memory refers to the RAM while we use the term "`secondary memory`" to refer to HDD or SSD storage. + +At the hardware level, memory accesses are done on a memory-word boundary. +A memory-word is 32-bits wide and memory accesses should be done at a 32-bits alignment to avoid wasting cycles doing double the amount of memory operations. + +NOTE: The term "`memory accesses`" encompasses both read and write operations. + +Data is encoded in memory with the little endian scheme. +For a given value, the least significant byte (LSB) is stored in the lowest address and the most significant byte (MSB) in the highest. + +=== System modes and privilege levels +There are three system modes divided into two privilege levels. + +The privilege levels are `privileged` and `unprivileged`. +Some instructions can only be executed and some registers can only be accessed while running under a system mode belonging to the `privileged` privilege level. + +.System modes +[cols="1,1"] +|=== +|Name |Privilege level + +|User-mode +|Unprivileged + +|Supervisor-mode +|Privileged + +|Fault-mode +|Privileged +|=== + +User-mode:: + User programs execute in this mode. + These programs can access services provided in a higher privilege level by making supervisor calls (SVCs). + +Supervisor-mode:: + The kernel executes its code in this mode. + Control is passed to code executing in this mode when exceptions occur. + Software executing in this mode provides context switching, I/O, process management and inter-process communications. + +Fault-mode:: + Code executes in this mode when a double fault occurs, i.e. when an exception is generated in system-mode code. + Code executing under this mode can be used to log/report double faults and then reset/halt the system. + Debug exceptions generated in supervisor-mode code are also handled in this mode, in which case control is passed back to supervisor-mode after handling. + +=== Exceptions +Exceptions are events that need to be acknowledged and handled by the system. +Exceptions change the state of the _execution engine_ so that privileged software can be executed to handle them. +Exceptions thus always suspend user code for the duration of their handling. + +Exceptions can be of two types: *synchronous* and *asynchronous*. + +==== Synchronous exceptions +Synchronous exceptions are generated from inside an _execution engine_. +They are a conditional or unconditional response to the execution of an instruction. + +SVC:: + Supervisor call exceptions are generated when a user program calls the `svc` instruction. + Supervisor calls are used to perform privileged actions in a secure manner. + +DataFault:: + A data fault is generated when an instruction references a memory address that is not mapped in virtual memory or that does not exist. + This exception is generated when read or writing memory as well as fetching an instruction. + +SysTick:: + This exception is generated each time a system programed timer ticks at regular intervals. + This exception is used to implement context switching. + +Debug:: + TODO + +==== Asynchronous exceptions +Asynchronous exceptions are generated from outside an _execution engine_. +These exceptions enable the system to react to its environment. + +HMC:: + This exception is generated when the _hardware management console_ communicates with a _Processing Unit_ and that the _Processing Unit_ relays the event to an _Execution Engine_. + Data can be passed alongside the exception and would be stored in main memory by the _Processing Unit_ communications controller. + +IO:: + This exception is generated when an I/O device communicates with the _Execution Engine_. + Data can be passed alongside the exception and would be stored in main memory by the I/O system. + diff --git a/src/execution-engine-spec/registers.adoc b/src/execution-engine-spec/registers.adoc index 145e2c9..b9870dd 100644 --- a/src/execution-engine-spec/registers.adoc +++ b/src/execution-engine-spec/registers.adoc @@ -1,10 +1,11 @@ == Registers === General Purpose Registers - -General purpose registers (GPRs) are used to perform calculations and store intermediate values. There are 8 GPRs in an Execution Engine. These registers are named *_r0_* through *_r7_*. +General purpose registers (GPRs) are used to perform calculations and store intermediate values. +There are 8 GPRs in an Execution Engine. These registers are named *_r0_* through *_r7_*. === Special Purpose Registers +.Special purpose registers [cols="1,1,1,1,3"] |=== |Name |User-mode |Supervisor-mode |Fault-mode |Description