8 ms·
It is fascinating that semantic confusion over RISC vs CISC persists since I was in college in the 80's. It is largely meaningless. The naive idea behind RISC
by 0xr0kk3r 3y ago
It is fascinating that semantic confusion over RISC vs CISC persists since I was in college in the 80's. It is largely meaningless.
The naive idea behind RISC is essentially to reduce the ISA to near-register-level operations: load, store, add, subtract, compare, branch. This is great for two things: being the first person to invent an ISA, and teaching computer engineering.
Look at the evolution of RISC-V. The intent was to build an open source ISA from a 100% clean slate, using the world's academic computer engineering brains (and corporations that wanted to be free of Arm licensing) ... and a lot of the subtext was initially around ISA purity.
Look at the ISA today, specifically the RISC-V extensions that have been ratified. It has a soup of wacky opcodes to optimize corner cases, and obscure vendor specific extensions that are absolutely CISC-y (examine T-Head's additions if you don't believe me!).
Ultimately the combination of ISA, implementation (the CPU), and compiler struggle to provide optimal solutions for the majority of applications. This inevitably leads to a complex instruction set computer. Put enough engineers on the optimization problem and that's what happens. It is not a good or bad thing, it just IS.
- ip26 3y agothere is an iron triangle operating on ISA design. I would propose the vertexes are complexity, performance, and memory model. The ideal ISA has high performance, a strong memory model, and a simple instruction set, but it cannot exist.
- thesz 3y agoDefine high performance. Also, define strong memory model. This is the first time I hear that memory model can be strong. And, finally, define what is "simple" in instruction set.
- sweetjuly 3y agoStrong and weak as terms to describe memory models is very common, the standard RISC-V memory model is called "weak memory ordering" after all :)
- thesz 3y agoStrong and weak are not properties of memory model, but memory access ordering in memory model. They are common in description of memory access orderings, but not memory model itself.
- deleted 3y ago[deleted]
- snvzz 3y agoStrong memory ordering is convenient for the programmer. But it is a no-go for SMP scalability. That's why most architectures today use weak ordering. x86 is alone and a dinosaur.
- ip26 3y agoI’m curious to hear what problems are you thinking of in particular that make it no-go? Strong model has challenges, but I am not aware of any total showstoppers. x86 has also illustrated the triangle, garnering some weakly ordered benefits with examples like avx512 and enhanced rep movsb. The interesting thing is both solutions (weak ordering, special instructions) have been largely left to the compiler to manage, so it could become a question of which the compiler is better able to leverage. For example, if people are comfortable programming MP code in C on a strong memory model but reach for python on a weak memory model, things could shake out differently than expected.
- sweetjuly 3y agoMemory ordering tends not to play much into the design issues of xMP systems. As long as you have a coherent and properly scalable cache and NoC, the actual memory ordering of the local processor is irrelevant to the total performance of the system since the LSU and L1 cache are (typically) responsible from providing ordering. The reason why most architectures use weaker memory ordering rules is that it allows you to more easily build faster individual cores as it makes it much easier to extract memory parallelism.
- saagarjha 3y ago
- CalChris 3y agoTo be fair, RISC-V has a small base, RV64I in the 64-bit case. These bases are small, reduced and frozen. But after that, yes, the extensions get whacky. L is Decimal Floating Point, still marked Open. I'm not sure what's reduced about that. But extensions are optional. About the history of RISC, the basic idea dates to Seymour Cray's 1964 CDC 6600. I don't think Berkeley gives Cray enough credit.
- dvwobuq 3y agoPatterson and Waterman detail exactly what they we’re thinking during the design of RISCV in the RISCV Reader and Cray is mentioned in multiple places. https://www.goodreads.com/en/book/show/36604301 https://www.goodreads.com/en/book/show/36604301
- CalChris 3y agoCray gets mentioned in the Reader 3 times, the simplicity quote, the pioneer quote and the timeline comparison with the Iliac-4 (p. 80). Waterman's thesis does actually give some credit: The CDC 6600 [95] and Cray-1 [82] ISAs, in many respects the precursors to RISC, each had two lengths of instruction, albeit without the redundancy property of the Stretch. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-1.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-...
- hajile 3y agoIEEE 754 specifies not only floating point, but decimal floating point too. You actually find hardware implementations on some systems (notably IBM POWER). Better to reserve and not finish that to be unprepared. In any case, decimal floating point is better for MOST programs/programmers and is only inferior in being harder to implement (imo).
- dehrmann 3y agoIt's the story of every framework. It starts out clean and minimal, then gets features added on as users demand more for more and more specific uses.
- codedokode 3y agoThis "feature hell" is often seen in open source projects, when users add dubious features that nobody except them needs, and as a result after many years the program has hundreds of CLI flags and settings and becomes too complex. See openvpn as an example.
- 0xr0kk3r 3y agoIt is NOT feature hell. That is an absolutist/purist standpoint that only gets in the way in my experience. Products evolve to fit their market, which is literally why products are made. Complexity needs to be managed, not labelled and shunned because it is "too hard" or "ugly". That is life. Learn that early and it will help.
- throwaway2037 3y agoSee every web browser ever made. Also: Every GUI toolkit ever made. Also: IDEs. Eventually, someone is complaining about "bloat". Please: Give features, then I'll deal with the bloat.
- codedokode 3y agoRISC-V is copying wrong decisions made tens years ago. Against any common sense it doesn't trap on overflow on arithmetic operations, and silently wraps number over, producing incorrect result. Furthermore, it does not provide an overflow flag (or any alternative) so it is difficult to make addition of 256-bit numbers for example.
- wbl 3y agoIt doesn't trap because trapping means you need to track the possibility of a branch at every single arithmetic operation. It doesn't have a flag so flag renaming isn't needed: you can get the overflow from a CMP instruction and macroop fusion should just work.
- codedokode 3y ago> you need to track the possibility of a branch at every single arithmetic operation Every memory access can cause a trap, but CPUs seem to have no problem about it. The branch is very unlikely and can always be predicted as "not taken".
- twbarr 3y agoHell, with non-maskable interrupts, any instruction can cause a trap!
- meithecatte 3y agoNot even that - instruction fetch can cause a page fault. When an NMI happens,the CPU still has the choice of when to service it. If it needs to flush the pipeline, it might as well retire the instructions up to the first store.
- hajile 3y agoManaging memory coherency is probably the single hardest part to design in any given CPU. Why add even more hard things (especially if they can interact and add even more complexity on top)? Get rid of what complexity you can then deal with the rest that you must have.
- snvzz 3y agoThe usual RISC-V FUD points. It gets boring. >It has a soup of wacky opcodes to optimize corner cases OK, go ahead and name one (1) such opcode. I'll wait. >obscure vendor specific extensions that are absolutely CISC-y (examine T-Head's additions if you don't believe me!). Yes, these extensions are harmful, and that's why they're obscure and vendor-specific. RISC-V considers pros and cons, evaluates across use cases, and weights everything when considering whether to accept something into the standard specs. Simplicity itself is valuable; that is at the core of RISC. So the default is to reject. A strong argument needs to be made to justify adding anything.
- codedokode 3y agoRISC-V ISA is very inconsistent. For example, for addition with checked overflow the spec says that there is no need for such instruction as it can be implemented "cheaply" in four instructions. But at the same time they have fused multiply-add which is only needed for matrix multiplication (i.e. only for scientific software), which is difficult to implement (it needs to read 3 registers at once), and which can be easily replaced with two separate instructions.
- brucehoult 3y agoFused floating point multiply-add with a single rounding from the infinite-precision answer is required by the IEEE 754-2008 floating point standard. You don't get a choice in the matter. > can be easily replaced with two separate instructions It can't. You will get different answers. RISC-V allows you to choose a CPU without floating point instructions. But if you choose to have an FPU then you get multipy-add. Yes, it needs to read three registers, which is expensive. It is also the most common instruction in any floating point calculation, so that expensive three port register file gets used constantly. Checking overflow for addition on the other hand is something that is very seldom used (on any CPU). On RISC-V you need four instructions only if the operands are full register size and you don't know anything about either operand. If you know the sign of one operand then the cost reduces to one extra instruction.
- 3y ago