Note that in RISC-V there are profiles which are separate from the instruction set extensions. You can have an application profile for running Linux and a different microcontroller profile for embedded applications. Each profile specifies a base instruction set and a set of mandatory extensions plus some non ISA details (like the interrupt controller and debug mechanism). A system can implement a profile but also add extensions that the profile doesn't mandate. If such an optional extension proves to be popular enough, it might become mandatory in a future version of that profile. But these instructions will remain an extension - they will never get added to the base ISA. This allows one profile to get more bloated without necessarily affecting other profiles.
This is a very important note. ^ I witnessed the seminar on profiles at the summit, and I had mixed feelings about the amount of "administrative complexity" had been added, and how much is optimal; some, of course, is required. I'm avoiding the "design by committee" phrase, because I don't think it's fair. OTOH, profiles do offer a possible better route than individual customizations going straight to the next generation base standard after being popular. It seemed like, from the seminar, that several profiles already exist, so it is something that we should get comfortable with in the evolution process of RISC-V. A popular set of customization making its way into a "profile" would be preferable to one route from "customization-to-base standard", if I understand the intent. It is from this very video here (DJ's) that I connected profiles and "customizations" (I can't help but think of graphics accelerator standards and "extensions" madness) mentally. tldr; customizations and profiles could be a good thing, better than the alternative, straight-to-standard (which seems like it could be contradictory.)
The difference between RISC and CISC has become blurry, but one difference which still stands is the split between memory access and arithmetic. In a RISC processor, an instruction can access memory, can perform arithmetic operations but can NOT do both (e.g. 'inc ', found even on the MOS 6502). Also, both ARM and RISC-V have fixed-sized instructions, even though it's not a RISC requirement.
@@ecdhe Risc V is not exactly fixed length but mostly fix length. There is an extension for more compact 16bit length instruction compared to regular 32bit length instruction.
Well, this CISC and x86... The CISC architecture could be thought of several special purpose RISC subunits to decide and execute the instructions. Lots of the x86 implementations have RISC CPUs in them to do management and microcode stuff.
Thanks for producing these fine videos. For folks interested in more details about RISC-V, I recommend the book "The RISC-V READER" by Patterson and Waterman.
It was my understanding that the extra power consumption of *modern x86* is mainly found in the instruction decode module, the speculative execution, and related out-of-order pipeline support circuits rather than strictly in the logic processesing core. In the core the execution of an operation is effectively the same set of internal register moves and clock cycles regarding a basic integer calculation. (Setting aside special modules, coprocessors, and such. Most ARM don't even have float module.) Further complication is microcode that converts an external CISC instruction into internal RISC instructions; and on the other team certain combinations of simple external RISC instructions can be fused to make a more complex internal instruction.(saving an instruction register load and maybe a clockcycle or two) Then externally we see maybe 16-32 registers, yet hardware may have well over 200. There was also a time long ago when CISC was being forcast to evolve into a hardware high level language interpreter, sort of like a Python ASIC. In any case I have seen some analysis that show for small embedded stuff that isn't dominated by caches and pipelines, RISC-V can be implemented in less physical area than ARM which is direct cost savings as raw chip manufacturing cost rises with the square of chip area.(Of course the package cost dilutes the advantage a bit, but many are used as blob on board without solderable packages.)
I mean, you're describing most of the performance aspects of the chip there. As DJ mentioned, the soft-squishy internals of modern x86 CPUs are really RISC cores with all that extra stuff wrapped around them to make them faster. A lot of what Intel does from chip to chip is to retune which subsets of CISC instructions are optimized for in the decoding in order to best align with the current set of programs on the market. I would definitely hope that a RISC-V core would take less silicon than an ARM chip. Typical ARM implementation is around 500 opcodes while RISC-V is only 47 opcodes.
@@thewiirocks Risc-V base is 47 opcodes, but modules beyond a simple microcontroller will add more. The point with that is that it doesn't force "all or nothing". In any case I was talking about the area used for a similarly complete set of opcodes, not comparing the base risc-V to a full featured ARM.
There is also a tradeoff in silicon. The logic needed to perform each complex instruction must exist on the wafer even when this instruction is not needed. The remaining functionality then must work around this area within the speed of light limit and the capacitance of the longer traces. One or two of these functions might use as much silicon as an entire RISC core. Each complex instruction can perform that function faster and more efficiently than any other implementation; but few programs use every complex instruction and some programs use none.
In terms of energy consumption, I see two ways RISC processors have an edge over CISC: - Intel processors split their instructions into micro-instructions, whereas I'm not aware ARM processors do. If that's the case, it means extra transistors for Intel CPUs, which means more heat generation - Fixed-length instructions are easier to handle, allowing a simpler design. You won't gain in performance but will cut down on extra transistors to deal with variable-length instructions I do not know to what extent those factors matter, but it is also true that the one thing we've asked Intel/AMD is 1) more powerful processors and 2) backward compatibility, so energy consumption was never the top priority. ARM, on the other hand, had energy consumption pressure starting with their very first version (even though it was designed for a desktop computer)
Thanks DJ, highly interesting as always. Reminds me of the Acorn Archimedes, which I almost bought who knows back when, just for the heck of RISC. Anyway, new sub here: What is the best way of humbly proposing topics for future videos?
@@CyberGizmo Thanks DJ, apologies for the off-topic request: Would love to hear your thoughts on future LAN-wide user authentication in home networks in the Fedora/RHEL realm (and likely in other distros). You know, the kind of networks for which LDAP+Kerberos (FreeIPA) is really overkill (I hate both, BTW)... Fedora is scheduled to abandon NIS in F38, so what to do now? FreeIPA, the suggested alternative, is simply too intrusive for me, yet there seems to be no simpler alternative. I just want to sync my uid/gid/passwords among a few trusted local stations. Thanks again, Jan.
The Acorn Archimedes was an amazing machine for the time - 1986 - I wrote a lot of assembly code for the ARM2 and ARM3 processor for those first machines and I still have one here in my office. People today don't realise ARM originally stood for Acorn Risc Machines well before ARM was spun out as a separate company - it's an amazing story. RISC V is doing great stuff but ARM has such a massive lead it's going to be a long time before applications processors are going to be anything like threatening ARM - especially considering as DJ says, you still have to licence IP cores from some company and it still takes a massive amount of engineering to get it right. ARM has surprisingly cheap licence fees for how well developed it is today. At the microcontroller/IoT level, that's where RISC V is going to do well in the short to medium term especially now Espressif is focusing on RISC in their ESP32 line. I just wish they didn't confuse that branding. On the server side the custom ARM Graviton focus from AWS is really significant. Both Azure and Google Clouds now offer ARM instances but they are a bit further back. Ampere's 128 Core Altra Max is another one to watch for on premises servers in 2023.
In the early MIPS days the pipeline was very visible to the programmer. Accessing some result too early wouldn't work (a pipeline hazard) rather than wait for it (a pipeline stall). Of course you'd want to avoid stalls too and the assembler even reorganized instructions for you unless you told it not to (for example by putting instructions in the branch delay slot).
Thanks for the video ! Very informative. Regarding CISC vs RISC, in the early days, most commercial ISAs were CISC. Like 6504, 68000 etc, these were the days when people were still writing assembly. In time, as compilers and higher level languages emerged, it made more sense to take away the complexity from ISA and put it into compilers. By doing this, they were able to make CPU cores smaller, efficient and robust. (Thats the story I heard in the uni anyway lol :) ) I have another question though, how different is Apple Silicon to ARM ? I think they have some extensions ? Does Apple pay fees to ARM ? Also, does Apple have any plans to go into the server market ? It's not their effigy, but I think there is a great potential for them there. Apple silicon is very efficient and powerful. Also, community is building the software for them, you can run linux on M1.
Only Apple would be able to talk about those differences, they are so tight lipped about it and I have also noticed they don't share those features back to ARM, great question though. And I don't want to re-open the CISC vs RISC debate that's like arguing which is your favorite editor. Thanks for the kind words!
Apple has an ARM architecture license, which means that they pay for the ARM ISA but designed their own micro-architecture (i.e. CPU core design) from the ground up. So an M1 is compatible with any other ARM v8 processor but the implementation is completely different. I don't think Apple has any interest in the server market but ARM does with its Neoverse family of micro-architectures aimed at servers. And AWS released the Graviton 3 based on that micro-architecture.
@@ecdhe just assume 6502… what? No love for the short-lived 6501? ;-) (Hmm.. nobody talking about 6800 or 6809… keep quiet or they’ll hear us and insist on joining the party)
CISC instructions are more complex and take more cycles to execute. Due to multiple execution paths. CISC architectures have variable length instructions. Multiple argument combinations affect how an instruction is read and how it is executed. RISC has a well-defined fixed-length instructions that take certain clock cycles to execute. The emphasis in CISC is on smarts in the hardware, while RISC is optimized through the instructions that it get - the software that you as a developer write. Yet CISC CPUs are nowadays implemented with RISC concepts under the hood. So a complex instruction might be unfolded into multiple instructions that also can be reordered and optimized so to reduce clock cycles.
AWS is pushing their ARM based cpu graviton on their cloud and it's cheaper with the same performance as x86 architectures. They acquired some ARM special company to build these cpus specially for the cloud.
I've been rather impressed by Graviton performance. AWS is extremely competitive with Intel server CPUs at a much lower power budget. They still don't hold a candle to Apple Silicon (which are CRAZY FAST cores) but they're definitely holding their own far better than anyone could have predicted.
Plot twist, Intel is already RISC. In fact the native opcodes of the Intel CPU's are similar to ARM. The x86 instruction set is being emulated in software(microcode) inside the CPU. Most likely this happened when Intel acquired Transmeta's patents. Transmeta was a CPU company that emulated assembly instructions sets inside the CPU which they called "Code Morphing Software". So for those of you who did not get the memo.... RISC won, and CISC died a long time ago.
Very Long Instruction Word...In general I think its a good idea anything that helps parallelization is better than doing single instruct, the fact that it makes those parallelization choices at compile time, I feel is a better place to do it, than at runtime by the scheduler
ARM is making moves into the server space. As of today the Fugaku supercomputer is the 2nd most powerful super computer in the world and it is based on ARM CPUs. Companies copy Apple and they are seeing the power of ARM based Macs. Rumors state Microsft is working on a custom CPU for their Surface line. It will be interesting to see the performance of the new Mac Pros based on ARM.
Thank you, though I understood almost nothing of that. Trying to get a basic grasp of the differences between the chip/CPU/architecture types, I have watched a small variety of videos, but it seems I will need a basic grasp of the mathematical side of this (unlikely to happen) in order to get that basic grasp. I had thought that it could probably be understood from a simpler (perhaps as an analogy with something tangible in the real world as it were) perspective. Of course I understood the dichotomy of: fewer but more complex instructions vs more but simpler instructions. If anyone knows of a link to something for real novices / laypersons, thanks in advance.
I think you forgot to mention the third processor type. I'm assuming you were referring to Very Long Instruction Word (VLIW) design? Those never quite panned out like we hoped. I doubt anyone even remembers Transmeta's attempts to make the design mainstream.
I remember Transmeta's VLIW. Their design allows lower power comsumption to notebook computer. Fujitsu made some low power notebook based on Transmeta's VLIW CPUs.
18:08 The x86 ISA has without a doubt evolved since 1978. HPC and machine learning systems that only need 24GB/CPU are probably salivating over the Apple M2 chip; too bad they can't build servers with them...
Apple hasn't cared about servers for a long long time now, however you might want to check out the SiPearl announcement from November 2022 on their partnership with AMD to provide an ARM Neoverse V1 with scalable vector extensions and AMD Instinct for the EuropeanHPC project
ARM just pulled an AT&T by suing Qualcomm for the Nuvia CPU. The 8cx can't compete with Apple silicon and the Qualcomm's Nuvia CPU could have changed that.
I do not see why Qualcomm cannot compete with Apple Silicon. There aren't any breakthough technology used in AppleSilicon that Qualcomm cannot do. Most are TSMC technology. Qualcomm can also get the same thing with TSMC although without the Apple flavour tweaks. Qualcomm is facing another market with another set of rules. They cannot make their chip the way Apple does. Apple sells the whole phone and Qualcomm sells the SoC. As for the in-chip memory those are custom made ordered from Apple to Samsung. If Qualcomm wants and places order Samsung will make them as well. Apple does not have many patents on memory chips.
@@catchnkill While you are correct, the Nuvia team is the team that architected the M1 chip. Qualcomm bought them to make a competing desktop chip and Qualcomm sued them.
is it true risc-v is more integer based and amd64 is focused on floating point? to me integer based to me means microcontroller applications dealing with timers and bools/bytes, and floating point means cartesian-coordinates/math based applications.... not sure though
or buy a RISC-V board: a cheap one (Nezha D1, 30 USD) or a more expensive one (StarFive VisionFive 2, Pine64 Star64, Sipeed LM4A (Lichee Module 4 Model A ... all around 100 USD). RISC-V in QEMU on x86 is extremely slow
The distinction between RISC and CISC "philosophy" is more and more blurred. Almost all CICS processors are microcoded and deeply pipelined, often achieving superscalar performance. One could say that RISC processors put the burden of optimizations like branch prediction and instruction reordering on the compiler, while CISCs do that themselves. In theory, the compiler has more information on the program structure and should be better at those optimizations.
Here is Jim Keller's take on the subject. He has worked and Intel and AMD. He's the chief architect for Ryzen. ua-cam.com/video/yTMRGERZrQE/v-deo.html I find his take on important instructions and variable length instructions fascinating. It leads me to think of an instruction set like Unicode, something like RISC and VLIW in one ISA.
If Jim Kellers "ISA doesn't matter" is true, it means that it should be possible to design an x86 core that delivers similar performance to Apples Arm cores at similar "low" clock speeds of 3.2-3.5 GHz (M1/M2). But the reality is that there are two seasoned x86 companies that both came up with the same solution: clock as high as possible. Intel learned the expensive way (Pentium 4) that IPC matters and AMD startet Zen from scratch, knowing that current manufacturing nodes give you transistors (almost) for free and that clock speed won't improve much more. So, again: both companies know that clock speed only gets you so far and IPC/ILP is the future, especially if you want an efficient design. So unless there is an x86 core that is implemented "wide and slow" i won't believe that "ISA doesn't matter".
@@janhofmann3499 Part of the problem with clock speed is that there's only so much you can do to reduce the physical distance of the circuits. Cranking up the clock requires increasing the number of pipeline stages, which just isn't a very good tradeoff. As the aforementioned Pentium IV demonstrated. Though I do think that a good chunk of the improved performance we're seeing in Apple Silicon has a lot to do with packaging. By moving the memory to a predictable location closer to the cores, Apple can reduce the number of wait cycles associated with memory fetches. This allows the chip to use a lot of downtime that most other chips have to waste waiting for a fetch to complete. Which gives Apple an incredible performance advantage that x86 can't match while still supporting DIMMs. I think this design has become a bit of a problem as they try to scale up to build a chip for the Mac Pro. Latest rumors is that Apple hasn't gotten the scalability they want out of the "M2 Extreme" chip and are therefore scrapping it for a high powered Ultra chip. They're probably hitting the limits of physical space without getting into some really sophisticated 3D stacking in the packaging. Honestly, I'm thinking Apple should just bite the bullet and add multiprocessor support with DIMMs into the Mac Pro. Use the on-package memory as an L4 cache for each chip, allowing them to avoid main memory accesses as much as possible. I'm willing to bet they could scale it at the high end a lot better than way without having to create a lot of new silicon.
@@janhofmann3499 ISA does not matter but legacy instruction do matter. ARM has the advantage of being newer so it has less legacy codes making a mess. x86 should be possible to design to be very power efficient but they need to give up compatibility with legacy instruction and only implement modern instructions and extensions. Using only 64bit compatible instruction and dropping the 16bit era complex memory addressing. This will remove the power needed for memory translation, simplify decoding and improve the efficiency of the Opcode cache. This will also prevent old codes from actually running but if you only use 64bit compatible software then there is no problem.
@@kazedcat I'm honestly surprised that they haven't dropped the 16 bit stuff.. even though it might cause some problems, it's not like we run operating systems old enough to make much use of the software that did. Since XP, no DOS programs are runnable, and I doubt much Windows NT code takes advantage of pre-32 bit instructions.
The law suit between ARM and Qualcomm over the licensing agreements after the acquisition of Nuvia has given RISC V increased popularity. Nuvia are promising to do similar to what Apple did with their M Series Silicon by offering desktop performance with mobile efficiency. It would be amazing to have an architecture from RISC V that can scale from iot, euv, smartphone, tablet, laptop, desktop, edge, server. I now use a smartphone for majority of my needs. I’m used to the screen size and the limited multitasking, switching to a foldable or dual only increases my productivity. One day my smartphone will be able to run a full desktop pro app and play games natively at 4k 120Hz with raytracing. I’ll probably never need to upgrade it.
"M Series Silicon by offering desktop performance with mobile efficiency." - But, what is the price for mobile laptop that you pay for MacBook Pro 16" with 1tb SSD and 32GB RAM? Probably more then 3000$... NO THANKS!!! For the 1000-1500$ you can buy very good laptop with the same performance like M2 pro/max with many possibilities to run Windows/Linux/BSD! For M1/M2 ARM there is nothing right now! There is too many limitation for ARM Apple M1/M2.
@@levskilevov4888 this is simply not true there are plenty of people using apple silicon comfortably there is actually fewer people using Linux and BSD combined than they are using MacOS. The Apple Laptops with M Series SOC are the best selling laptop. There are also more applications supporting Apple Silicon natively especially those that matter to most people. As for affordability te MacBook Air is priced very competitively, nothing like the doom and gloom you are describing.
*You forgot to link to a video on security extensions. Instead there's a link to Home Lab video.* This video started completely beginner-friendly, then suddenly escalated to some wacky expert knowledge stuff about virtualization, "MMUs". Then hovered somewhere in the middle because of terms like "IOT" and "edge" thrown in (IOT is a widely-known one, but few people would remember it by acronym, because its hype train passed long time ago with no tangible success).
Nope didnt forget the link the Home Lab video is my plans to redo the security of my network, as for your other comments, meh nit picky. For what its worth a quick search on Google for iot, returns 496,000,000 entires with IoT not IOT. Internet of Things would be correctly represented by IoT in accordance with English language rules of capitalization. As for the IOMMU's that is a critical difference between x86, ARM and RISC-V that no one covers, its not whacky, Sergro its critical for passing hardware to a guest virtual machine.
my cellphone has a more powerfull cpu then my first servers i setup,and it can run on battery for a full day and fits in my pocket,i think power usage will at some point become a problem for both amd and intel,apples m1 and m2 is doing really well its a shame its locked in to apples realm.
RISC v is very cool, but the formal Isa guidelines are extremely complicated to follow lol, there are very many levels and it’s really cool, but Jesus is it hard to explain to someone without domain knowledge
David Patterson hasn't taped out a processor, EVER. He just spent his entire academic career hawking an instruction set. Someone else will have to seal his legacy. I'd give more credence to Jim Keller, not David Patterson.
The RISC-V does not contain innovative ideas in microprocessor design capable of replacing existing processors such as x86 and ARM. The RISC-V processor is not suitable as a candidate for this role. They say “RISC-V does not represent new technology”. The RISC-V has no novelty potential. The tomorrow’s world needs completely new architectural ideas as familiar processors x86 and ARM are morally obsolete architecturally. I propose the novel architectural idea, see my article, address is below in this comment. The RISC-V is good for embedded systems, controllers, and similar as free and open. There are other positives and improvements, but they are on the engineering level. But the RISC-V will never become a general all-purpose processor. The RISC-V is based on 40-year old ideas as RISC-V Foundation claims. There is no sense to port the huge x86 and ARM software ecosystems on it. Thus, RISC-V will never gain a victory over x86 and ARM. The most of positives about the RISC-V processor are arbitrary speculations. Actually, the main advantage/benefit of RISC-V is free and open architecture (open ISA). The RISC-V processor has instructions with variable lengths, consisting of 2-byte snippets. It is strange, it is bad being a deviation from the classic, absolute, and pure RISC principles well formulated at the beginning of the RISC era. Also the RISC-V processor has 6 instruction formats, and it is too many. I sceptically evaluate the RISC-V microprocessor, because it is based on old ideas and does not advance computer science and practice, freezing the long-achieved scientific and technical levels. However, I pay tribute to the creators of the ideas of the RISC microprocessor, with the main feature to perform all arithmetic/logical operations only on registers, and use external RAM only to load/store processed data. I also pay tribute to the idea of the free and open computer architecture (not patented instruction set architecture). The Contemporary microprocessors contain 8 specific hardware components: (1) SMT (Simultaneous Multithreading), (2) register renaming, (3) instruction reordering, (4) out-of-order execution, (5) speculative execution, (6) superscalar execution, (7) delayed branch, (8) branch prediction. These components make up some kind of a “magnificent eight” of components which essentially raise the performance of microprocessors. But unfortunately they are very complex. A processor core having these components is a full-fledged one, otherwise it is good for simple applications, e. g. for embedded systems, controllers etc. The “magnificent eight” of components is very hard to design, only the experienced firms and developers are able to do this, and much know-how was acquired, some effective solutions are patented. Particularly complex is the SMT. Only powerful and advanced firms like Intel, AMD, IBM are able to equip their processors with the “magnificent eight” components. It is not surprising that some Intel processors, and the famous Apple's M1 processor do not contain SMTs. If a company is able create the full-fledged RISC-V processor with all “magnificent eight” components then it would be a serious achievement, and such RISC-V would be considered of the World's class comparable with x86, with ARM, but not more. As far as I understand most of the developed RISC-V processors have no components from the “magnificent eight”, and are intended for embedded systems. A course directed on further development of RISC-V is a wrong way, and leads the computer architecture to deadlock. The RISC-V is not promising for computer industry. In fact, RISC-V hampers the further development of the state-of-the-art microprocessor technologies. The World demands absolutely novel microprocessor having much more higher performance than all contemporary ones. The novel and effective ideas on computer architectures do exist! Here’s such a novel processor architecture in article V. K. Dobrovolskyi. “Microprocessor Based on the Minimal Hardware Principle”. The article is published in scientific magazine Electronic Modeling (Електронне моделювання), 2019, vol 41, No 6. pp. 77-90. The magazine is posted in the Internet: www.emodel.org.ua/en/ touch ARCHIVE, move to 2019, then to VOL 41, NO 6, (2019) then click Microprocessor Based on the Minimal Hardware Principle, then go below to Full text: PDF, and click PDF. My novel processor architecture does not have the “magnificent eight”, The “eight” is not necessary at all. This comment reflects different view on the RISC-V architecture, and the computer community has a right to become familiar with such a view. I’m Volodymyr Dobrovolskyi (V.K.Dobrovolskyi).
In fairness, RISC was always more of a design concept than a hard and fast rule for implementation. The market found the middle ground between RISC and CISC that worked best and moved there. Existing CISC (x86 for the most part) became more RISC internally while RISC processors grew in complexity to meet the performance needs of the chips. It's kind of like how many modern languages are both interpreted AND compiled thanks to the use of JITs. Or how we've managed to integrate Harvard data/code split into Von Neuman machines which are wrapped in high-speed I/O chips that provide multiple caches along the way. Or how we do both top-down and bottom-up design before a design is complete. Or how we are finding more and more ways to mix dynamic typing and static typing in a complementary fashion.
@@thewiirocks Agree, all that hardware cache management, bus arbitration... Is probably done with special hidden cores that run on microcode... For example, The Intel management engine is a tiny not-x86 core that runs a tiny minix kernel.
@@CyberGizmo well RISC-V is a MISC ISA if the M stands for Modular. I think that is a unique feature that's going to make it so much better in the long run!
Good luck offering a "RISC-V" processor, without an annual subscription to the alliance and paying to have your implementation CERTIFIED. Let alone purchasing licences for the 90% of the die that incorporate proprietary, standards essential buses, memory controllers, ...
There is no need for you to get your CPU certified as RISC-V if you use it in your proprietary product. Let say you are making an industrial product which is a big hydraulic press. You want to use a CPU to run software to control it. You can use RISC-V instruction set to develop your proprietary CPU. Since it is internal use you are not selling it. There is no marketing need to get it certified. There will be a lot of such custom made RISC-V proprietary chips in industrial use.
@@catchnkillYou won't be selling any non FCC / EU certified product, with a documented supported structure in place, and demonstrably funded for a decade past end of production, in the majority of the Globe's markets, which costs millions to achieve. After you've spent millions creating your custom SoC and Software stack, that offers the same functionality to a certified $0.08 ARM M0 microcontroller. Let alone a custom modem packed SoC, to attempt to save the ~$0.29 Apple is reported to pay per M3 / A17pro to ARM, for it to pick up the hassle of creating a certified and supported CPU and Software stack.
Very disappointing that the discussion quickly turned in cisc vs risc. As one can see macs turned to RISK which appears to be more efficient for laptops than current cisc and for servers amazon EC2 runs ARM machine types which have better performance to price ratio for many workloads than amd64. So as a whole this video seems to be a waste of time.
Note that in RISC-V there are profiles which are separate from the instruction set extensions. You can have an application profile for running Linux and a different microcontroller profile for embedded applications. Each profile specifies a base instruction set and a set of mandatory extensions plus some non ISA details (like the interrupt controller and debug mechanism). A system can implement a profile but also add extensions that the profile doesn't mandate. If such an optional extension proves to be popular enough, it might become mandatory in a future version of that profile. But these instructions will remain an extension - they will never get added to the base ISA. This allows one profile to get more bloated without necessarily affecting other profiles.
This is a very important note. ^
I witnessed the seminar on profiles at the summit, and I had mixed feelings about the amount of "administrative complexity" had been added, and how much is optimal; some, of course, is required. I'm avoiding the "design by committee" phrase, because I don't think it's fair.
OTOH, profiles do offer a possible better route than individual customizations going straight to the next generation base standard after being popular. It seemed like, from the seminar, that several profiles already exist, so it is something that we should get comfortable with in the evolution process of RISC-V. A popular set of customization making its way into a "profile" would be preferable to one route from "customization-to-base standard", if I understand the intent. It is from this very video here (DJ's) that I connected profiles and "customizations" (I can't help but think of graphics accelerator standards and "extensions" madness) mentally.
tldr; customizations and profiles could be a good thing, better than the alternative, straight-to-standard (which seems like it could be contradictory.)
The difference between RISC and CISC has become blurry, but one difference which still stands is the split between memory access and arithmetic. In a RISC processor, an instruction can access memory, can perform arithmetic operations but can NOT do both (e.g. 'inc ', found even on the MOS 6502). Also, both ARM and RISC-V have fixed-sized instructions, even though it's not a RISC requirement.
RISC-V has variable length instructions though, Kriste even mentioned it in last years videos about the "discussions" that generated
@@CyberGizmo I didn't know that, I was under the impression RISC-V had fixed-length instructions. My bad.
@@ecdhe Risc V is not exactly fixed length but mostly fix length. There is an extension for more compact 16bit length instruction compared to regular 32bit length instruction.
As always straight to the point and with solid facts.
Thank you, user!
Great great video, exactly the type content I was looking for. Thank you so much for sharing your insights
Well, this CISC and x86... The CISC architecture could be thought of several special purpose RISC subunits to decide and execute the instructions. Lots of the x86 implementations have RISC CPUs in them to do management and microcode stuff.
Agreed you can't stuff any CPU's anymore into a pure CISC or pure RISC anymore, its all a mess :)
Thanks for producing these fine videos. For folks interested in more details about RISC-V, I recommend the book "The RISC-V READER" by Patterson and Waterman.
Nice. Thanks DJ
Welcome @seguramik
It was my understanding that the extra power consumption of *modern x86* is mainly found in the instruction decode module, the speculative execution, and related out-of-order pipeline support circuits rather than strictly in the logic processesing core. In the core the execution of an operation is effectively the same set of internal register moves and clock cycles regarding a basic integer calculation. (Setting aside special modules, coprocessors, and such. Most ARM don't even have float module.)
Further complication is microcode that converts an external CISC instruction into internal RISC instructions; and on the other team certain combinations of simple external RISC instructions can be fused to make a more complex internal instruction.(saving an instruction register load and maybe a clockcycle or two)
Then externally we see maybe 16-32 registers, yet hardware may have well over 200.
There was also a time long ago when CISC was being forcast to evolve into a hardware high level language interpreter, sort of like a Python ASIC.
In any case I have seen some analysis that show for small embedded stuff that isn't dominated by caches and pipelines, RISC-V can be implemented in less physical area than ARM which is direct cost savings as raw chip manufacturing cost rises with the square of chip area.(Of course the package cost dilutes the advantage a bit, but many are used as blob on board without solderable packages.)
I mean, you're describing most of the performance aspects of the chip there. As DJ mentioned, the soft-squishy internals of modern x86 CPUs are really RISC cores with all that extra stuff wrapped around them to make them faster. A lot of what Intel does from chip to chip is to retune which subsets of CISC instructions are optimized for in the decoding in order to best align with the current set of programs on the market.
I would definitely hope that a RISC-V core would take less silicon than an ARM chip. Typical ARM implementation is around 500 opcodes while RISC-V is only 47 opcodes.
@@thewiirocks Risc-V base is 47 opcodes, but modules beyond a simple microcontroller will add more. The point with that is that it doesn't force "all or nothing".
In any case I was talking about the area used for a similarly complete set of opcodes, not comparing the base risc-V to a full featured ARM.
Excellent video thank you. IMHO one of the reasons RISC-V is attractive is because a nation state can't embargo it.
Thanks for the very informative video. Very insightful
There is also a tradeoff in silicon. The logic needed to perform each complex instruction must exist on the wafer even when this instruction is not needed. The remaining functionality then must work around this area within the speed of light limit and the capacitance of the longer traces. One or two of these functions might use as much silicon as an entire RISC core. Each complex instruction can perform that function faster and more efficiently than any other implementation; but few programs use every complex instruction and some programs use none.
In terms of energy consumption, I see two ways RISC processors have an edge over CISC:
- Intel processors split their instructions into micro-instructions, whereas I'm not aware ARM processors do. If that's the case, it means extra transistors for Intel CPUs, which means more heat generation
- Fixed-length instructions are easier to handle, allowing a simpler design. You won't gain in performance but will cut down on extra transistors to deal with variable-length instructions
I do not know to what extent those factors matter, but it is also true that the one thing we've asked Intel/AMD is 1) more powerful processors and 2) backward compatibility, so energy consumption was never the top priority. ARM, on the other hand, had energy consumption pressure starting with their very first version (even though it was designed for a desktop computer)
Thanks DJ, highly interesting as always. Reminds me of the Acorn Archimedes, which I almost bought who knows back when, just for the heck of RISC. Anyway, new sub here: What is the best way of humbly proposing topics for future videos?
Thank you Jan, comments always work, I try and read them all
@@CyberGizmo Thanks DJ, apologies for the off-topic request: Would love to hear your thoughts on future LAN-wide user authentication in home networks in the Fedora/RHEL realm (and likely in other distros). You know, the kind of networks for which LDAP+Kerberos (FreeIPA) is really overkill (I hate both, BTW)... Fedora is scheduled to abandon NIS in F38, so what to do now? FreeIPA, the suggested alternative, is simply too intrusive for me, yet there seems to be no simpler alternative. I just want to sync my uid/gid/passwords among a few trusted local stations. Thanks again, Jan.
The Acorn Archimedes was an amazing machine for the time - 1986 - I wrote a lot of assembly code for the ARM2 and ARM3 processor for those first machines and I still have one here in my office. People today don't realise ARM originally stood for Acorn Risc Machines well before ARM was spun out as a separate company - it's an amazing story.
RISC V is doing great stuff but ARM has such a massive lead it's going to be a long time before applications processors are going to be anything like threatening ARM - especially considering as DJ says, you still have to licence IP cores from some company and it still takes a massive amount of engineering to get it right. ARM has surprisingly cheap licence fees for how well developed it is today. At the microcontroller/IoT level, that's where RISC V is going to do well in the short to medium term especially now Espressif is focusing on RISC in their ESP32 line. I just wish they didn't confuse that branding.
On the server side the custom ARM Graviton focus from AWS is really significant. Both Azure and Google Clouds now offer ARM instances but they are a bit further back. Ampere's 128 Core Altra Max is another one to watch for on premises servers in 2023.
In the early MIPS days the pipeline was very visible to the programmer. Accessing some result too early wouldn't work (a pipeline hazard) rather than wait for it (a pipeline stall). Of course you'd want to avoid stalls too and the assembler even reorganized instructions for you unless you told it not to (for example by putting instructions in the branch delay slot).
Thanks for the explanation👍
Thanks DJ👍
Thanks for the video ! Very informative.
Regarding CISC vs RISC, in the early days, most commercial ISAs were CISC. Like 6504, 68000 etc, these were the days when people were still writing assembly.
In time, as compilers and higher level languages emerged, it made more sense to take away the complexity from ISA and put it into compilers. By doing this, they were able to make CPU cores smaller, efficient and robust. (Thats the story I heard in the uni anyway lol :) )
I have another question though, how different is Apple Silicon to ARM ? I think they have some extensions ? Does Apple pay fees to ARM ?
Also, does Apple have any plans to go into the server market ? It's not their effigy, but I think there is a great potential for them there. Apple silicon is very efficient and powerful. Also, community is building the software for them, you can run linux on M1.
Only Apple would be able to talk about those differences, they are so tight lipped about it and I have also noticed they don't share those features back to ARM, great question though. And I don't want to re-open the CISC vs RISC debate that's like arguing which is your favorite editor. Thanks for the kind words!
Apple has an ARM architecture license, which means that they pay for the ARM ISA but designed their own micro-architecture (i.e. CPU core design) from the ground up. So an M1 is compatible with any other ARM v8 processor but the implementation is completely different. I don't think Apple has any interest in the server market but ARM does with its Neoverse family of micro-architectures aimed at servers. And AWS released the Graviton 3 based on that micro-architecture.
I assume you mean 6502 instead of 6504 ;-)
@@ecdhe just assume 6502… what? No love for the short-lived 6501? ;-)
(Hmm.. nobody talking about 6800 or 6809… keep quiet or they’ll hear us and insist on joining the party)
@@nickpalance3622 the 6800 was what inspired the 6502 but it was way too expensive
Great video, thanks for such a straightforward breakdown.
Most welcome, Tony
Thanks 😁
CISC instructions are more complex and take more cycles to execute. Due to multiple execution paths.
CISC architectures have variable length instructions. Multiple argument combinations affect how an instruction is read and how it is executed. RISC has a well-defined fixed-length instructions that take certain clock cycles to execute.
The emphasis in CISC is on smarts in the hardware, while RISC is optimized through the instructions that it get - the software that you as a developer write.
Yet CISC CPUs are nowadays implemented with RISC concepts under the hood. So a complex instruction might be unfolded into multiple instructions that also can be reordered and optimized so to reduce clock cycles.
I have always considered the Control Date 6000 series to be the fist serious RISC architecture. A bit of Seymour Cray brilliance.
AWS is pushing their ARM based cpu graviton on their cloud and it's cheaper with the same performance as x86 architectures. They acquired some ARM special company to build these cpus specially for the cloud.
Yep they are one of the companies who are very interested in ARM
I've been rather impressed by Graviton performance. AWS is extremely competitive with Intel server CPUs at a much lower power budget. They still don't hold a candle to Apple Silicon (which are CRAZY FAST cores) but they're definitely holding their own far better than anyone could have predicted.
Plot twist, Intel is already RISC. In fact the native opcodes of the Intel CPU's are similar to ARM. The x86 instruction set is being emulated in software(microcode) inside the CPU. Most likely this happened when Intel acquired Transmeta's patents. Transmeta was a CPU company that emulated assembly instructions sets inside the CPU which they called "Code Morphing Software".
So for those of you who did not get the memo.... RISC won, and CISC died a long time ago.
What are your thoughts about VLIW?
Very Long Instruction Word...In general I think its a good idea anything that helps parallelization is better than doing single instruct, the fact that it makes those parallelization choices at compile time, I feel is a better place to do it, than at runtime by the scheduler
ARM is making moves into the server space. As of today the Fugaku supercomputer is the 2nd most powerful super computer in the world and it is based on ARM CPUs. Companies copy Apple and they are seeing the power of ARM based Macs. Rumors state Microsft is working on a custom CPU for their Surface line. It will be interesting to see the performance of the new Mac Pros based on ARM.
Thank you, though I understood almost nothing of that.
Trying to get a basic grasp of the differences between the chip/CPU/architecture types, I have watched a small variety of videos, but it seems I will need a basic grasp of the mathematical side of this (unlikely to happen) in order to get that basic grasp.
I had thought that it could probably be understood from a simpler (perhaps as an analogy with something tangible in the real world as it were) perspective.
Of course I understood the dichotomy of: fewer but more complex instructions vs more but simpler instructions.
If anyone knows of a link to something for real novices / laypersons, thanks in advance.
I think you forgot to mention the third processor type. I'm assuming you were referring to Very Long Instruction Word (VLIW) design?
Those never quite panned out like we hoped. I doubt anyone even remembers Transmeta's attempts to make the design mainstream.
I remember Transmeta's VLIW. Their design allows lower power comsumption to notebook computer. Fujitsu made some low power notebook based on Transmeta's VLIW CPUs.
Is there an AMD or Intel CPU that uses A.R.M. or RISCv architecture?
18:08 The x86 ISA has without a doubt evolved since 1978.
HPC and machine learning systems that only need 24GB/CPU are probably salivating over the Apple M2 chip; too bad they can't build servers with them...
Apple hasn't cared about servers for a long long time now, however you might want to check out the SiPearl announcement from November 2022 on their partnership with AMD to provide an ARM Neoverse V1 with scalable vector extensions and AMD Instinct for the EuropeanHPC project
👍👍
ARM just pulled an AT&T by suing Qualcomm for the Nuvia CPU. The 8cx can't compete with Apple silicon and the Qualcomm's Nuvia CPU could have changed that.
never a good idea to sue your customers, will they ever learn
I do not see why Qualcomm cannot compete with Apple Silicon. There aren't any breakthough technology used in AppleSilicon that Qualcomm cannot do. Most are TSMC technology. Qualcomm can also get the same thing with TSMC although without the Apple flavour tweaks. Qualcomm is facing another market with another set of rules. They cannot make their chip the way Apple does. Apple sells the whole phone and Qualcomm sells the SoC. As for the in-chip memory those are custom made ordered from Apple to Samsung. If Qualcomm wants and places order Samsung will make them as well. Apple does not have many patents on memory chips.
@@catchnkill While you are correct, the Nuvia team is the team that architected the M1 chip. Qualcomm bought them to make a competing desktop chip and Qualcomm sued them.
is it true risc-v is more integer based and amd64 is focused on floating point? to me integer based to me means microcontroller applications dealing with timers and bools/bytes, and floating point means cartesian-coordinates/math based applications.... not sure though
What about DSP and SDR embedded environments
18:40 The #2 supercomputer in the world is ARM right now
Will run Debian RISC V in Qemu and check it out.
or buy a RISC-V board: a cheap one (Nezha D1, 30 USD) or a more expensive one (StarFive VisionFive 2,
Pine64 Star64, Sipeed LM4A (Lichee Module 4 Model A ... all around 100 USD).
RISC-V in QEMU on x86 is extremely slow
The distinction between RISC and CISC "philosophy" is more and more blurred. Almost all CICS processors are microcoded and deeply pipelined, often achieving superscalar performance. One could say that RISC processors put the burden of optimizations like branch prediction and instruction reordering on the compiler, while CISCs do that themselves. In theory, the compiler has more information on the program structure and should be better at those optimizations.
Here is Jim Keller's take on the subject. He has worked and Intel and AMD. He's the chief architect for Ryzen. ua-cam.com/video/yTMRGERZrQE/v-deo.html
I find his take on important instructions and variable length instructions fascinating. It leads me to think of an instruction set like Unicode, something like RISC and VLIW in one ISA.
Thanks Esra will take a look at it.
If Jim Kellers "ISA doesn't matter" is true, it means that it should be possible to design an x86 core that delivers similar performance to Apples Arm cores at similar "low" clock speeds of 3.2-3.5 GHz (M1/M2). But the reality is that there are two seasoned x86 companies that both came up with the same solution: clock as high as possible. Intel learned the expensive way (Pentium 4) that IPC matters and AMD startet Zen from scratch, knowing that current manufacturing nodes give you transistors (almost) for free and that clock speed won't improve much more. So, again: both companies know that clock speed only gets you so far and IPC/ILP is the future, especially if you want an efficient design. So unless there is an x86 core that is implemented "wide and slow" i won't believe that "ISA doesn't matter".
@@janhofmann3499 Part of the problem with clock speed is that there's only so much you can do to reduce the physical distance of the circuits. Cranking up the clock requires increasing the number of pipeline stages, which just isn't a very good tradeoff. As the aforementioned Pentium IV demonstrated.
Though I do think that a good chunk of the improved performance we're seeing in Apple Silicon has a lot to do with packaging. By moving the memory to a predictable location closer to the cores, Apple can reduce the number of wait cycles associated with memory fetches. This allows the chip to use a lot of downtime that most other chips have to waste waiting for a fetch to complete. Which gives Apple an incredible performance advantage that x86 can't match while still supporting DIMMs.
I think this design has become a bit of a problem as they try to scale up to build a chip for the Mac Pro. Latest rumors is that Apple hasn't gotten the scalability they want out of the "M2 Extreme" chip and are therefore scrapping it for a high powered Ultra chip. They're probably hitting the limits of physical space without getting into some really sophisticated 3D stacking in the packaging.
Honestly, I'm thinking Apple should just bite the bullet and add multiprocessor support with DIMMs into the Mac Pro. Use the on-package memory as an L4 cache for each chip, allowing them to avoid main memory accesses as much as possible. I'm willing to bet they could scale it at the high end a lot better than way without having to create a lot of new silicon.
@@janhofmann3499 ISA does not matter but legacy instruction do matter. ARM has the advantage of being newer so it has less legacy codes making a mess. x86 should be possible to design to be very power efficient but they need to give up compatibility with legacy instruction and only implement modern instructions and extensions. Using only 64bit compatible instruction and dropping the 16bit era complex memory addressing. This will remove the power needed for memory translation, simplify decoding and improve the efficiency of the Opcode cache. This will also prevent old codes from actually running but if you only use 64bit compatible software then there is no problem.
@@kazedcat I'm honestly surprised that they haven't dropped the 16 bit stuff.. even though it might cause some problems, it's not like we run operating systems old enough to make much use of the software that did. Since XP, no DOS programs are runnable, and I doubt much Windows NT code takes advantage of pre-32 bit instructions.
could you please use slides during the talk? it would be easier to follow the technical talks
I saw Debian 11 has a RISC V ISO. Should Programmers start supporting RISC V?
Yes!
The law suit between ARM and Qualcomm over the licensing agreements after the acquisition of Nuvia has given RISC V increased popularity.
Nuvia are promising to do similar to what Apple did with their M Series Silicon by offering desktop performance with mobile efficiency.
It would be amazing to have an architecture from RISC V that can scale from iot, euv, smartphone, tablet, laptop, desktop, edge, server.
I now use a smartphone for majority of my needs. I’m used to the screen size and the limited multitasking, switching to a foldable or dual only increases my productivity. One day my smartphone will be able to run a full desktop pro app and play games natively at 4k 120Hz with raytracing. I’ll probably never need to upgrade it.
"M Series Silicon by offering desktop performance with mobile efficiency." - But, what is the price for mobile laptop that you pay for MacBook Pro 16" with 1tb SSD and 32GB RAM? Probably more then 3000$... NO THANKS!!!
For the 1000-1500$ you can buy very good laptop with the same performance like M2 pro/max with many possibilities to run Windows/Linux/BSD!
For M1/M2 ARM there is nothing right now!
There is too many limitation for ARM Apple M1/M2.
@@levskilevov4888 this is simply not true there are plenty of people using apple silicon comfortably there is actually fewer people using Linux and BSD combined than they are using MacOS. The Apple Laptops with M Series SOC are the best selling laptop. There are also more applications supporting Apple Silicon natively especially those that matter to most people. As for affordability te MacBook Air is priced very competitively, nothing like the doom and gloom you are describing.
Forgot about compressed instructions in RiscV. Anything open source will dominate market and win
How about a factory building user designed chip. Ie , personal DESIGNED CPU / GPU. PC.
*You forgot to link to a video on security extensions. Instead there's a link to Home Lab video.*
This video started completely beginner-friendly, then suddenly escalated to some wacky expert knowledge stuff about virtualization, "MMUs". Then hovered somewhere in the middle because of terms like "IOT" and "edge" thrown in (IOT is a widely-known one, but few people would remember it by acronym, because its hype train passed long time ago with no tangible success).
Nope didnt forget the link the Home Lab video is my plans to redo the security of my network, as for your other comments, meh nit picky. For what its worth a quick search on Google for iot, returns 496,000,000 entires with IoT not IOT. Internet of Things would be correctly represented by IoT in accordance with English language rules of capitalization. As for the IOMMU's that is a critical difference between x86, ARM and RISC-V that no one covers, its not whacky, Sergro its critical for passing hardware to a guest virtual machine.
@@CyberGizmo Yes, "whacky" was too big of an exaggeration. Do you have a video on such hardware virtualization things?
Nope, RISC-V is open standard ISA not Open Source License !!!
my cellphone has a more powerfull cpu then my first servers i setup,and it can run on battery for a full day and fits in my pocket,i think power usage will at some point become a problem for both amd and intel,apples m1 and m2 is doing really well its a shame its locked in to apples realm.
I think you can run Asahi Linux on the M2, not sure about the newer versions of the chips like the Max and Ultra
RISC v is very cool, but the formal Isa guidelines are extremely complicated to follow lol, there are very many levels and it’s really cool, but Jesus is it hard to explain to someone without domain knowledge
Entropy guarantees a hybrid clusterfuck of a hack.
second!!
Now that China is adopting RiscV wholesale, Intel, Amd, and Arm are dead.
RISC-V has higher hip value. Which effectively proves nothing at all.
in short answer. risc will be winner..
David Patterson hasn't taped out a processor, EVER. He just spent his entire academic career hawking an instruction set. Someone else will have to seal his legacy. I'd give more credence to Jim Keller, not David Patterson.
The RISC-V does not contain innovative ideas in microprocessor design capable of replacing existing processors such as x86 and ARM. The RISC-V processor is not suitable as a candidate for this role. They say “RISC-V does not represent new technology”. The RISC-V has no novelty potential. The tomorrow’s world needs completely new architectural ideas as familiar processors x86 and ARM are morally obsolete architecturally. I propose the novel architectural idea, see my article, address is below in this comment. The RISC-V is good for embedded systems, controllers, and similar as free and open. There are other positives and improvements, but they are on the engineering level. But the RISC-V will never become a general all-purpose processor. The RISC-V is based on 40-year old ideas as RISC-V Foundation claims. There is no sense to port the huge x86 and ARM software ecosystems on it. Thus, RISC-V will never gain a victory over x86 and ARM. The most of positives about the RISC-V processor are arbitrary speculations. Actually, the main advantage/benefit of RISC-V is free and open architecture (open ISA). The RISC-V processor has instructions with variable lengths, consisting of 2-byte snippets. It is strange, it is bad being a deviation from the classic, absolute, and pure RISC principles well formulated at the beginning of the RISC era. Also the RISC-V processor has 6 instruction formats, and it is too many.
I sceptically evaluate the RISC-V microprocessor, because it is based on old ideas and does not advance computer science and practice, freezing the long-achieved scientific and technical levels. However, I pay tribute to the creators of the ideas of the RISC microprocessor, with the main feature to perform all arithmetic/logical operations only on registers, and use external RAM only to load/store processed data. I also pay tribute to the idea of the free and open computer architecture (not patented instruction set architecture).
The Contemporary microprocessors contain 8 specific hardware components: (1) SMT (Simultaneous Multithreading), (2) register renaming, (3) instruction reordering, (4) out-of-order execution, (5) speculative execution, (6) superscalar execution, (7) delayed branch, (8) branch prediction. These components make up some kind of a “magnificent eight” of components which essentially raise the performance of microprocessors. But unfortunately they are very complex. A processor core having these components is a full-fledged one, otherwise it is good for simple applications, e. g. for embedded systems, controllers etc.
The “magnificent eight” of components is very hard to design, only the experienced firms and developers are able to do this, and much know-how was acquired, some effective solutions are patented. Particularly complex is the SMT. Only powerful and advanced firms like Intel, AMD, IBM are able to equip their processors with the “magnificent eight” components. It is not surprising that some Intel processors, and the famous Apple's M1 processor do not contain SMTs. If a company is able create the full-fledged RISC-V processor with all “magnificent eight” components then it would be a serious achievement, and such RISC-V would be considered of the World's class comparable with x86, with ARM, but not more. As far as I understand most of the developed RISC-V processors have no components from the “magnificent eight”, and are intended for embedded systems.
A course directed on further development of RISC-V is a wrong way, and leads the computer architecture to deadlock. The RISC-V is not promising for computer industry. In fact, RISC-V hampers the further development of the state-of-the-art microprocessor technologies. The World demands absolutely novel microprocessor having much more higher performance than all contemporary ones. The novel and effective ideas on computer architectures do exist! Here’s such a novel processor architecture in article V. K. Dobrovolskyi. “Microprocessor Based on the Minimal Hardware Principle”. The article is published in scientific magazine Electronic Modeling (Електронне моделювання), 2019, vol 41, No 6. pp. 77-90. The magazine is posted in the Internet:
www.emodel.org.ua/en/ touch ARCHIVE, move to 2019, then to VOL 41, NO 6, (2019) then click Microprocessor Based on the Minimal Hardware Principle, then go below to Full text: PDF, and click PDF.
My novel processor architecture does not have the “magnificent eight”, The “eight” is not necessary at all. This comment reflects different view on the RISC-V architecture, and the computer community has a right to become familiar with such a view. I’m Volodymyr Dobrovolskyi (V.K.Dobrovolskyi).
Armv8 is barely RISC anymore...
Yep I like Dave Jaggers view its MISC
In fairness, RISC was always more of a design concept than a hard and fast rule for implementation. The market found the middle ground between RISC and CISC that worked best and moved there. Existing CISC (x86 for the most part) became more RISC internally while RISC processors grew in complexity to meet the performance needs of the chips.
It's kind of like how many modern languages are both interpreted AND compiled thanks to the use of JITs. Or how we've managed to integrate Harvard data/code split into Von Neuman machines which are wrapped in high-speed I/O chips that provide multiple caches along the way. Or how we do both top-down and bottom-up design before a design is complete. Or how we are finding more and more ways to mix dynamic typing and static typing in a complementary fashion.
@@thewiirocks Agree, all that hardware cache management, bus arbitration... Is probably done with special hidden cores that run on microcode... For example, The Intel management engine is a tiny not-x86 core that runs a tiny minix kernel.
@@CyberGizmo well RISC-V is a MISC ISA if the M stands for Modular. I think that is a unique feature that's going to make it so much better in the long run!
Good luck offering a "RISC-V" processor, without an annual subscription to the alliance and paying to have your implementation CERTIFIED. Let alone purchasing licences for the 90% of the die that incorporate proprietary, standards essential buses, memory controllers, ...
There is no need for you to get your CPU certified as RISC-V if you use it in your proprietary product. Let say you are making an industrial product which is a big hydraulic press. You want to use a CPU to run software to control it. You can use RISC-V instruction set to develop your proprietary CPU. Since it is internal use you are not selling it. There is no marketing need to get it certified. There will be a lot of such custom made RISC-V proprietary chips in industrial use.
@@catchnkillYou won't be selling any non FCC / EU certified product, with a documented supported structure in place, and demonstrably funded for a decade past end of production, in the majority of the Globe's markets, which costs millions to achieve. After you've spent millions creating your custom SoC and Software stack, that offers the same functionality to a certified $0.08 ARM M0 microcontroller. Let alone a custom modem packed SoC, to attempt to save the ~$0.29 Apple is reported to pay per M3 / A17pro to ARM, for it to pick up the hassle of creating a certified and supported CPU and Software stack.
Very disappointing that the discussion quickly turned in cisc vs risc. As one can see macs turned to RISK which appears to be more efficient for laptops than current cisc and for servers amazon EC2 runs ARM machine types which have better performance to price ratio for many workloads than amd64. So as a whole this video seems to be a waste of time.