Basically, they had the API interface and implemented everything behind it. I think saying that "it's an RV32I core" vastly underrates the design work that goes into actually implementing an RV32I core from scratch.
What you describe (the specific implementation details of a core) is *microarchitecture*. In this case clearly a lot of work was done and it is cool, but the *architecture* is indeed RV32I and not custom
I was not undermining anything. I was helping others find the info I sought and took a while to find. This is why i left my comment. Everyone has their own interests. As an example, my thoughts were "whoa... a new architecture... did they write a new compiler or rewrite doom in assembly?" and for that "it is rv32i" would have been a quick answer.
[dead]
Anybody got a link to that?
Is it this?
https://www.instagram.com/armaan.gomes/reel/DatqWKChtnw/?hl=...
I was expecting a real video, not some 9 second clip posted to random social media website.
> random social media website
This reminded me of a project I built a while back: a RV32IM emulator in C++ that can boot and run DOOM. Initially I implemented only RV32I, and implementing the M extension provided a massive speedup!
If anyone's curious, here's the source code: https://github.com/lalitshankarch/rvcore
edit: I went to down a quick hole "The historical footnote is that a version of this genuinely happened. SNES Doom shipped with a Super FX 2 in the cartridge, a custom RISC chip with a pixel-plot instruction, because the console's own CPU had no chance. Jaguar and PlayStation ports both moved the rasteriser onto dedicated hardware. Doom's design was shaped by the absence of an FPU, and then hardware kept getting built to catch up with it."
I just did the same thing, but for a byte-code interpreter for a completely novel ISA I made up a while back (with an assist from Claude). I just haven't made the HN post yet, since I'm doing a bit of cleanup.
https://github.com/paulmooreparks/Maize/ https://paulmooreparks.github.io/Maize/
[dead]
[dead]
My friend...
Then, wire your simulator to https://github.com/riscv-software-src/riscv-tests, and there you have an official test suite. When everything passes, you have a fully-compliant RISC-V CPU. You can at this point tell GCC or Rust or your favourite language to compile to RV32IM and see it run on your simulator. It's a very gratifying process.
If you get at this stage, you might want to use the ecall instruction to hard-code I/O operations such as "read from stdin" or "print a character", and there you have a sandboxed CPU that you can target with your favourite programming language. Make it run DOOM (start with https://github.com/ozkl/doomgeneric and see which I/O do you need), or turn it into a toy game console; the sky's the limit.
---
Here's a copy-paste of the list of resources I have saved in my notes:
- https://github.com/libriscv/libriscv A very fast RISC-V VM with sandboxing of memory and syscalls.
- https://luplab.gitlab.io/rvcodecjs/ RISC-V Instruction Encoder/Decoder
- https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/noteboo... Reference card
- https://cs.brown.edu/courses/csci1952y/2024/assets/docs/risc... Spec
- https://riscv-software-src.github.io/riscv-unified-db/manual...
- ABI: https://lists.riscv.org/g/tech-psabi/attachment/61/0/riscv-a...
Good luck!
I made a post a while back that details the entire process: https://www.reddit.com/r/EmuDev/comments/1t1or4j/doom_runs_o...
The Super FX is a custom RISC chip, but it was custom made for Star Fox and used for other projects with refinements.
*just* a 486. :-(
> RV32I doesn't define the hardware architecture
FTFM - satisfied?