Just for Fun. No, Really.

> They are indeed more complex and difficult to understand. But I fail to see how that is a criterium.

It's... not? Like, if you want to merely use an ISA, you don't need it to be simple or easy to understand, in fact tons of people pride themselves on making extremely high-performance RISC-V cores with OoOE and so on.

But the reason why someone might want a C implementation of an ISA is different from the reason people might want to go implement an ISA in a real project: maybe they want a software simulator that is easy to understand for one reason or another, perhaps for learning or demonstration purposes, or just as a fun hobby project.

These people wouldn't benefit from just pulling down Verilator or using one of the existing BATTLE-TESTED INDUSTRY-STANDARD PROFESSIONALLY-AUDITED HIGH-PERFORMANCE implementations because they literally don't care about any of those things.

In any case, it's a fallacy to assume that every programming project out there has to address a need in order to have a place. https://justforfunnoreally.dev

It’s hard to generate efficient code ahead-of-time because the compiler doesn’t know what the types of values will be, so it has to emit very general code that can cope with all possibilities at the expense of performance. A just-in-time compiler has access to this type information because it’s executing at runtime, so it’s able to generate more efficient code which only works in the more specific situation that is actually happening right then.

See Natalie [0] for a work-in-progress Ruby compiler which works ahead of time. It’s a super cool project but it’s just for fun [1] so I don’t believe it’s trying to compete on performance.

[0] https://natalie-lang.org/

[1] https://justforfunnoreally.dev/