Arm vs RISC V- What You Need to Know 

Indeed - while Gary is correct that someone still must build these designs, and building it especially large scale costs a lot of money, this cost can be greatly reduced by IP reuse. Software isn't exactly cheap to make either. Every CPU still needs an I/O die, and this is no different from every other I/O die on the market. Every CPU still needs a cache memory, FPU, and so on. These have existed for years, expired patents tell us how to build these already and as efficiently as possible. 90% of a CPU chip is the same components, so if these 90% were in the same standardized modular package that will eventually allow for lower costs. Think chiplets but at chip level. Think a CPU but sacrifice FPUs for hardware-accelerated packet switching. And so on. Lots of fun stuff that could be done here. :)

Companies that design cores still patent those designs. While the architecture is open like Linux, the core designs and innovations that make those cores more useful and efficient can still be patented. And since the architecture is open, this will likely lead to multiple companies designing multiple cores using a variety of source codes that are controlled by different companies. This means that a unique innovation that could benefit all RISC V chips will only be available to whichever company designed it. So if one company designed a more efficient source code and another company designs a more powerful core, you can’t get a RISC V system that uses both the powerful core and efficient code because they’re property of two competing companies. This will lead to a fracturing of the technology with no single controlling all the best technologies. Instead the best innovations will be scattered among multiple designs, preventing any of them from reaching peak performance. This is not a limitation of ARM who can implement all innovations. This is why Intel is trying to buy up RISC V engineering companies, so they can control the best designs of these chips.

if they would make an atmega pin compatible risc-V with faster speed and more memory it could really beat atmel on the arduino space in a second because even if its slow and obsolete many are still using it because thats what the arduinos come with and thats the platform the software was made on. It would be just a matter of making the chip and adding it to the arduino libraries. Just give me 300mhz and 4mb of ram and im sold.

@@laharl2k the new ESP32 C3 is using RISC-V

@@devdylan6152 Make that into an arduino uno and arduino mega form factor and it will sell, otherwise we are still in the same situation where everything people use ws made for those so they keep using those instead, even if there are better alternatives.

There's not really as much to say there. AArch64 has some weird instructions RV64 doesn't, and some design differences, but it's not that crazy. RV32 vs 32-bit ARM is a bit more exciting because 32-bit ARM is extremely quirky.

Well you have all the specifications out there. Is hard stuff to digest but cool if yo really like to understand computer architecture.

Agree. I wonder how much the differences in ISA would contribute to differences in performance. Even the ancient x86 CISC instruction set has been accelerated under the hood by Intel's and AMD's trickery.

@@gast128 The answer to that question is "it's complicated". Chris Celio did a talk on this while he was working in the BOOM RISC-V out of order core. Sort of on this, really. It was about stacking up ISAs and comparing them. Thing is, the ISA can impact how many instructions your program is, but it can't determine how fast they run. That's the province of the microarchitecture and the process. And if there is one thing x86 has proven it's that you can make almost any ISA run fast. However, an ISA can make a microarchitect's job easy or hard. x86 makes the microarchitect's job much much harder than it needs to be, and not really to any gain for programs: it's just that every x86 CPU needs to implement 50 years of legacy. RISC-V makes the microarchitect's job much easier, and the chip real estate you don't have to use on making x86 not terrible can be utilized in other ways. Of course, Intel and AMD still have some of the best microarchitects in the world, exceptional fab technology at their disposal, and enough guaranteed customers to bankroll the design, testing, and production of chips (and the upfront cost of producing chips, especially on the very small processes that Intel and AMD are using, is very high). That's why x86 is still beating everyone else's performance. Of course, none of this actually matters if your compiler sucks at utilizing your ISA, or you blow your instruction or data cache, or any number of other things. It turns out even if your program is CPU-bound the microarchitecture isn't always the bottleneck. My credentials on this subject are... zero. I don't have any. Don't trust me.

@@THB192 More quirky than X86_X64?

WoW . i'm from iran sir , is there any opportunity to understand RISC-V arch for me ? you swimming on the technology :) , if that's impossible we will find out the way from scratch . a nation under sanction can do anything finally .

@@spguy7559 Hi, there is an online course from UC Berkeley called CS61C. They teach RISC-V but I dont know why you would need to learn it.

I'm going through teaching myself how to design circuits with the eventual goal of implementing my own MC68060-compatible core, not in design, but at an instruction level. Then after that, I'm going for synthesizing OpenSPARC T2 on an FPGA, with an eventual goal of building an OpenSPARC T2 1U 19" rack server. And then get the missing illumos support back in, which shouldn't be too difficult considering it comes from the SPARC platform. And then get SmartOS to build on it, once illumos support is upstreamed.

@@AnnatarTheMaia - That sounds like a fun project!

@@thomasruwart1722 I'm having so much fun learning how to design electronic circuits, I completely "found myself" in it.

big deal for A.I.

ARM SVE is very similar to RISC-V V extension. Both are designed to deal with user vectors of any length (up to millions or billions of elements) using CPUs with vector registers of varying length (128 to 4096 bits for SVE, 32 to 2^32 bits for RISC-V) using exactly the same binary program instructions to give optimal results on any machine.

@@BruceHoult Sorry, but not at all. RISC-V RVV vector extensions when contrasted with ARM SVEx follows a profoundly different strategy. Another problem with ARM vs RV is that the former is simply large (+1000 vs a mere 48 ins in RV), RVV vector instr. fit on one single page and have a pretty simple syntax (ex. a simple vector load ins: VLD v0, x10). Yep, length is pretty similar, but ARM FP registers overlaps in the same register file/memory. RVV does not work like ARM, as long as holds in a separate register file, for example. ARM vector complexity is above RVV. And so on

@@paco3447 complexity is not a good thing in itself. Usability and effectiveness are just as important. I've been using real, production, RISC-V vector hardware (Alibaba C906 core) for several months now and it's very nice -- older 0.7.1 spec, but the differences between that and 1.0rc1 are trivial compared to the differences to SVE, let alone anything else.

@@BruceHoult Yep. But you now that both follows different strategies in many aspects of V instructions. For example, dealing with variable length vectors (more simpler in favour of RISC-V). Or vector register file partitioning. Yes, both have same amount of vect. regist. but R-V allows disable those regs and give it back to memory. Differences when calculating max vector length, etc. I'm not saying ARM is bad but both have quite different approaches and personally I believe RISC-V is more simpler than ARM.

I appreciate that!

Popular is indeed up to the buyers that is the whole point. 🤦‍♂️

I'm thinking RISC-V is more like POSIX or the Single Unix Specification or something like that. Linux is just one "manufacturer" following this standard, with also the various *BSDs, Darwin, Windows with the appropriate subsystem, all the proprietary versions from Sun, HP, SGI etc. A mix of closed commercial and open source versions.

@@BruceHoult If RISC-V is like POSIX, it is doomed to irrelevance. POSIX compliance looks like compatibility on paper, but that's all it's "good" for. To me it seems like an ISA is a language in which software is written, much as C is. An operating system is a different kind of beast.

My pleasure!

I think I said popular and prevalent.

As if the MCU were responsible for the price difference! 🤣

Glad it was helpful!

It got cancelled.

Oh no!!! I'm rubbing all lamps looking for a genie to wish on now.

Furthermore, I've resolved to pull together some QEMU magic to get SOME OS running locally on RISC-V even if that OS is some minimal screen text loop. Oh hey! It looks like Debian has been ported to RISC-V. Here's hoping it can do with entirely virtualized devices. It might involve some annoying games but now i'm determined.

I have a video about emulating RISC-V on a Pi using qemu.

They implement the Intel memory model as a massive performance hack.

yessss i'd love a video on this

@@destrierofdark_ does this mean that the Intel memory model when used executing x86-64 code works concurrently with the ARM load/store model when executing AArch64 code? Seems like a pretty sweet hack if they managed to do it with minimal silicon.

@@davidhart1674 I'd imagine some very specific ASIC to convert it, or whatever the load/store of the ARM is doing is adapted to Intel. Either approach works, and the hack obviously performs amazing, and considering it's still that low of a wattage on the M1, that should tell you something.

I'm in love reading all of this technical discussion, thank you very much guys

I agree. I still use lisp. I like legacy systems.

As one of three authors of multiple process lisp systems, I ported to 4 different multiple cpu machines, that cost $100,000+, and now a $5 PI has two, and $10 chips have 4, and we still can't program them effectively in parallel after 30 years. I am so tempted to bring back my NICL system, yet nobody would care.

@@murraymadness4674 I hear you. I did my initial work on Symbolics machines and finally ported over to Allegro Lisp on Sparcs.

@@madmotorcyclist At my last job we had Sparc Stations everywhere. My favorite part? The bios written in Forth.

I remember visiting my CS212 prof for office hours in the early 90’s and spent the whole time asking him about his Symbolics workstation next to him that ran LISP natively

Well that's what the Chinese always do.

Still 3 years behind. And it isn't in any actual products.

Haiku is a small project with very slow progress. I installed the x86 version of Haiku beta under VMware months ago. Though it is a very old OS i.e. BeOS, it is surprisingly usable.

That quote was way outdated before that movie even came out. RISC had already changed the landscape significantly. Why would you use such a silly movie to make a serious quote? Why would that make you buy a PA machine? It’s not like they were useful for most people at the time, especially since you needed HP-UX to do anything useful (Lites wouldn’t show up until 96 and BSD after) - are you saying you had access to THAT too along with a dev toolchain?

@@BlownMacTruck First server I brought in the early 2000s was an A180c that had HP-UX on it. I then installed Linux on it. Debian HPPA. Had that as my main email and web server till 2008 then went to an A500 and now using a RP3440. I’ve been helping with the port to this day. Still running the latest kernel etc. I like the fact that it’s not your standard architecture and sometimes you have to build your own security updates but it still does it’s work with less issues than the later AMD64 machines that I use. Hackers was a movie that got me and a lot of other people into more serious IT projects, it’s not the best movie out there but was good enough to make me interested.

Complete misunderstanding. ARM does not manufacture chips. US government is putting the squeeze on manufacturing. No matter what instruction set you use what design your chip is on, they can ban you from manufacturing the chip.

That would be interesting for the real nerds, but since MIPS basically died, I don't think it would be that interesting to a wider audience.

@@GaryExplains Yeah, I can understand that. I was just thinking that perhaps it would be a useful way to help predict if RV will become a direct competitor to ARM one day, or if they'll go the same way as MIPS as there just isn't the same degree of interest in RV. My instincts tell me that the industry usually works best when there are two major competitors in each space, and I think that for now x86 & ARM have all of the attention from big industry players and RV is just used by a few companies looking to explore, but without too much commitment from them and so will probably disappear before x86 dies off.

@@SmilerOnline Fun fact: MIPS is now a RISC-V processor designer - www.eejournal.com/article/wait-what-mips-becomes-risc-v/

I actually think MIPS would be really interesting to hear about. MIPS powered the PS1, PS2, and Nintendo64. A lot of people alive played those consoles.

Thanks!

That would be interesting for the real nerds, but since Itanium is basically died, I don't think it would be that interesting to a wider audience.

Itanium use a very long word ops and risc is smaller , itanium is still used on Hp mainframes.

@@GaryExplains The issue would not be whether Itanium is interesting, but whether hearing about how Itanium works would be interesting. I think it is.

Indeed, the RISC-V ISA is free and open with a permissive license for use by anyone in all types of implementations. Designers are free to develop proprietary or open source implementations. Only the ISA is free and open, not the implementations.

That would be interesting, but I think that it is too niche and wouldn't be that popular.

"the other ISA"???

@@GaryExplains Sparc and Power are still going. I’m not sure beyond that, though I hear there’s some strange dev work going on in China.

like how huawei was kicked out of the whole arm ecosystem

@@obstinatejack I'll have to look that up. What comes to mind is the linux on mac project, maybe that's right but it may just be a similar name.

@@obstinatejack not true. nothing like that. huawei can still use ARM instruction set. they cannot find companies to manufacture their ARM chips in advanced process technology only. in fact huawei will sell new phones early next year using Qualcomm SoCs. those Qualcomm SoCs are ARM chips

Agree. It is good to have a open instruction sets RISC-V. There will be leverage against ARM domination.

Thanks for the brief lesson on open source licenses 🤦‍♂️the point is that only the ISA is open, not the designs.

​@@GaryExplains To clarify, the designs you refer to are the packaging of the processor (physical manufacturing) and the support hardware (motherboard, for lack of a better word). And you are correct inasmuch as the "designs" are not available as part of the open source RISC-V project, however, there are projects that are open source that do provide everything you need to create a working RISC-V processor. This obviously excludes everything else that goes into a SOC, but we are comparing two processor architectures, RISC-V to ARM, and while RISC-V certainly has closed source solutions, there are also purely open source solutions available too. I don't mean to be pedantic, but anyone who is interested in RISC-V Vs. Arm would need to understand that both open and closed solutions exist.

🤦‍♂️

No, because if Intel does buy its way into RISC-V it will still keep developing and selling x86. Intel will likely use a business strategy that means that their RISC-V and x86 businesses won't overlap.

In future... It will

@Coz Fi looks like someone didn't get the connection: - both RISC V and BSD originate at berkley - both RISC V and BSD don't require derivatives to release the source code

@@fuseteam I gotcha 😉

@@davidca96 nice :3

Indeed. In powerful processors, the RISC/CISC divide is really largely nonexistent, as RISC processors gained many more instructions, and CISC processors started breaking down “complex” instructions into simpler ones under the hood before sending them for execution.

No.

I'm not sure X86 has literally thounsands of pages of specification, tons and tons of seemingly useless bloated instructions, enormous amounts of legacy stuff, etc etc. ARM is still much simpler, being much less bloated, but it's still incredibly complicated. I think it's probably not such a RISC architecture anymore. I don't know the details of each processor, so I can't give you a properly educated answer.

From wiki "Most RISC architectures have fixed-length instructions (commonly 32 bits) and a simple encoding, which simplifies fetch, decode, and issue logic considerably." Basically, instructions are fixed length, significantly simplifying design, and thus increasing efficiency. Some instructions on CISC CPUs are multiple instructions on RISC CPUs, but the overall efficiency is much greater. CISC CPUs these days in practice take on this mentality. Instructions are broken up into smaller chunks, to allow higher clock speeds, and pipelined, multiple instructions being processed at once (not multicore, this is within the core), drawback of course is code branches, making accurate branch prediction extremely important. So RISC works on smaller instructions by design, CISC has complex instructions, and breaks them into smaller, wasting vast amounts of power with complex instruction decoding. Historically, CISC has had much higher single threaded performance, albeit at a higher power cost, but this gap is quickly narrowing, and where efficiency matters, reversed. Obviously in phones, efficiency is king, and with the M1, performance good enough for laptops.

@@xeridea ... and in practice, ARM has thumb, RISC-V has RVC, and it's much more about how much an architecture can avoid or simplify complex architectural state in the speculation pipeline, than whether fetch/decode is complex. 30 years ago, fetch/decode complexity mattered, but not today. My question is: Does the approach in RISC-V pay off? What's the relative latency of a branch misprediction? How often does it run into a full pipeline flush? How much memory load pressure is avoided with the bigger register file? Those are differences that matter!

@@jonwatte4293 I am not an expert on the topic, I know there are obviously optimizations with the fetch decode, but in general x86 is far more complex, and less efficient. It has came a long way, and has been cool to see AMD come back, in a big way, now we have lots of cores, which is another way to gain efficiency, due to how energy use grows exponentially with voltage/frequency. Branch misprediction latency is heavily affected by the pipeline length. Full pipeline flush would be.... anytime there is a mispredicted branch. More registers don't lessen memory load, they allow more parallel operations with the instructions. Bigger cache reduces memory stress.

Better cost and performance? I don't think so. I have tested the performance of RISC-V microcontrollers and they are behind Arm controllers (see my videos here on this channel). A Raspberry Pi Pico board is $5, and that has a dual core processor.