Same!

Yes and remember as well WD also uses another older technology on the silicon as well, in there being an embedded 6502 processor, with 64k of ROM and RAM, which is used to bootstrap the main processor, feeding in the configuration file and doing housekeeping, as the core is now royalty free to use, and there is a lot of tools to develop for it, and it is both also RISC, and also incredibly small as well, fitting well in the RISC architecture. So small you can fit it into a ultra cheap processor sold as a toy.

The only thing that could be the fly in the ointment is that 486 and ARM have a standard that is controlled and understood. Risc-V is already split into two closed and open. Who will control compatibility?

All of us my friend 🎉

@@tonysheerness2427 RISC-V Foundation will do that ... btw, that (standardization, research, promotion, providing resources and training) is their purpose and right to exist:) Don't forget that RISC-V itself IS the base layer providing compatibility. Anything else YOU invent and introduce to the platform (and that freely, which isn't a thing with X86 & ARM) is surplus, a gift or a relief. How could you possibly see that as something bad (like you asking in that direction)? With more, free and open diversity there will come opportunities! No offense or accusation: It is only ones OWN confusion and fears (based on unfamiliarity with the topic?) that gives this unfounded feeling of negative consequences. (This problem exists not only with processor-ISAs ... sadly).

You're very welcome!

Yes, Kamol, I agree that this was an excellently done video, and I appreciate it very much. I especially like that it's being put out relatively toward the beginning of 2023, so that we have some kind of high-level overview of what RISC-V developments we might anticipate this year. I agree with others sentiments that this sort-of feels like another "birth era" in the computer industry (or perhaps "rebirth" would be a better adjective). It kind-of has the warm-fuzzy feelings somewhat similar to the historical mid-70s feel of the hobbyist S-100 bus market in which literally thousands of hobbyists participated in some small way or another in the road along which the MITS Altair 8800 and IMSAI 8080 (and some 6502 and Motorola 680x0 architectures) gradually morphed into the goal that some of us had at the time, namely a "personal computer" in every home. We weren't so prescient as to anticipate a "personal computer" in every pocket and in every car dashboard. The winners of that first round of personal-computer development were arguably those companies whose business-management acuity was greatest (and some would argue those who were just the darn best at turning the business idea of the personal computer into a profit-producing monopoly) such as the Bill Gates and Steve Jobs visionaries of the world. A side effect of the topsy-turvy growth of the industry is that the instruction set architecture for Intel/AMD x86-64, although powerful, is just a horrible messy nightmare, such that we should probably have special custom shrinks to provide psychiatrist help to those poor slobs who are still stuck writing x86 code at the assembler level. ARM came along later, so was a bit less terrible than x86. We see the current benefits in Apple M2 chips being able to accomplish the same amount of work at power levels much lower than equivalent x86-64 CPUs (although the $ cost might still be more expensive due to Apple's pricing philosophy). But time and time again it has been proven that for doing equivalent tasks using much less power, RISC beats CISC (unless you can design a custome CISC chip for your particular mix of instructions - which nobody ever does). There's really only about half-a-dozen major categories of instructions (and cross that orthogonally with various data types and sizes-in-bits-or-bytes) in a standard CPU core, and now that we've kinda-sorta figured out multithreading more-or-less sufficiently, it's almost always more efficient chip-die-real-estate-wise to have a simpler, more-orthogonal instruction set (that is, more toward the RISC end of the spectrum) than to waste a lot of die space on interpretting and executing huge instructions that are rarely used in practice. A better approach these days to rare instructions is to have a very-fast function call mechanism to something that, by default, is implemented in software, but if needed is special cases can be implemented as add-ons to the core RISC ISA so as to run really fast in hardware This approach would also probably be best for GPU architectures. We went all the way around the horn and made tens of billions for Nvidia (and mere billions for AMD and Intel) in making discrete GPUs, only to find out that this sort of thing would be best incorporated as optional parts of a CPU chip that shares the same memory space as the rest of the CPU (such as in the AI engines now incorporated in Apple chips and some specific 7040-series AMD chips). I can see the industry possibly marching even more in this direction under the umbrella of RISC-V.

Great point!

Yes, this! BTW, you forgot HP PA-RISC and Itainium. Except for "Itanic", I have used all of them.

@@cdl0 Elbrus CPU...

You say that, but, just look at the Snap vs flatpak vs etc... situation. The open source community is already at a pretty maxed capacity just doing things for different linux flavors on the SAME architecture. How will adding 10-15 more CPUs with different and non-standardized instruction sets benefit anyone outside of those with the money to pay people to make software for their specific platform? And yes, risc-v has stuff in theory to make things have basic minimums to prevent fragmentation but those have not produced the desired results, its uniform only on the most idealistically written marketing webpage.

@@TheRus13 Oh yes, a super-rare one, even more exotic than the Itanium! I never got my hands on one of these, as well. Another legend lost in the mists of time was the Transputer. I have seen these demonstrated, but never used one.

Thanks, appreciated. :)

done

This recognition would be greatly deserved!

Only 1 million? That is an outrage! This channel should have at least 1 BILLION viewers!!

​@@Remigrator A channel generally have more viewers than subscribers. Remember that most popular channels tend to ask their viewers to subscribe because as they say: "60% of our viewers aren't subscribed". Most people just watch a new video when it gets recommended and don't subscribe at all.

@@new-lviv the most dystopian OS is Windows 11

Every kind of knowledge should be open and free for everybody! It's a shame that one has to pay for example for ISO- oder DIN-Definition-Documents or for learning materials that could be hosted and downloaded practically for free.

@@new-lviv Yes. This is a phenomenon also known as "freedom". Freedom is always a bit messy, offering too many choices. Leading to inevitable fragmentation. But, like, some might challenge that, well, that's kind of the point. That's what freedom is. That this is the definition of freedom. To make your own choices. And for that choice to be a real choice, it needs to be a free and open choice - which necessitates a wide array of possibilities. And, with everyone making their own varying choices, this inevitably leads to fragmentation. The underlying argument being that this is not a bug. It's a feature. It's supposed to look like this.

@@thesenamesaretaken Everyone always says that about the current Windows OS. The entire community was in an uproar when Windows 10 came out, totally different to the positive sentiment today.

@@jimtekkit I can't speak for 10 because I never used it. What I can say is, having moved straight from 7 to 11, that there is a lot about it that makes me cringe, as if they deliberately looked for bad parts of the smartphone ecosystem and brought those to the desktop. If it weren't for work and education I would abandon windows entirely at this point.

Yeah, at my job we make makes SoCs for industrial controllers and sensors. We're looking to make our own eFPGAs for the signal processing, ideally on the same chip as the sensor.

There's $15 FPGA dev boards that can run a RISC-V soft core at 100 MHz - granted it's the stripped down embedded processor, but more than enough to replace most microcontrollers.

Guys .. look what we saw found out today, a mobile RISC-V platform based on FPGA. look for Mr Iot tech

Thanks for support. And yes, I remember the Commodore/Atari/Sinclair days very well. Things do always move on.

​@@ExplainingComputers looking back always makes me regret I am not a hoarder 😢😂

I think your interest matches that of most makers. I'm now planning a video that will try to bring together what has happened in the maker SBC space, why, and where we may go next. Stay tuned! :)

Wait, something happened to those little things?

@@builder396 well, kinda, the company raspberry pi foundation saw an opportunity to make loads of money and instead of selling to makers, learners and enthusiasts they have now prioritized selling them to big companies for automation (as its a perfect product for automation etc.)

Historically there hasn't been a problem with ARM. It's been very, very cheap to license and has not been limited.. For the most part if you're making chips the cost of ARM should be largely meaningless. Open source not necessary for anyone in the business and RISC-V would have died off. But China is trying to get around trade sanctions. RISC-V is pretty much entirely about the very unequal entity of China. That's what this is about, not any high-mindedness.

Global trade balance is the way.

Well if you like at the internet public statistics 1/2 of all users are on phones. So when they get a new phone and it has RISC-V as long as everything they use works as normal barely anyone will care. The problem will be when you get to the server market as almost everything is made for x86. To my knowledge they will not change from what they use unless there is a good reason to change. Then you have the desktop market. As almost everything is made for x86 or x86_64 moving to RISC-V or even Microsoft trying to move to ARM is a problem as almost everything designed for desktop is made for x86.

@@kyleolson8977 So is RISC-V a threat to the US and NATO? As a Pole, Canadian and Brit, that would concern me very much. Could it lead to defeating the power of Western sanctions on bad actors?

Agreed.

I just worry about what this means for the more enthusiast and pro-sumer markets, where being able to build a machine that is exactly what you want in terms of specs and hardware is dominant. I just recently built my first server, and I don't think I would be able to do that if everything is SOCs and MiniPCs.

@@K9TheFirst1 Socketed SOCs with support for PCIE expansion is technically possible. Run the power efficient graphics on the soc, and when the extra omph is needed, the external GPU spins up. RAM might still be as it is, with SOC ram acting closer to cache than RAM.

I have to strongly disagree. The modular Midi Tower has two main advantages over SOCs and MiniPCs. 1. It can be used to cool off enormous amounts of energy without the computer becoming too loud. This cannot be done with an SOC and an SOC would always be significantly slower than such a cooled high-end computer in a midi tower. 2. You can upgrade the Midi Tower super cheap. I only have to replace the motherboard, the CPU and the RAM, I can mostly continue to use the rest. I've been doing it this way for many years now and it's the most cost-effective solution to have a lot of power and a sufficiently up-to-date computer at the same time. The SoC serves niches. As a secondary computer e.g. It's okay to watch Netflix, but a SoC will never displace my main computer in the Midi Tower. This is not possible just because of point 1.

Thanks Perry. Views "permitting", I hope to now post a RISC-V annual update each March, just as I have done a quantum computing update in August for many years now.

@@ExplainingComputers Yes, definitely views permitting. Also, permit me to say, I liked the visuals of you talking to the audience with computer and video tech stuff on both sides of you on the table. Impressive young Jedi!

I think we are kindred spirits here. Great post! Thanks for sharing. :)

Many thanks for this support -- most appreciated. :) As you say, RISC-V SBCs will go on improving, and rapidly. The barrier to their use right now is already software, not hardware . . . but it will get there, as there is a lot of community support and interest.

Well done for pointing this out. Thank you for saving me the trouble of making the same comment.

CISC only made sense in the early days of computing, when memory and storage where very expensive and highly limited in capacity, and power consumption was basically inconsequential. The emphasis was on making your compiled executables as small as possible. In today's computing world, those things are reversed.

@@johnhunt1725 CISC also makes sense if you are going to write your code in Assembler. Many CISC instruction sets are really like high level languages. As compilers evolved, it became easier to 'translate' high level language code into RISC instruction sets. I'd wager that very little ARM code is actually written in assembler (except for low level initialization routines), and that most ARM software is actually written in C, Ada, Python, or other high level languages.

@@johnhunt1725 Yes, this was the working hypothesis. When real RISC processors were released in the wild, it was found that real code density was very much better than feared, and barely worse than CISC. The reason is that RISC ISA's necessarily provide efficient, orthogonal machine codes for compilers.

@@KennethScharf 🤔Does anyone write anything for any platform in assembler anymore? I wouldn't be surprised if it's no longer a BS in CS degree requirement these days.

RISC has been a major technology for quite some time now, there are more ARM cores out in the wild than all other processors combines. RiscV is just a processor instruction set standard based on RISC that is open source meaning no licensing costs to those who wish to implement it in silicon. The disadvantage is that ARM provides core designs that can easily be integrated into SoC designs. With RiscV you are on your own.

The "R" in ARM stands for "RISC", by the way. Originally, the "Acorn RISC Machine", as it was created by Acorn in the UK. But then - in a joint venture with Apple (who'd used the ARM chip in their Newton product) and VLSI - they founded a new company for its further development, and as Apple and VLSI were also involved there, then the Acorn in the ARM name was substituted and, for the company, ARM stood for "Advanced RISC Machine". These days, the acronym officially stands for nothing. It's just a name and is no longer considered to be an acronym for anything. But, yeah, the ARM was born in the '80s in the Acorn Archimedes. I used one at school, when I was a kid. (And, truth is, though modern x86 chips still present a CISC instruction set for compatibility's sake, it's really a RISC chip, running microcode, under the hood and has been for a long time now. It just presents a CISC instruction set to the outside world, for "backwards compatibility", but its internals are actually RISC.)

Thanks for your support, most appreciated. :)

have a like from me for your avatar

Great post. An agreed! In particular, a very good point on the server space / cloud providers. And on the EU . . .

Server != cloud != big 5 cloud providers. Adding another architecture will be easy for the big 5 than for pourer players. Europe also has NXP. Fabless production is the great enabler for new designs, TSMC monopoly is a problem compared to back when chips like 6502 could use an ecosystem of competing fabs that didn't own particular gate and transistor designs elements .

What success? 0.001% of the desktop market 🤣🤣🤣🤣🤣!

@@jimmihenry While it is a small percentage, it is growing. It's about 2.94%, slightly higher than Chrome OS. Up from 2.19% a year ago. Windows dropped about 4% during that same period.

@@rgbii2 I tired Linux.Linux Puppy for a older laptop, oh boy what a journey! Had to scratch the boot loader from another revision, i accidentally downloaded a Japanese version to get the grub, well it was 3 am spend hours on that build... Because i am stubborn i made it. I also installed Arch it was way smoother, but only on a virtual machine. Linux is not a suitable daily rig OS sadly. Not even Ubuntu that spy's on you like Billy G. (G like gangster 🤣)

@@jimmihenry Depends a bit on hardware and distribution. Some 22 years ago I had no problems at all installing Redhat to dual boot on an IBM T20, and it has gotten to be much simpler since then e.g. with Ubuntu. It's essentially automatic now, and much the same goes for PC's. One slightly nasty thing to note is that current installers on big distributions such as Ubuntu won't work on very old x86 CPU's; you need to find a distribution which supports old hardware. As for daily use, the Linux ecosystem supports just about everything you are lilkely to do, and there are several ways to run Windows things if need be. Note that Linux will mount Windows filesystems, and packages such as Libre Office have good format conversion utilities. I have used Linux for 99% of everything I do since 1995. Distributions have included Slackware, Redhat, Distro Astro, Ubuntu and Ubuntu MATE (not forgetting Raspbian on the Pi), the choice is vast. In nearly thirty years I can remember paying for only one application, an Excel-like spreadsheet called Xess, and after 25 years the binary can still run on current Ubuntu (with a little hacking of the install script).

@@jimmihenry Hmm, I've been using Linux since around 1995. Nowadays, I have it running on most of my machines and on my wife's laptop. My children also use Linux both at home and at work. I have supported Linux both on servers and desktops from over a decade, in addition to Linux-based PBX systems. YMMV, as the Yanks say, but if you measure the success of Android which runs on top of a Linux kernel, you can hardly say that Linux has been a failure. I would gently suggest that your own personal experience does not define the success of Linux.

I don't think Risc-V is fixed length, but check the documentation.

Almost all modern RISC designs use variable length instructions. ARM, PowerPC, MIPS, and SuperH have done it for a long time. The only thing that really differentiates RISC from CISC is whether you can access AND compute information in a single instruction. In almost all other respects, including addressing modes and SIMD, modern RISC processors do a lot of things the CISC way.

@@johndododoe1411 If you mean that Risc-V also have a 16-bit instruction mode like ARM Thumb, you are right. But the main problem with x86 is that instruction lengths vary greatly and instruction boundaries cannot be easily found and because of that converting instructions to microops cannot be done in a simple and efficient way. This limits number of translation units and prevents further speedup in x86 ISA.

@@mehmetdemir-lf2vm As far as I recall, RISC-V has a very regular instruction length pattern, but not fixed length like ARM 32-bit.

@@johndododoe1411 you recall right, but if you inspect the instruction set throughly most if not all the instructions are 32 bit, and 16 bit if compressed. longer instructions are also supported for future use to be flexible.

Thanks Allan, your support is appreciated. :)

It will be a long time before that may happen. RISC-V is likely to be used in the embedded market, then probably servers. These are applications that generally use new code or code that can be recompiled. Mobile and desktop are more dependent on pre-installed software, so these are more difficult to transition.

Thanks for this. More regular updates may indeed be needed! :)

The real problem is that x86(x64) is designed for a different market than RISC-V. x86 has a stupidly complicated instruction format, but the instruction decoding process is a drop in the bucket compared to the hardware needed for high-performance computing, and x86 does that really well. If x86 didn't have such a deeply entrenched ecosystem, a "cleaned up" x86 instruction format could be developed that would absolutely destroy everything in the high-performance market. RISC-V is reasonably simple, but it just can't compete at the high-end due to major compromises to satisfy the low-cost embedded market. Having read the RISC-V whitepapers, it's obvious the ISA was not designed for performance applications, and I doubt it will ever be competitive in that market, which is a shame. RISC-V is generating excitement because it's cheap, and it's possible that will affect consumer prices by a penny or two. It'll take something else to dethrone the dominance of x86/ARM in the PC and server market. ARM will be around for a long time, as it's the certification and verification tools that really matter when you're developing a complete system, and RISC-V can't (and will never) hold a candle to that.

@@Waccoon Excellent points, Waccoon. Many I'd not fully considered. I think a lot of possibilities still lie in multicore RISC-V. Tho this massively multicore space is GPU space more than CPU space, it'll still be interesting where edge [in both senses of extraneous and edge computing] cases lie. NVIDIA has stated replacing Falcon with RISC-V, and I think RISC-V does perhaps sit in this middle ground, somewhere between CPU and GPU, which, for ML TPU driven development, might be an interesting space. The Esperanto ET-SoC-1 being perhaps the biggest/fastest proposal in this space so far. And while I certainly don't doubt your arguments and research here, I guess I'm just more optimistic about things we don't know yet :) In that the more these get pushed out to research markets, the more unexpected use cases/modifications will appear. Either way, it's going to be fun to watch, and will push all markets, that's the main thing :)

My pleasure!

Glad it was helpful!

I don't think RISC-V needs to beat x86_64, the processor so small and energy efficient it can be used in battery powered apps and lower power applications where heat is a problem. It is ideal for compact controllers for networking, disk drives, SSD drives, fan-less media controllers for audio/video applications where fan noise is objectionable.

Box64 is being ported to RISC-V by @ptitSeb123. He just posted a video playing SuperHexagon with Box64 on the VisionFive 2 RISC-V SBC.

Odds are good you won't be able to build a computer in the sense you are thinking of with risc-v anymore than you can just go out and buy an ARM cpu and then go buy a motherboard you like with it currently. It will be like the M1/M2/etc.. Macs. You will just be buying the system, not the parts and all the pros and cons that brings.

Greetings Steve. :)

Apple has changed ISA in their desktop computers more than once. Both times they've used a combination of "fat binaries" containing machine code for both systems as well as emulation to keep software running. The overhead from emulation has also been used as an incentive to compile to the newer architecture. Given how much Apple likes to control their stack, they could very well be among the first to push RISC-V to desktop computing, at least if they didn't _just_ switch to ARM so recently. The prior instance by the way was switching from PowerPC to x86, and they're reusing the exact same technologies used to handle that switch with the current one from x86 to ARM.

RISC-V is an open (ie free-to-license) ISA. It is not open source (as in open source software).

Sounds ominous tbh 😂

I think you misinterept the situaton. The "open" part refers to the situation with licensing, not development. There is no direct comparison to open source software. The RISC-V standards are fixed, if extensible. But any extensions lie outside of the core instruction set. And there is zero incentive for anybody to deviate from the core instruction set if designs cores, SoCs or SoMs for general application.

100% agree, but I think this kind of inconsistency will not stop it from being adopted. Actually it will encourage it being adopted, because each company of computer engineers will like that they can develop their own cpu. It's just something that will become an issue if there a lot of vendors w/ CPUs that run Linux. And then we'll work it out in software.

Greetings Chris. :)

This is just not how it works. Yes, RISC-V is extensible -- developers can add extra instructions as extensions. But this only happens for dedicated chips -- for example a car manufacturer may add instructions useful for them in an embeded device. Your description of RISC having an "open architecture" is misleading and not really correct, and perhaps suggests that you are comparing RISC-V to open source software, when the two are really not comparable. The openess of RISC-V relates to the LICENSING of the ISA, not to altering the ISA itself.

@@ExplainingComputers My understanding is that the earliest RISC-V did not even include floating point instructions (something like where Intel architectures were around the late 1980s). They do have that, although there seems to be no compulsion to prohibit manufacturers from 'improving' on those instructions if they so wish (as far as I am aware there is no RISC-V verification process, although I may be wrong about that). Nonetheless, modern desktop and server architectures require far more than that; they require SIMD instructions, and instructions to support VMs and memory virtualisation, and much more. What compulsion is there for every RISC-V manufacturer to implement common solutions to these omissions? Rather than comparing it to embedded systems, maybe better to look at the problems with differing GPU architectures from different OEMs, and the need to somehow create (with varying degrees of success) various abstraction layers that allows software to talk to the various GPUs (although this has now become less of an issue as there are now only very few GPU architectures still surviving as many have fallen by the wayside).

Exactly why is "open ISA" a competitive advantage vs x86 and ARM, apart from non-proprietary IP? Is there an intrinsic performance advantage to RISC-V? Or is it just that RISC-V provides a bigger playpen for (not yet realized) innovation? If it's the latter, what's to stop Intel/AMD or ARM from making their own playpens more inviting by "opening" their IP and improving design tools and foundry infrastructure so that it's easier to design? Wouldn't that be a way to strangle RISC -V in the cradle?

That's the problem. RISC-V is only an ISA, not a system specification, so the reality of implementing it in a real system is a mess. Code written for one processor will almost certainly not work on another. All the major RISC-V vendors use a variety of proprietary instructions to overcome the limitations of the ISA, especially with regards to performance, which isn't very good.

So nice of you.

:)

Something tells me you are English. Just guessing. :)

@@d.barnette2687 tom's hw has a recent article that goes into great depth on risc-V - well worth a look - youtube does not like links #balderdash #poppycock #joseph conrad #art conan doyle #alistar crowley #jim keller

:)

By many accounts, RISC-V is very close to MIPS at the assembly level

Thanks for your support. :)

Greetings my friend.

Also, PowerPC, Sparc, PA-RISC, and MIPS. It was always envisioned that ARM would run Unix and Unix-like operating systems, as well.

@@cdl0 Anything can run UNIX as long as you have at least supervisor/user privileged modes and an MMU.

@@Waccoon Correct: ARM has included all the necessary modes from the outset.

China and Russia definitely will use their technologies as a way of avoiding sanctions in order to continue their war and total disrespect to human rights and humanity overall.

I could see a 'WiFi File Server' for running backups for all PC's, tablets, phones in your home. That would be similar to smart printers with 'WiFi Print Server' built in. If they used a Linux File Server program it would be easy for user to maintain and provide for 'off site' backup as well.