Created a proper intro and refactored the doc
All checks were successful
Central(Architecture) Docs Build / Build Documentation (push) Successful in 11s

This commit is contained in:
Elyan 2024-10-15 00:14:23 +02:00
parent 9615379f80
commit 58f56360e7
7 changed files with 117 additions and 35 deletions

View File

@ -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[]

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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[]

View 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.

View File

@ -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