Created a proper intro and refactored the doc
All checks were successful
Central(Architecture) Docs Build / Build Documentation (push) Successful in 11s
All checks were successful
Central(Architecture) Docs Build / Build Documentation (push) Successful in 11s
This commit is contained in:
parent
9615379f80
commit
58f56360e7
@ -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.
|
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/glossary.adoc[]
|
||||||
include::execution-engine-spec/data-manipulation.adoc[]
|
include::execution-engine-spec/intro.adoc[]
|
||||||
include::execution-engine-spec/ee-modes.adoc[]
|
|
||||||
include::execution-engine-spec/registers.adoc[]
|
include::execution-engine-spec/registers.adoc[]
|
||||||
include::execution-engine-spec/instructions.adoc[]
|
include::execution-engine-spec/instructions.adoc[]
|
@ -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.
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -2,6 +2,21 @@
|
|||||||
== Glossary
|
== Glossary
|
||||||
|
|
||||||
[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.
|
[horizontal]
|
||||||
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.
|
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.
|
||||||
|
|
||||||
|
@ -1,5 +1,7 @@
|
|||||||
== Instructions
|
== Instructions
|
||||||
|
|
||||||
=== Instruction Encoding Formats
|
=== 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[]
|
|
92
src/execution-engine-spec/intro.adoc
Normal file
92
src/execution-engine-spec/intro.adoc
Normal file
@ -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.
|
||||||
|
|
@ -1,10 +1,11 @@
|
|||||||
== Registers
|
== Registers
|
||||||
=== General Purpose Registers
|
=== General Purpose Registers
|
||||||
|
General purpose registers (GPRs) are used to perform calculations and store intermediate values.
|
||||||
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_*.
|
There are 8 GPRs in an Execution Engine. These registers are named *_r0_* through *_r7_*.
|
||||||
|
|
||||||
=== Special Purpose Registers
|
=== Special Purpose Registers
|
||||||
|
|
||||||
|
.Special purpose registers
|
||||||
[cols="1,1,1,1,3"]
|
[cols="1,1,1,1,3"]
|
||||||
|===
|
|===
|
||||||
|Name |User-mode |Supervisor-mode |Fault-mode |Description
|
|Name |User-mode |Supervisor-mode |Fault-mode |Description
|
||||||
|
Loading…
Reference in New Issue
Block a user