I became fascinated by what is happening in the RISC-V space just by seeing it pop up every now and then in my Twitter feed. Since I am currently unemployed I have a lot of time and autonomy to dig into whatever I wish.
RISC-V is a new instruction set architecture. To understand RISC-V, we must first dig into what an instruction set architecture is. This is my learning technique. I bounce from one thing to another, recursively digging deeper as I learn more.
Some more RISC-V information. I wouldn’t be surprised to see more and more RISC-V articles and even hardware to buy over the coming years.
While RISC-V is better than alternatives such as SPARC and old MIPS, fixing old issues (register windows, delay slots…), it was first designed as an educational instruction set, which could be implemented by students in a semester, with deliberately simple and limited base instruction set, for example without double indexed addressing modes, or multiple register instructions.
I would have preferred an instruction set designed to be the best possible from current state of the art, usually by iterating the instruction set on a compiler and simulator : Which addressing modes, which instructions,…
This is what ARM have likely done on ARMv8.
How are register windows and delay slots “issues”?
>> How are register windows and delay slots “issues”?
Register windows make for large register files, which are more complex to implement, and need extra management to handle spills. This has a hardware and software cost, for very little benefit. I was under the impression that one of the limiting factors of SPARC, and why the other RISC architectures often out-performed it, was the difficulties of implementation of a large, fast register file.
Delay slots are just wrong. Nice idea, when 4 or 5 stage pipelines were state of the art, and instruction execution was strictly scaler and in-order. But we’ve not been at that point since the early-nineties. The MIPS R4000 of 1991 had already moved beyond those simple pipelines which allowed the use of delay slots without interlocks (which was the point of the delay slots). As soon as we’re out of the simple R2000/R3000 pipeline, the interlocks have to come back in, and bubbles re-emerge. It was a leak of the pipeline implementation detail into the instruction set, a bad idea. We now have other measures in hardware to mitigate pipeline stalls.
Treza,
I don’t have any hands on experience with RISC-V, and I’m not likely to get any in my line of web/programming work, so I can’t really comment on the specifics. But I do agree with you in principal about how it should be developed. With that said though, I’d kind of prefer for the open community to focus it’s very limited resources on developing open FPGAs rather than traditional CPU architectures. The reason being proprietary FPGAs are more of a headache & obstacle today for developers than proprietary CPUs are. and I predict that FPGAs will have way more opportunity and innovation potential than new ISA to replace conventional CPUs. I think FPGAs will be coming to consumers in the next decade because the technology makes sense, but it would be a shame if we end up with some proprietary technology becoming the defacto standard for FPGAs and then having to fight several more decades for for open FPGAs. I’d rather have practical robust open FPGAs technology today before a proprietary solution controls the market.
I agree, vehemently.
Not commenting on RISC V, future will show if an extensible ISA will survive.
But the blog entry is not worth to be mentioned.
I thought, to read something on RISC V but all one gets is a bunch of links any search engine will spit out.
Ok, let’s write a blog also. How about: Digging into Atari Lynx and how I started hacking. Or: Digging into ZX81 and why “1 or 1” is “1” and “1 and 0” is “0”. More? No ,,,
Not commenting specifically on extensibility in ISAs, but extensibility in Forth brought the risk of making any substantive application a new fork of the language.