How is RISC-V's future?

hi lainons, I have been thinking about RISC-V and i am thinking about if it would be possible for Risc-V to completely replace X86 by having full functionality Emulation. personally i am not very educated on the matter. would it be possible to run a full Libre OS (including firmware and bios) with all functionality? how much better is the power efficiency compared to ARM? would it open the door towards something like solar-panels on the back side of laptop screens? in your opinions how long would it take (if we ignore the rare mineral shortage) until we get a viable consumer hardware? do you believe it will open the door towards a more competitive market when it comes to desktop CPU manufacturers? with these advantages, what do you believe could be a possibility only thanks to RISC-v?

>>52325 I don't manufacture chips for a living, but I think the future is very bright for RISC-V. One of the biggest efficiency issues in modern CPUs is how many cycles are wasted because they're effectively doing nothing. ARM was intended to fix this by reducing instruction complexity and shortening the pipeline, but the only performant ARM chips available are so complex that they may as well just be CISC again. Even chips like the M1 waste an enormous amount of time performing the same NEON instructions over and over again, which completely defeats the purpose of having a simpler architecture in the first place. RISC-V seems to have solved this. The core modality and modularity of the ISA is a huge step in the right direction, basically allowing for hardware acceleration at every stage of the pipeline. It's not airtight, but very few instructions are wasted since you can just outright cut the power to the cores you aren't using. The other issue RISC-V fixes is the scaling one. x86 scales fairly well across multiple cores and voltages, though a lot of the infrastructure used to facilitate it is decidedly hacked-together and aftermarket. ARM scales relatively poorly by comparison, limited by voltage because of it's simple instruction pipeline. ARM also has difficulties scaling with multiple cores, as it lacks much of the x86 cruft that made it easy. Plus, the majority of ARM chips are designed to run RTOSes and single-core schedulers. It's simply wasteful to make multi-core ARM systems, which is probably why Apple divided the M1 into two groups. RISC-V is designed to scale all the way to the top though, in both voltage and parallelism. You can run a 2 stage pipeline and/or a 21 stage pipeline, the CPU doesn't discriminate. You can also run a metric fuarrrkton of cores concurrently, which might be able to make integrated graphics a thing of the past. TL:DR - RISC-V will probably beat ARM by 2030. x86 is still fine for most use cases and dominates the server market, while ARM is the same weird middle child it has been since the 90s.

Using the email field is unnecessary. >how much better is the power efficiency compared to ARM? Well, RISC-V provides nothing for BIGNUM arithmetic, a common operation, and no special instructions for many other things, so it's clear its efficiency will suffer. Now, the solution to something being inefficient in software is to put it in hardware, which a RISC design is exactly the opposite of. Instead of using an FPGA, we should apparently use stupid little RISC machines forever. >with these advantages, what do you believe could be a possibility only thanks to RISC-v? RISC-V is nothing but some academics masturbating to their delightfully useless design. Imagine starving people, and some idiots talking about their beautiful seating arrangement, which also happens to only provide room for chopsticks, a fork, and a bowl. Most people only need chopsticks and bowls, they'd say, so this is fine. Why have a fork? Well, they like forks. What about spoons and knives? Those are an extension, so go sit somewhere else. RISC-V does absolutely nothing to help people manufacture silicon themselves. It's laughable anyone would think it would mean anything like this. There's no meaningful difference between proprietary-but-documented interface and freely-available interface here, and again, it is like kicking dead whales down the beach anyway.

>>52332 I think you have a distorted view. Granted, some academics had the odd idea of restricting the instruction set in order to make designs simpler, but it wasn't obvious that there were such benefits to be reaped. The success story of ARM is basically the success story or RISC (note I didn't say RISC-V). Whether RISC-V does actually become common will depend on the forces of the market, but like any open designs, it will get iterated upon all the time, getting more attractive ever so slightly, so it would be natural for RISC-V (or future derivatives) to dominate the market. You complain about extensions, but this extension business is intentional, not every chip needs every feature. Probably makes life easier for compiler designers as well, since it makes for clear boundaries within the spec.

>>52325 >in your opinions how long would it take (if we ignore the rare mineral shortage) until we get a viable consumer hardware? A while, it seems the RISC-V Foundation are assholes. https://www.crowdsupply.com/libre-risc-v/m-class/updates/nlnet-grants-approved-power-isa-under-consideration#PowerPC

>>52333 I didn't even mention POWER, which is actually available in something useful through Talos, but what purpose is there in RISC-V when MMIX exists: http://www.mmix.cs.hm.edu Look at how much simpler and cleaner it is; look at how the special register design allows it to store useful information that software can choose to use or ignore easily, a nice multiple value system that reminds me of Common Lisp's, as opposed to ignoring these issues and pushing them into software. The simple answer is that MMIX doesn't allow the Berkeley people to get that warm fuzzy feeling they get from UNIX and C, by ignoring everything they deem irrelevant, regardless of whether that be the case or not; it doesn't allow them to masturbate themselves.

>if it would be possible for Risc-V to completely replace X86 by having full functionality Emulation. Not in the silicon for sure, you'd lose all the advantages of RISC. >in your opinions how long would it take (if we ignore the rare mineral shortage) until we get a viable consumer hardware? probably a couple years. There's already some dev boards coming out. >>52332 This post was probably written by somebody who didn't pay attention in his mandatory assembly programming class. >Well, RISC-V provides nothing for BIGNUM arithmetic, a common operation, and no special instructions for many other things, so it's clear its efficiency will suffer. I've never heard of an ISA that *does* have bignum arithmetic built in. Instead they have carry bits and wide multiplication so that engineers can easily write efficient bignum implementations. It's also not *that* common to do bignum operations. For most users the only time their computer will ever do bignum operations is when they're doing public key cryptography. >and no special instructions for many other things, so it's clear its efficiency will suffer. The ISA is easily extensible. I'm also wondering what specific instructions you mean. >Now, the solution to something being inefficient in software is to put it in hardware or just write better software. Hardware is orders of magnitude harder to design. >Instead of using an FPGA, we should apparently use stupid little RISC machines forever. The fuarrrk? If you need an FPGA use an FPGA. >RISC-V does absolutely nothing to help people manufacture silicon themselves. Why should an ISA be in charge of manufacturing silicon? That is the job of CPU manufacturers. >There's no meaningful difference between proprietary-but-documented interface and freely-available interface here Okay, would you prefer to have an ISA with tons of undocumented behavior like x86? >>52334 that's actually a damn shame. I thought they were supportive :(

>>52342 >This post was probably written by somebody who didn't pay attention in his mandatory assembly programming class. I never took such classes, but I'd be willing to wager I've done more machine code programming between us. However, since this is an anonymous forum, I'd rather not link to my programs as a form of proof. >I've never heard of an ISA that *does* have bignum arithmetic built in. Several did, back when machines were designed to prevent common errors. >Instead they have carry bits and wide multiplication so that engineers can easily write efficient bignum implementations. I was referring to these, however, which RISC-V lacks. >The ISA is easily extensible. I'm also wondering what specific instructions you mean. It lacks multiplication, division, bit-accessing, and other common operations in its base. >Why should an ISA be in charge of manufacturing silicon? That is the job of CPU manufacturers. This is my point as to why RISC-V is just masturbation, and similarly meaningless. >Okay, would you prefer to have an ISA with tons of undocumented behavior like x86? Well, I suppose not, but RISC-V can be manufactured to have the same garbage, so it doesn't make a real difference. Again, why not use MMIX? Well, it doesn't let them masturbate themselves, so they ignore it, and screech about their meaningless work instead.

>>52344 >I was referring to these, however, which RISC-V lacks. In the base, yes. The standard vector extension, however, does have add with carry etc. https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#vector-integer-add-with-carry-subtract-with-borrow-instructions The standard multiplication extension also has wide multiplication by default. The spec doc explicitly says that extracting the high bits and then low bits of a multiply should result in a single multiply split across two instructions. >It lacks multiplication, division, bit-accessing, and other common operations in its base. As do many embedded processors. The base is meant to be a lowest common denominator; any hypothetical desktop RISC-V core would almost certainly have all the standard extensions and probably some nonstandard ones. >This is my point as to why RISC-V is just masturbation, and similarly meaningless. I'm really confused why you think having an open ISA standard is "pointless". >but RISC-V can be manufactured to have the same garbage, so it doesn't make a real difference. Literally anything can. >Well, it doesn't let them masturbate themselves You're right, they should be masturbating Donald Knuth instead.

>>52347 >The spec doc explicitly says that extracting the high bits and then low bits of a multiply should result in a single multiply split across two instructions. That instruction combination business is nonsense. >As do many embedded processors. None of this is truly embedded. All of these embedded systems are supercomputers. The term is meaningless due to this nonsense. >The base is meant to be a lowest common denominator; any hypothetical desktop RISC-V core would almost certainly have all the standard extensions and probably some nonstandard ones. Yes, and what a Hell it would so easily become. >I'm really confused why you think having an open ISA standard is "pointless". Several better designs already existed. >You're right, they should be masturbating Donald Knuth instead. He actually knows what he's doing, so yes.

>alternative ISA thread >instant flamewar Only on lainchan

>>52351 yeah lisp has weird and annoying opinions about machine code.