link to register renaming page

src/SUMMARY.md

@@ -1,5 +1,6 @@
 * [Libre-Chip](README.md)
     * [Proposal for Libre-Chip's First CPU Architecture (Draft)](first_arch/index.md)
+        * [Register Renaming](first_arch/register_renaming.md)
 * [Conduct](Conduct.md)
 * [License](LICENSE.md)
     * [GPL 3.0](gpl-3.0.md)

src/first_arch/index.md

@@ -12,6 +12,10 @@ Possible follow-on work, order TBD:
 * Add FPGA-style programmable decoder and μOp Cache, with trap-to-software fallback for uncommon/complex ops, which allows running more ISAs such as RISC-V, older x86-32/64, more PowerISA support, and then if we can figure out the legal situation, ARM and modern x86-64. The idea is QEMU (or similar) will be compiled with a special compiler that generates both the fallback software and the bitstream for the decoder, the compiled output will be covered by QEMU's license which has some patent clauses, which hopefully helps with the legal situation. Jacob Lifshay came up with this idea [back in 2022](https://web.archive.org/web/20220612082603/https://bugs.libre-soc.org/show_bug.cgi?id=841)
 * Formal proof that the CPU doesn't have any spectre-style bugs even though it still is OoO superscalar with speculative execution. Jacob Lifshay came up with this idea [back in 2020](https://web.archive.org/web/20201021124234/https://bugs.libre-soc.org/show_bug.cgi?id=209)
 
-## Architecture
+## Register Renaming & Internal Registers
 
-![](architecture.dia.svg)
+See [Register Renaming](register_renaming.md)
+
+## Architecture Diagram
+
+![](architecture.dia.svg)

src/first_arch/register_renaming.md

@@ -0,0 +1,26 @@
+# Register Renaming
+
+The Internal Register Addresses are of the following format:
+
+```mermaid
+---
+config:
+    packet:
+        bitsPerRow: 8
+---
+packet-beta
+    0-3: "Unit Number"
+    4-7: "Unit's Output Register"
+```
+
+The general idea is that every Unit has its own set of output registers that are only ever written by that Unit. Internal Register Addresses are also used as a handle for the corresponding instruction, for tracking when instructions are no longer speculative, cancelling mis-speculated instructions, and tracking when to retire instructions. Therefore, instructions that don't write any registers (such as stores) still have a Internal Register Address allocated for them.
+
+## L2 Register File
+
+Because each Unit doesn't necessarily have enough output registers to hold all ISA-level registers (e.g. a pathological sequence of divide instructions targetting each ISA-level register in sequence), the L2 Register File is used to hold ISA-level registers when there aren't enough registers available in the Unit that last wrote to the corresponding ISA-level register. The Register Renamer will automatically insert moves to and from the L2 Register File when a Unit runs out of registers or when ISA-level registers currently in the L2 Register File are read.
+
+## Distributed Registers (May or may not be a good idea)
+
+All Units' Output Registers are actually stored distributed in duplicated register files positioned at the beginning of every Unit's pipeline, this allows for faster reads from Units' Output Registers, as well as allowing register files to be more optimal for FPGAs since FPGAs tend to only support at most 2-port register files.
+
+![](distributed_registers.dia.svg)