From 67f6c5c6f169cbd175258be557ea91c11f5ac0db Mon Sep 17 00:00:00 2001 From: Jacob Lifshay Date: Wed, 13 Aug 2025 22:25:39 -0700 Subject: [PATCH] group tasks for first_arch based off what is actually in the grant --- src/first_arch/index.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/first_arch/index.md b/src/first_arch/index.md index 9ca3f99..d67ac0b 100644 --- a/src/first_arch/index.md +++ b/src/first_arch/index.md @@ -4,13 +4,14 @@ The CPU architecture will be developed in several stages: -1. Getting an initial working CPU -- First NLNet/etc. Grant +1. [First NLNet Grant Proposal -- First CPU Architecture And Formal Proof of No Spectre bugs -- 2024-12-324](../first_arch/index.md) + 1. Getting an initial working CPU + 2. 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) Possible follow-on work, order TBD: * Expand CPU to support more operations (e.g. floating-point, vector ops., paging) * 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) * [Idea for much wider fetch/decode/rename width based on parallel-prefix-sum and taking more than 1 cycle per batch of renamed instructions](https://forum.libre-chip.org/t/idea-for-maybe-allowing-much-wider-fetch-rename-etc-widths-in-a-cpu/33) ## Register Renaming & Internal Registers