Would probably be a decent step in the right direction for validating/verifying the future of trusted computing.
Although... this gives rise to a 2nd thought. If it was _this easy_ to build a RISC-V implementation, is it all that special, technically speaking? I ask as someone naive about processor design. Is implementation relatively straightforward, but design hard?
However, if you want to build really high performance cores, there are plenty of challenging techniques you have to employ that add a lot of complexity that is hidden below the ISA abstraction layer (speculation for example).
So if you want to make RISC-V go fast, you have to employ more design tricks like "macro-op fusion". For example, scan for two load instructions in the fetch stream and fuse them into a single "load-pair" micro-op if they access adjacent addresses. There are a whole bag of tricks like this that are irrespective of the ISA and add a fairly high "skill-ceiling" to processor design.
Except for the C variant where they went to 110% complexity for maximum ICache efficiency: 32bit instructions aligned to 16bit?? I wonder if there are other RISC ISA which made the same choice.
The RISC-V ISA does great with a very small number of instructions, so playing around with encodings is rather easy. I'm reaching the conclusion that fixed 24-bit opcodes are an close to optimal if immediate constants are allowed after.
https://www.anandtech.com/show/13199/hot-chips-2018-samsungs...
The advantage of working with RISC-V over ARM right now is that you can configure a RV core to have far less capability than an ARM core. You can license RTL from SiFive for RV64imc (64-bit address and data, baseline integer instruction set, hardware multiply, and 16-bit compressed instructions). Such a core simply does not exist in the ARM marketplace today, partially because NEON is mandatory in ARMv8.
In RISC-V there are currently only 2 byte and 4 byte instructions, which you can brute force your way through. The specification does technically allow for longer sequences, in which case sandsifter will work just fine. [And the RISC-v privileged specification has existed for years].
It is a draft which has not been finalized and contains a disclaimer that it might be modified in a non-backwards compatible way prior to final release.
Chips with MMUs have been taped out for years. Likewise the Linux port has existed for years.
First the complexity comes in fully implementing the whole ISA. Yes RISC-V has an advantage over ARM/x86 in that it will have less cruft, but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real software requirements so RISC-V will need similar complexity if it wants to seriously challenge either architecture (with the advantage they can learn from the previous mistakes made and thus implement things more cleanly).
Second it comes in verifying your design, especially around the fun corner cases. There are plenty of bugs that occur when a series of rare things happens at once (maybe involving some obscure areas of the ISA) which can be very hard to track down. Unless you can successfully hunt down and fix these you'll end up with a phone or a computer that occasionally crashes for no good reason.
Third is making it hit your power and performance targets. It's one thing to say you have a 256-bit data path and can issue 4 instructions per cycle with out of order execution. It's quite another to build such a design so it can actually sustain decent throughput on real software whilst hitting a decent clock frequency and remaining within power budget, especially when you have all of the various complex bits of ISA to deal with.
Like what? Are you talking about extensions that don't exist for RISC-V, like Transnational Memory?
I would say most reason for complexity is legacy and there is little actual software requirements in that regard if your doing a new architecture.
Well for one thing your load may come in multiple sizes, can target different kinds of memory (e.g. device memory, non-cacheable memory, fully-cached memory, ARM architecture actually allows you to get quite specific about differing levels or shareability and cacheability too), can be unaligned with respect to the access size (but you still need full performance with them). There are ordering requirements with respect to other loads and stores in the system (even within the same CPU avoiding read-after-read ordering issues may not be simple) and various different kinds of barriers that can effect loads. You get exclusive loads or atomics (some variations can return the data seen so are performing a load on top the atomic op). It may be a vector load that needs to quickly feed the vector register file as opposed to the 'standard' register file. In a multi-processor system you can have various different types of snoop operation coming in that could effect the load. You also need to work out if you're actually allowed to do that load, modern page tables are pretty complex affairs. The page table itself could be changing as the load is executing. A decent chunk of the complexity is for virtualisation support but even without that there's various fiddly bits.
You also have speculative execution attacks to worry about. Certain loads may need to be very sure they should execute before doing anything, others may be free to speculate away and forward data into further speculative execution.
You can certainly build a perfectly functional ISA that avoids a lot of this (and avoid other things by keeping to a simple in-order microarchitecture) but that will loose you a lot of performance.
x86 has TSO and still is the fastest, so I think overall you are doing much better for yourself if you avoid massive complexity in your memory model because that is gone cost you in application complexity that you could be using for optimizations.
RISC-V has privilege architecture and a vector architecture as well, and they of course do add complexity, but are still simpler then corresponding functionality in ARM/x86 while doing many things better.
RISC-V was specifically design as it was because the ISA does really not impact performance that much and having something simple and understandable was not going to be a huge performance hit.