6 ms·
I understand that designing processors is fun, but I hold several things against RISC-V: - the assembler dst, src backward syntax (like intel); - the fact tha
by Annatar 10y ago
I understand that designing processors is fun, but I hold several things against RISC-V:
- the assembler dst, src backward syntax (like intel);
- the fact that this processor design is being aggressively pushed here (featured several times already);
- the fact that the instruction set is non-orthogonal (32-bit fixed encoding makes the decoder simple, but creates the same load-store problem as on SPARC - hello non-existent, synthetic instructions!);
- the fact that they could have extended the open source UltraSPARC T-series design, but decided to just re-invent the wheel all over again. How does 128-bit support justify starting from scratch, and not re-using what is already there and open sourced?
The last point is their biggest sin, in my view. There is already an open source processor design, and a good, solid design, and they just went ahead and invented their own anyway. All the lessons about reuse went out of the window. We're the only industry that I know of that keeps nuking itself and starting from scratch, throwing away all the work which had been done before.
Oh, and I seriously dislike the instruction mnemonics. To the authors of RISC-V:
couldn't you have made the mnemonics MC68000 compatible, or at least make them similar?
- rwmj 10y agoTo address a couple of these points: - Assembler syntax is a matter of personal preference. I also loved programming the 68K, writing OS-9/68k drivers back in 1990. However the vast majority of even kernel/embedded programmers rarely touch assembler these days. - SPARC & register windows. A very unfortunate design choice in hindsight. The RISC-V ISA developers have paid very close attention to existing designs, and other ISAs and microarchitectures are frequently referenced. Have a look at the discussions on the ISA-Dev mailing list: https://groups.google.com/a/groups.riscv.org/forum/#!forum/isa-dev https://groups.google.com/a/groups.riscv.org/forum/#!forum/i... - RISC-V is trying to avoid patents, so they cannot necessarily reuse existing ISAs, even open ones.
- Annatar 10y ago- SPARC & register windows. A very unfortunate design choice in hindsight. What do you mean, unfortunate design choice? The register windows help compilers and provide 256 virtual registers, thus significantly boosting performance. It's one of the biggest, best features of the Scalable Processor ARChitecture. And that's the exact feature RISC-V considers "unfortunate". I cannot believe it! Considering that the OpenSPARC cores are under the GPL, what impact do patents have in that case?
- rwmj 10y agoRegister renaming is a better way to provide large numbers of hardware registers. Another aim of RISC-V is to provide an architecture which is both easy to implement at the low end, and can be scaled at the high end. Register windows are not easy to implement. Register renaming OTOH can be left out of low end designs and included (as an invisible microarchitectural detail) at the high end. The smallest RISC-V implementation is PicoRV32 which is ridiculously small (https://github.com/cliffordwolf/picorv32 https://github.com/cliffordwolf/picorv32 - smallest is 725 LUTs in an FPGA). It couldn't have been done if the architecture had register windows. BTW I'm fairly certain that high end SPARC implementations must be doing register renaming, otherwise each function is limited to 8 or 16 registers.
- Annatar 10y agoOkay, so if we assume that implementing register windows is hard, why tackle the problem again, instead of reusing what is already there? The entire work appears to me to be the authors' personal bias against SPARC, possibly wanting to implement an entire processor from scratch, at all costs, no matter what. The patent argument seems very illogical for a code base under the GPL. Something just doesn't seem right.
- deleted 10y ago[deleted]
- 0xcde4c3db 10y ago> possibly wanting to implement an entire processor from scratch Wanting to facilitate others to do so, sure. This is a common thing to do in a computer engineering program, and I believe it was an explicit design goal that student projects could be real RISC-V implementations instead of targeting the toy ISAs commonly used for this purpose.
- popgoescarrot 10y agoIf RISC-V is supposed to scale down to the low end, why doesn't it have delay slots? On an implementation with a simple instruction pipeline, delay slots not only improve performance, they also simplify the hardware.
- deleted 10y ago[deleted]
- popgoescarrot 10y agoBased on your behavior in this comment thread -- downvoting comments that give valid criticism of the RISC-V ISA -- I have to conclude that the reason the RISC-V folks chose not to reuse a patent-unencumbered ISA such as SH2 or MIPS32 (minus the unaligned load-store instructions) is simple vanity.
- bonzini 10y agoWhat does your comment add to the discussion, and what is the proof of what you are attributing to the user?
- baobrien 10y agoFor one, MIPS32 and SH2 are both 32-bit ISAs. Extending them to 64-bit would require just as much compiler re-working as building a new RISC ISA -- and it'd no longer be MIPS32 or SH2 anyway.
- rwmj 10y agoI haven't downvoted a single thing in this thread. Other people are doing the downvoting.
- lgeek 10y ago> 32-bit fixed encoding makes the decoder simple, but creates the same load-store problem as on SPARC - hello non-existent, synthetic instructions! I'm not familiar with this. Could you explain the problem or point me in the right direction for background info?
- Annatar 10y agoIf you have 32-bits available to encode the instruction and the operand, how do you encode a load of a 32-bit address, or even a 64-bit address? That's why the SPARC assembler, as(1), accepts a completely made-up, non-existent, synthetic instruction, ld. In reality, what happens is that as(1) assembles this made-up fantasy into two instructions, sethi and or. This is the cold, hard reality of loading a 32-bit value from memory: String0: .asciz "Counter is %.2d\\n" .align 4 main: sethi %hi(String0), %l0 or %l0, %lo(String0), %l0
- lgeek 10y agoLooking at the RISC-V spec, you probably should be using the AUIPC instruction to address data in your .text, .data or .bss sections. As a bonus, your code becomes position-independent so you can actually use it in shared libraries. To use arbitrary 32-bit and 64-bit pointers known at compile-time (which should be pretty rare), you also have the option of loading them from memory, i.e. using AUIPC to generate a pointer to the value in your .text and then loading it to a register in addition to your approach.
- baobrien 10y agoKeep in mind, the UltraSPARC T1 and T2 are only two cores suited to specific workloads. They'd still be starting from scratch on the RTL if they wanted to do anything different with the microarchitecture. Now they've (UCB-BAR anyway) got at least one open out-of-order core suited to the higher end, a flexible in-order core for microcontroller up to cellphone operation; not to mention the gaggle of open RISC-V cores from outside UCB-BAR.
- baobrien 10y agoAlso, check out chapter 2 of this paper for the technical and licensing motivation to not go with SPARC or several other RISC ISAs: https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...
- renox 10y agoThat's funny, I don't like much the RISC-V because of the focus on minimalism(1), but the points I dislike are totally different from yours.. 1: no trap on integer overflow instructions? Come on: a) the MIPS (a processor designed for simplicity too) has those! b) in 21st century, security features should not be optional.