Show HN: RISC-V core written in 600 lines of C89 (opens in new tab)

Not sure if this was intended, but coming to this as someone vaguely aware of RISC-V, it's looking like a fantastic form of documentation for the ISA, that both describes and gives a way to play with it, but in an intuitive, even fun manner.

Obviously this works best for someone who already knows C - but, given it's C89 mitigates against this aspect somewhat.

So you can compile and run it on any platform with a C compiler

Considering it's allocation-free, maybe it's an ultralight/ simulator for checking large quantities of compiler output? (i.e no VM to create and destroy for every testcase)

Or the same but for testing some verilog/vhdl CPU implemetation in a simulator?

Or since it's only 500SLOC, maybe it's just for fun!

Perhaps this could be used to run sandboxed code. Game engines could safely run mods using something like this, ala QuakeC.

It's more of a fun exercise, I guess. But I do have experience with at least one compiler that doesn't support C99: Zilog's ez80 C compiler. Back in the day I used to program my TI-84+ CE for fun[0], and the only C solution was a pretty bespoke C89-only compiler[1] distributed with a community toolchain[2], which has since switched to clang. It's somewhat irrational, but in the back of my mind it bugs me if the software I write can't run on platforms like that.

[0] https://github.com/mnurzia/chip8-ce

[1] http://www.zilog.com/docs/appnotes/pb0098.pdf

[2] https://ce-programming.github.io/toolchain/

One "advantage" (if one wants to call that) is that the code would also compile as C++, while C99 has diverged enough from the common C/C++ subset that one cannot use all C99 features in C++ mode.

I've met several people that seriously think that C89 is the peak of programming languages and that C99 just brings misfeatures (like, allowing variable declarations in middle of basic blocks according to them)

Funnily enough, the file rv.h does use stdint.h if available and contains the following comment:

> All I want for Christmas is C89 with stdint.h

Did Visual Studio finally make the jump?! (you could always just compile it as C++ code though)

Admittedly, C89 has very little utility, especially among people my age. For example, my university progresses from Racket to Java to C++, and has a systems course that partially teaches C11. Although good for teaching, I don't think those languages artificially constrained me in the ways that C89 does. I felt that my programming skills improved the most when I forced myself to work in such an under-powered language.

I also like the idea of being able to run my code anywhere, kind of like Doom.

I think kids or at least there’s the risk of kids seeing old people romantically reenacting their eight bit micro days and think that it’s some thing besides nostalgia.

I was kind of the opposite as a kid, if it wasn’t crazy futuristic I didn’t want it. So even in the 80s I wanted an FPGA accelerators in every machine.

Not really, my implementation isn't smart enough to guide compilers to the right solution. Trivial instructions, like xor, are of course recognized, but for example the 32x32 mul implementation isn't. Maybe compilers will be smart enough one day...

https://godbolt.org/z/WEcTzKf7M

Yeah, well, the rock that breaks your pick in that scenario is copying all the processor state back and forth to/from the emulation model, including flag register bits, and also correctly handling exceptions and faults. Emulating the instruction’s happy path is just scratching the surface.

'switch' is good, but for VM's computed goto is better.

nested "ifs" are optimized out by compilers. Moreover in the latest horrible gcc extensions you have the case statement using a _not_compiler constant expression (you can find the usage of such horrible gcc extension in linux net code).

There are several different types of CPU's, in two main classes, CISC and RISC. The difference is summarised by the first letter - "Complex" vs. "Reduced" - Instruction Set Computer. Or, what size "vocabulary" a CPU decodes.

RISC-V is a type of CPU architecture (a set of plans for how to build one, not an actual CPU itself), that also happens to be open source. Anyone can build a RISC-V CPU without having to buy the rights to do so. (Many are.)

This project is an emulation of a RISC-V CPU. A kind of virtual "reference" CPU in software. It can be used to compile code that can run on a RISC-V type CPU, and to help understand what's happening inside the CPU when it runs.

It's written in C, which is and was a very fundamental programming language that's influenced the design of many other languages. It is a language that is very close the fundamental language CPU's natively decode and process.

CPU's natively use a language referred to as "Assembly", but which actually has many varieties particular to each CPU design. Regardless of variety of CPU, assembly is usually is about as reasonably "close to metal" as it gets.

It's literally communicating with the CPU directly in its own language. This makes it extremely fast to run, but laborious to code, and also somewhat "dangerous" in that with such low-level control, it's easy to mess things up.

This project takes an input of a text list of RISC-V assembly instructions (a "program") and pretends to be RISC-V CPU with those instructions loaded into it and being run on it. Useful for understanding, prototyping and building a RISC-V program.

CPU's are designed rather to run assembly that already "works", having been created programmatically (compiled or interpreted), by a higher level language that isn't going to give it things that make no sense (hopefully).

So there is not usually a lot of provisioning done in the design of the CPU to make it easy to watch it and its state carefully at a low level and examine how your assembly program is working, or not working. Emulation eases this.

The core concepts are generally very straightforward, however it's always the optimization that adds complexity. That's how you get the orders of magnitude improvement. This C89 core definitely doesn't do macro op fusion for instance.

The complexity is in how to distribute dev workload and how to make it financially viable. No one pays for beautiful works of art unless it’s somehow anchored, tangled and aligned into their interests.

This is really cool, thanks for sharing! Something like this would be a great tool to distribute with my emulator.

The base instruction set is tiny but there are quite a few extensions and pretty much every practical implementation includes at least a few of them.

i.e. the GD32V microcontrollers implement RV32IMAC, Allwinner D1 which is a "full-blown" CPU meant to run Linux implements RV64IMAFDCVU.

RV32I/RV64I are the base 32/64 bit integer instruction sets and every letter after that is a different extension. Most of the extensions are relatively small and simple, but the C (compressed instructions) extension introduces some decoder complexity and the V (vector) extension adds several hundred instructions.

Though even with all the extensions it is still a very small/simple ISA by modern standards.

Pretty much all architectures have "simple" instruction sets under the hood, that is, the microcode that executes the mess we put in binaries. RISC-V is based on the idea that you can skip most of this step. The difficulty is getting fusing and other optimizations to work so the throughout remains high, which seems to work so far.

Not really, think of it like a... CPU emulator? Ish? You have registers as variables in the program. If you have register a1 and you are at an instruction adding 1 to it, it will add 1 to the variable representing a1. So on and so forth.

This works because, well, memory operations are mostly(all?) a CPU does so this "core" takes the program and does the same kind of memory operations the silicon would do, only in SW.