14 ms·
The Genius of RISC-V Microprocessors
- childintime 6y agoI've seen quite a few presentations, but never have I seen such a direct approach to showcasing the merit of RISCV. Well done.
- artemonster 6y agoI am really curious about the content of that article. I work closely with different embedded CPU architectures and in most of our multi-expert evalutions of RISC-V (from different suppliers) it could not compete with commercial offerings (avoiding names).
- artemonster 6y agoAllright, I've used the incognito "trick" to gain access to that article and I must say that this article is an utter crap written by a person that never seen why and how processors are chosen to be integrated in projects. Comes off as a piece written by a paid pseudo-evangelist. Not going to say that the content is somehow wrong (its not), but its totally irrelevant to the sucess of particular architectures or ISAs in general. jeez.
- remexre 6y ago> Comes off as a piece written by a paid pseudo-evangelist. Yeah, I feel like Medium somehow manages to attract that sort of writing. Bizarrely, I've seen this with some authors who write on both Medium and elsewhere -- their Medium content seems weird in the same way. I wonder if it's just that after enough of that content is there, it's the norm, or whether something about the UI makes it feel more "just jot down your thoughts," while a blogpost makes the same authors draft, research, revise, etc., but it's uncanny.
- webmobdev 6y agoCould you atleast elaborate with specifics?
- ksec 6y agoThe author has been writing about RISC-V with relation to Apple M1 and basically fanboying about it. It is basically the same as some guy coming in and say Rust will overtake C and C++. And yet the article got interest, since it align with the general public and main stream media view of RSIC-V being the rising star. It is free. It must be better. etc. I could have repeat most of his point with OpenPOWER. ( microWatts [1] ) And for many application there are lot of reason why OpenPOWER are much better than RISC-V. ( Rather unfortunate IBM is loathed by lots of people in the industry ) [1] https://github.com/antonblanchard/microwatt https://github.com/antonblanchard/microwatt
- kps 6y agoI got a similar impression. Discussing addressing modes, > This is probably a more faithful representation of what happens in the x86 code as well. I doubt you can multiply with anything but multiples of 2, since multiplication is a fairly complex operation. For an article comparing instruction sets, ‘I dunno and didn't care enough to spend 30 seconds Googling’ does not inspire confidence.
- Someone 6y ago“since it align with the general public and main stream media view of RSIC-V being the rising star” I don’t think “the general public” even knows what “RISC-V” means. It’s more some specific circles where this is going on. The good thing for those writing such articles is that it’s hard to refute them, as they only discuss the instruction set, not particular designs, and few, if any, people can meaningfully judge how true various claims “this thing my/your favorite CPU does is worth/not worth the transistors. You’ll see it once advanced designs of my favorite CPU exist” are (even more so because feature A may be worth it for a CPU that also does B, but doesn’t do C, and that has a given power budget)
- socialdemocrat 6y agoA number of actors in the industry will disagree with you. Nvidia after careful analysis decided RISC-V was the superior replacement for their general purpose Falcon Chip: https://riscv.org/wp-content/uploads/2017/05/Tue1345pm-NVIDIA-Sijstermans.pdf https://riscv.org/wp-content/uploads/2017/05/Tue1345pm-NVIDI... Dave Ditzel, who is no dummy saw RISC-V as the better choice for the machine learning accelerator Esperanto Technologies is building: https://www.eejournal.com/article/another-risc-v-religious-conversion/ https://www.eejournal.com/article/another-risc-v-religious-c... There are numerous research articles and examples online of companies deciding on RISC-V and their reasons for it. Unless I misunderstand I cannot see how OpenPower matches RISC-V at all. It is a large ISA, which means you don't have the option of making e.g. small specialized co-processors based on the ISA. Nor can you make simple CPUs for the microcontroller market. The RISC-V BOOM has half the silicon area requirement of a comparable ARM Cortex CPU, is OpenPower based chips able to match that? If you already have a large instruction-set I don't quite see the value in an extendable ISA. You cannot keep the ISA lean as micro-architecture best practices change.
- WillSlim95 6y agoInteresting point, it depends what were the parameters. When it come to performance/cost compared to ARM processors RISC V was seen as a better choice by most semiconductor companies. Maybe in your experience the criteria might have been different
- klelatti 6y ago> When it come to performance/cost compared to ARM processors RISC V was seen as a better choice by most semiconductor companies. Can you give some evidence to back this assertion up?
- WillSlim95 6y agoSorry internal numbers at two FPGA companies who were benchmarking which hard-core to choose
- klelatti 6y agoInteresting - thanks!
- miohtama 6y agoOn purely commercial terms, RISC-V may not compete. But as already stated in other comments, CPUs and chips are getting political.
- CJefferson 6y agoPoint 2 claims that RISC-V is the dominant architecture used for teaching. The link provides no evidence for that. I know lots of unis teaching ARM, and none teaching RISC-V. Is there any evidence that RISC-V is the dominant architecture for teaching?
- WillSlim95 6y agoAlmost all universities I know of have shifted to RISC V. UC Berkely, MIT any of the UC's,UW, even Harvey Mudd College. So it is not an unreasonable assertion.
- saagarjha 6y agoMy UC (Santa Barbara) used MIPS in its computer architecture classes.
- CJefferson 6y agoFrom your list, this could be a US/UK separation.
- WillSlim95 6y agoI could give Indian universities too.
- the_duke 6y ago
- andy_ppp 6y agoI won’t sign up for medium to view this (let alone download another app!), does anyone have a different link?
- artemonster 6y agoCan we, please, make a rule that you cannot post paywalled links- or, alternatively, should provide a text copy in comments? People upvote submissions without reading, comment without reading, etc. --- Also, I am very skeptical about the content, jugding just by the clickbaity title alone.
- InvaderFizz 6y agoSince I do most of my reading on my phone, I find this iOS shortcut someone posted on HN a few months back of great use for bypassing almost every paywall I have come across. I extended it to also work on Medium by using Twitter as the referrer. Shortcut: https://www.icloud.com/shortcuts/95928cdef80a46d892d05a58a88ca9da https://www.icloud.com/shortcuts/95928cdef80a46d892d05a58a88...
- cesarb 6y agoThis probably happens because these links aren't paywalled for everyone. I, for instance, have never encountered any paywall on any medium.com article; whether that is because I have my browser configured to discard all cookies whenever the browser is closed (and I close my browser very often), or because I have it configured to disable Javascript by default unless the site is whitelisted (and medium.com is not on the whitelist), or something else, I don't know.
- the_duke 6y agoIt's both, actually. The Medium popup only comes after visiting a few articles, and it is shown with JS.
- ThrowawayR2 6y agoThe FAQ already says paywalled links are allowed as long as there's a workaround.
- lmm 6y agoIt does, but that was a bad decision that has made HN worse; it's time to revisit it.
- cesarb 6y agoI find it interesting that, in one aspect, ARM went into the opposite direction with its newer 64-bit ISA. Like with RISC-V, the designers of the 64-bit ARM ISA "knew about instruction compression and macro-ops fusion when they began designing their ISA" (32-bit ARM already had the alternative compressed ISAs Thumb/Thumb2/ThumbEE); however, they chose to use fixed-size 32-bit instructions without any compressed format. I suspect that they did it expecting that, once compatibility with the 32-bit ARM ISAs is removed on newer processors, the fixed-size instructions would allow for very wide decoders, like we've seen with Apple M1 (which can decode 8 instructions in parallel). It remains to be seen whether the RISC-V choice (the first two bits of every instruction are enough to determine the instruction length) will allow for a similarly wide decoder.
- cogman10 6y agoI'd imagine it would since they limit the number of possible instruction lengths. The hard thing about x86 is the fact that instructions can by anywhere from 8 bits->256 bits in length (in 8 bit increments). So there's really no way to know if you are loading up an x86 instruction or you are splitting an instruction. The fact that risc-v only supports 32,64, or 128bit instructions means that you don't have to go through a lot of extra effort to determine where instructions start or end.
- jecel 6y agoNote that RISC-V can have 32, 64 or 128 bit wide registers. The instruction length can be any multiple of 16 bits, though the base instructions are all 32 bits and the C extension adds 16 bit instructions and other lengths have not yet been used. This diagram shows how instructions up to 192 bits long can be encoded: https://www.embarcados.com.br/wp-content/uploads/2017/05/RISCV_length.jpg https://www.embarcados.com.br/wp-content/uploads/2017/05/RIS... It is a very simple circuit that can take the bottom 16 bits of any RISC-V instruction and tell you exactly how long it is, unlike the x86 where you need a sequence of steps.
- deleted 6y ago[deleted]
- wintorez 6y agoI always thought it was insane that the CPUs had instructions specific to a particular application in a particular operating system embedded in them. I think the close we get to the metal, the more abstract and general purpose things should get. For example, things like "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" should not exist at all.
- gameswithgo 6y agoif there is computation people are doing a lot, and a hardware instruction can make it faster, i will take it. so in a sense i agree you, but i only think that because i think javascript shouldn’t exist!
- henrikeh 6y agohttps://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/armv8-a-architecture-2016-additions https://community.arm.com/developer/ip-products/processors/b... > Javascript uses the double-precision floating-point format for all numbers. However, it needs to convert this common number format to 32-bit integers in order to perform bit-wise operations. Conversions from double-precision float to integer, as well as the need to check if the number converted really was an integer, are therefore relatively common occurrences. > Armv8.3-A adds instructions that convert a double-precision floating-point number to a signed 32-bit integer with round towards zero. Where the integer result is outside the range of a signed 32-bit integer (DP float supports integer precision up to 53 bits), the value stored as the result is the integer conversion modulo 2^32, taking the same sign as the input float. The semantics of numbers in JavaScript behave in a specific way. Since we are talking about numbers, it hardly gets more low-level and thus it makes good sense to design ALU operations targeting common numerical operations.
- boibombeiro 6y agoThe hardware overhead to implement this particular instructions is likely very small. The floating operation themselves are done in fixed point with large registers. This instructions tells the cpu to bypass part of the circuit. The javascript thing is just branding to make devs aware of the application of the instructions. Ironically, this actually gives more control of the hardware rather than increase abstraction.
- rahimiali 6y agoAll five reasoned mentioned apply to the MIPS ISA as well, no?
- klelatti 6y ago> However unlike the ARM, MIPS and x86 designers, RISC-V designers knew about instruction compression and macro-ops fusion when they began designing their ISA. Since ARM64 was announced in 2011 this is plainly false for 64 bit ARM. (And there is similar confusion between 32 and 64 bit ARM throughout the article).
- CalChris 6y agoInstruction compression dates at least to MIPS16, 1996 [1]. Macro-op fusion dates at least to the Pentium M, to 2003 [2]. These are old ideas. [1] https://en.wikipedia.org/wiki/MIPS_architecture https://en.wikipedia.org/wiki/MIPS_architecture [2] https://www.agner.org/optimize/microarchitecture.pdf https://www.agner.org/optimize/microarchitecture.pdf
- klelatti 6y agoIndeed and ARM7TDMI with Thumb was released in 1994 so clearly Arm had forgotten about it by 2011!
- fierarul 6y agoI don't understand the hype for RISC-V at all. It's an instruction set that would... just require a new backend for clang/gcc/Java and mean nothing to me unless somebody makes something that just obliterates a Ryzen. Why should developers care? We barely have a decent ARM ecosystem after years of ARM routers and Raspberry Pi. Now we are supposed to be enthusiastic we will do that yet again for RISC-V? Is it because it's somehow more open? But ARM wasn't that closed afaik - lost of folks produced it. And Sun Microsystems open sourced a 64 thread CPU, the OpenSparc and nothing happened. So, in a nutshell, why?
- 0xTJ 6y agoI think that's the wrong question to ask. Aside from those writing kernels, compilers, JITs, etc., developers don't need to care, that's the point of programming languages and compilers. Throw a toolchain at a developer and tell them to do it and they can do it. Comparing RISC-V to OpenSPARC is comparing apples to oranges. One is an ISA, the other is a hardware project. What do you mean by "We barely have a decent ARM ecosystem". Are you talking about the tools to build for those processors? Or the tools to build new ones of those processors? Or the actual chips that are available? I'm basically always within 10m of at least a half dozen ARM processors, and a handful of 8051s. At worst, RISC-V could be equivalent to ARM, without many of the parts that suck about it.
- fierarul 6y agoAre we talking about RISC-V as an abstract idea, the same way we would talk about the benefits of functional or object oriented programming here? Or is the end goal to have hardware in stores that people can buy? Wasn't SPARC a RISC architecture? (Wikipedia says so, but I'm no expert). > What do you mean by "We barely have a decent ARM ecosystem". Are you talking about the tools to build for those processors? Or the tools to build new ones of those processors? Or the actual chips that are available? I remember the early OpenWRT / RPi days when many packages weren't even compiling for ARM. Now I think we are in a much better shape. The chips were available, but the software ecosystem was way behind. > At worst, RISC-V could be equivalent to ARM, without many of the parts that suck about it. What I do know about ARM sucking is that the whole board design makes each product need a customer kernel more or less. Which is why we still don't have a "Linux for your phones". What I've read about RISC is that it's going to be roughly the same: encourage a lot of co-processors which mean custom boards to me and probably custom kernels.
- CalChris 6y agoCompressed Instructions and Macro-Operation Fusion It's strange to put these two together as RISC-V's killer feature. First, they are not new; they go back more than a decade. But more to the point, they are at odds. Instruction compression says that DRAM+cache are a scarce resource. Macro-op fusion says don't worry about those big instructions, we'll combine them after decode. Which is it? BTW, micro-op fusion is not free. It has to search the instruction stream for possible matches.
- pjc50 6y agoObviously the plan is to take a short string of bytes, expand it to a longer one, and then identify a single instruction that those bytes map to. This is much cleverer than just mapping the original string of bytes directly to an instruction. /s
- socialdemocrat 6y agoWith compression you avoid the cost of having multiple instructions to fuse. I don't see what that isn't a good combination. With two instructions compressed into one and then fused into one micro-op you get both less pressure on cache while still getting high throughput in the micro-op execution pipeline. The "killer feature" here is about designing the ISA around the fact that one knows macro-op fusion and compression exists. E.g. x86 ISA was designed without any thought to the possible existence of macro-o fusion. ARM seems to also have mostly ignored the existence of this in high end processors when designing their ISA. Innovation is really just about using existing stuff in clever new ways. Btw Macro-op fusion and micro-op fusion are not the same thing.
- CalChris 6y agoDoh. Yes, I fat fingered micro-op for macro-op. With compression you avoid the cost of having multiple instructions to fuse. I don't understand this. RVC is only a 16b 'abbreviation' for a subset of RISCV instructions. It's ultimately the same instruction. Also, RVC is an extension; it isn't base and Andrew Waterman's thesis [1] doesn't even mention macro-op fusion. FWIW, the A72 uses macro-op fusion [2]. Neither architecture ruled it out, but then neither architecture was anticipating it. It's just a microarchitectural optimization. No, the x86 (1978) certainly wasn't designed with macro-op fusion in mind. Instead, macro-op fusion (2000) was developed by Intel to improve x86 performance [3]. [1] https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p... [2] https://techreport.com/review/28189/inside-arms-cortex-a72-microarchitecture/ https://techreport.com/review/28189/inside-arms-cortex-a72-m... [3] https://patents.google.com/patent/US6675376 https://patents.google.com/patent/US6675376
- torginus 6y agoI still feel that the criticisms in this article still stand: https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99... The chief and most difficult to address among which is the lack of advanced addressing modes ('lea' in x86) means that address generation for array access requires 3 more instructions. The writer suggests that Macro-OP fusion will pick up the slack in this case, however it has been pointed out that this level of fusion (tons of instructions, which can have various read and write locations) is very complex to do in HW and is typically not done even in high-end commercial CPUs today.
- klelatti 6y ago> Highly unconstrained extensibility. While this is a goal of RISC-V, it is also a recipe for a fragmented, incompatible ecosystem and will have to be managed with extreme care. This seems to me to be under-debated. If / when RISC-V gets more adoption what is there to stop vendors trying to 'win' by adding proprietary extensions that fragment the ecosystem.
- remexre 6y agoConvincing the Chrome (or Firefox, Mathematica, MATLAB, $distro's emacs builds, ...) team to switch to their proprietary gcc/LLVM fork that supports the extensions, I assume. Proprietary extensions work better in the embedded space, where the status quo is a proprietary toolchain; I doubt you'd be able to get a ton of buy-in from application distributors before you have market dominance.
- klelatti 6y agoFair challenge. I fear though that once a firm gets to say Qualcomm or Apple size in the market then they have the scale to continue to maintain their own fork and develop their own apps with that (e.g. Apple could easily do with Safari etc.)
- nickik 6y agoIts not 'under-debated' it been literally debated in every single forum that ever had a post about RISC-V. Its literally the most debated thing. The reason its not very likely to happen is because we have a gigantic open source ecosystem that is unlikely to for free adopt your extension unless you pay them to do it. At the end of the day, you simply can't force hardware designer into some standard unless your ISA is proprietary.
- monksy 6y agoWhat does RISC-V have to do with "Read the rest of this story with a free account. You’ll also discover more fresh thinking personalized to your interests and can follow your favorite authors, publications, and topics." I'm not signing up with an account to read this article.
- Shared404 6y agoI see this comment on every single medium article. Just open it in private mode, or use noscript, or block cookies.
- siscia 6y agoAm I the only one who can't read anymore the medium articles?
- yangff 6y ago%gp
- indolering 6y ago> Keeping code small is advantageous to performance because it makes it easier to keep the code you are running inside high speed CPU cache. It's not called the Iron Law of Performance[0] for nothing: Time/Program = Instructions/Program * Cycles/Instruction * Time/Cycle [0]: https://compas.cs.stonybrook.edu/~nhonarmand/courses/sp15/cse502/slides/02-review.pdf https://compas.cs.stonybrook.edu/~nhonarmand/courses/sp15/cs...
- ur-whale 6y agohttps://archive.is/BPKlA https://archive.is/BPKlA
- bionhoward 6y agoIt would be awesome if folks would make a collective decision to turn off the Medium paywall on their articles there, or simply make a markdown blog with NextJS and Vercel for free.