The Risc V push is fascinating to me
-
I read here somewhere recently that Google is pushing to make Risc V de riguer for Android phones. In addition Espressif has IoT MCUs based on Risc V processors, and appears to be moving to Risc V for their new projects. This tells me Risc V is suitable for CPUs with a wide range of capabilities. It's about damned time they standardized a CPU architecture in a practical way that could be leveraged across the tech industry. I'm really interested in this technology, and although I'm not a fan of Espressif's current Risc V offerings, which are low power, but kind of anemic, they have a soon to be released offering The ESP32P4 Triple core (2x400MHz, 1xULP40MHz), 768kB of SRAM, 50 GPIO, wireless connectivity for days, all Risc V based. And if Android primarily adopts it, how long before Windows follows suit?
To err is human. Fortune favors the monsters.
-
I read here somewhere recently that Google is pushing to make Risc V de riguer for Android phones. In addition Espressif has IoT MCUs based on Risc V processors, and appears to be moving to Risc V for their new projects. This tells me Risc V is suitable for CPUs with a wide range of capabilities. It's about damned time they standardized a CPU architecture in a practical way that could be leveraged across the tech industry. I'm really interested in this technology, and although I'm not a fan of Espressif's current Risc V offerings, which are low power, but kind of anemic, they have a soon to be released offering The ESP32P4 Triple core (2x400MHz, 1xULP40MHz), 768kB of SRAM, 50 GPIO, wireless connectivity for days, all Risc V based. And if Android primarily adopts it, how long before Windows follows suit?
To err is human. Fortune favors the monsters.
-
Microsoft is too embedded in the x86/64 architecture. This was one of the problems with the AlphaServer versions of Windows NT - emulation was far too slow.
Doesn't dotNet change that? In dotNet, there is no emulation; each assembly is JIT compiled to native code. I believe that even available instruction set extensions are considered, to avoid runtime testing - all JIT compilation is done on the target machine (but don't quote me as a source on that). (This is obviously when the code is distributed as dotNet assemblies; you can generate a complete, statically linked executable file for distribution; then the code must test for instruction set extensions at run time!) I also believe that the structure of the Windows kernel has been significantly changed since the NT days, in the direction of a much more well defined hardware abstraction layer that handles different architectures, leaving the higher layers unaffected. With a HAL definition, they are not talking about any sort of emulation, but true native code - think of the HAL as the code generation part of compilation! (If you like: The JIT part of dotNet compilation.) Historically, Windows has been running on i860, Alpha, Itanium, MIPS, PowerPC, ARM, ARM64, IA-32 and x86-64 - that provides quite a background for defining a HAL suitable for a multitude of CPU architectures (including Risc V). Another problem with the Alpha was that the processor itself flopped. It made a good cooking plate for frying your lunch meal, though. I have been working with the Alpha for just a couple years: We bought it to teach the tech. college students Unix, so it was running DECs own Ultrix. I can assure you: Performance problems was not limited to Window NT! The vendor doubled the amount of RAM installed, at no cost to the college, in an attempt to make it perform as promised in the contract, but even after that, it didn't "run" - at most, it walked, dragging its feet along the ground. My impression is that DEC had problems with context switching performance when working in a small format. Running a single process could show impressive results, but switching among 20 user front ends (running X11 servers) didn't work out. It reminded me of the early VAX days: The company of a friend of mine bought a VAX 730, and benchmarked process switches to take 100 ms - one tenth of a second! They had to rewrite their DBMS from three to two main processes, so that fewer process switches was needed, to get acceptable performance.
-
I read here somewhere recently that Google is pushing to make Risc V de riguer for Android phones. In addition Espressif has IoT MCUs based on Risc V processors, and appears to be moving to Risc V for their new projects. This tells me Risc V is suitable for CPUs with a wide range of capabilities. It's about damned time they standardized a CPU architecture in a practical way that could be leveraged across the tech industry. I'm really interested in this technology, and although I'm not a fan of Espressif's current Risc V offerings, which are low power, but kind of anemic, they have a soon to be released offering The ESP32P4 Triple core (2x400MHz, 1xULP40MHz), 768kB of SRAM, 50 GPIO, wireless connectivity for days, all Risc V based. And if Android primarily adopts it, how long before Windows follows suit?
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
It's about damned time they standardized a CPU architecture in a practical way that could be leveraged across the tech industry.
Keep dreaming! It has happened! Look at the x86 desktop architecture. Many years earlier, it was the IBM 360 architecture. For smartphones, the ARM architecture has been a de facto standard CPU architecture for quite a few years. The problem is that lots of developers discover that there is something new, which makes them reject the estabished, accepted, respected and honored standards - they want to throw them out. Look at yourself: What makes you think that ARM is not "a CPU architecture that could be leveraged across the tech industry"? You have found that RISC V has some advantages that makes it a better alternative. If we switch horses from ARM to RISC V, it won't take long before someone come up with yet another architecture that has advantages over the RISC V. Over the years, I have lost all kinds of trust in "Strangler jeans: One size fits all!" You must be prepared to handle alternate solutions. Monoculture is never good. (My t-shirt that states "Stereotypes are real time savers" is sort of true, but obviously ironic.) So make yourself a hardware abstraction layer, and implement that on all the different CPUs that you come to work on. (Regarding RISC V: I 'discovered' it in my last job. The company makes IoT chips externally looking as two core ARM chips. Under the cover, there are several other cores, managing various parts of the hardware asynchronously with the two main ARM chips. One of these 'secret' cores is a RISC V.)
-
I read here somewhere recently that Google is pushing to make Risc V de riguer for Android phones. In addition Espressif has IoT MCUs based on Risc V processors, and appears to be moving to Risc V for their new projects. This tells me Risc V is suitable for CPUs with a wide range of capabilities. It's about damned time they standardized a CPU architecture in a practical way that could be leveraged across the tech industry. I'm really interested in this technology, and although I'm not a fan of Espressif's current Risc V offerings, which are low power, but kind of anemic, they have a soon to be released offering The ESP32P4 Triple core (2x400MHz, 1xULP40MHz), 768kB of SRAM, 50 GPIO, wireless connectivity for days, all Risc V based. And if Android primarily adopts it, how long before Windows follows suit?
To err is human. Fortune favors the monsters.
https://www.digikey.com/en/resources/risc-v[^] "At the heart of the differences between ARM and RISC-V is the matter of closed and open-source hardware. ARM is closed source whereas RISC-V is open source." Big delta
"A little time, a little trouble, your better day" Badfinger