As a fellow risc-v supporter, I think the rise of arm is going to help risc-v software support and eventually adoption. They’re not compatible, but right now developers everywhere are working to ensure their applications are portable and not tied to x86. I imagine too that when it comes to emulation, emulating arm is going to be a lot easier than x86, possibly even statically recompilable.
This is what concerns me. ARM could dominate the market because almost everyone would develop apps supporting it and leave RISC-V behind. It could become like Itanium vs AMD64 all over again.
Well right now most people develop apps supporting x86 and leaves everything else behind. If they’re supporting x86 + arm, maybe adding riscv as a third option would be a smaller step than adding a second architecture
Porting Windows exclusive games to Linux is a small step as well, but most developers don’t do it because they cannot justify the additional QA and debugging time required to port them over. Especially since Linux’s market share is small.
The reason Itanium failed was because the architecture was too different from x86 and porting x86 applications over required significant effort and was error prone.
For RISC-V to even get any serious attention from developers, I think they need to have appx 40-50% market share with OEMs alongside ARM. Otherwise, RISC-V will be seen as a niche architecture and developers would avoid porting their applications to it.
My point is that “porting” is not such a big deal if it is just recompile. If you already target Linux with a portable code base ( to support both ARM and amd64 for example ) then the burden of RISC-V is pretty low. Most of the support will be the same between RISC-V and ARM if they target the same Linux distros.
The Linux distros themselves are just a recompile as well and so the entire Open Source ecosystem will be available to RISC-V right away.
It is a very different world from x86 vs Itanium with amd64 added to the mix.
Look at Apple Silicon. Fedora already has a full distribution targeting Apple Silicon Macs. The biggest challenges have been drivers, not the ISA. The more complete the Linux ecosystem is on ARM, the easier it will be to create distros for RISC-V as well.
Porting Windows games to Linux is not a small step. It is massive and introduces a huge support burden. That is much different than just recompiling your already portable and already Linux hosted applications to a new arch.
With games, I actually hope the Win32 API becomes the standard on Linux as well because it is more stable and reduces the support burden on game studios. It may even be ok if they stay x86-64. Games leverage the GPU more than the CPU and so are not as greatly impacted running the CPU under emulation.
That is a risk on the Windows side for sure. Also, once an ISA becomes popular ( like Apple Silicon ) it will be hard to displace.
Repurposing Linux software for RISC-V should be easy though and I would expect even proprietary software that targets Linux to support it ( if the support anything beyond x86-64 ).
Itanium was a weird architecture and you either bet on it or you did not. RISC and ARM are not so different.
The other factor is that there is a lot less assembly language being used and, if you port away from x64, you are probably going to get rid of any that remains as part of that ( making the app more portable ).
Once a chip architecture gets popular on Windows, it will be hard to displace. ARM has already become popular on macOS ( via Apple Silicon ) so we know that is not going anywhere. If ARM becomes popular on Windows ( perhaps via X Elite ), it will be hard to displace as the more popular option. That makes RISC-V on Windows a more difficult proposition.
I do not think that RISC-V on Linux has the same obstacles other than that most hardware will be manufactured for Windows or Mac and will use the chips popular with those operating systems.
Its a small company without VC, seems ok so far. Chinese track record for open sourcing things isnt too good because chinese courts dont care about the GPL I think, however they sound like linux enthusiasts, so Im optimistic.
Is that a developer licence thing? I know GitHub recently announced Windows Arm runners that would be available to non-teams/enterprise tiers later this year.
It isn’t as simple as just compiling. Large programs like games then need to be tested to make sure the code doesn’t have bugs on ARM. Developers often use assembly to optimize performance, so those portions would need to be rewritten as well. And Apple has been the only large install of performant ARM consumer hardware on anything laptop or desktop windows. So, there hasn’t been a strong install base to even encourage many developers to port their stuff to windows on ARM.
Yeah this has been our (well, my) statement on requests to put out ARM binaries for Pulsar. Typically we only put binaries out for systems we actually have within the team so we can test on real hardware and replicate issues. I would be hesitant to put out Windows ARM builds when, as far as I know, we don’t have such a device. If there was a sudden clamouring for it then we could maybe purchase a device out of the funds pot.
The reason I was asking more about if it was to do with developer licences is that we have already dealt with differences between x86 and ARM macOS builds because the former seems to happily run unsigned apps after a few clicks, where the latter makes you run commands in the terminal - not a great user experience.
That is why I was wondering if the ARM builds for Windows required signing else they would just refuse to install on consumer ARM systems at all. The reason we don’t sign at the moment is just because of the exorbitant cost of the certificates - something we would have to re-evaluate if signing became a requirement.
It doesn’t usually work that well in practice. I have been running an M1 MBA for the last couple years (asahi Arch and now Asahi Fedora spin). More complex pieces of software typically have build system and dependencies that are not compatible or just make hunting everything down a hassle.
That said there is a ton of software that is available for arm64 on Linux so it’s really not that bad of an experience. And there are usually alternatives available for software that cannot be found.
I can’t say I’m one who shares that sentiment seeing as the only two projects I’m involved with happen to be Electron based (by chance rather than intention). Hell, one of them is Pulsar which is a continuation of Atom which literally invented Electron.
Until risc-v is at least as performant as top of the line 2 year old hardware it isn’t going to be of interest to most end users. Right now it is mostly hobbyist hardware.
I also think a lot of trust if being put into it that is going to be misplaced. Just because the ISA is open doesn’t mean anything about the developed hardware.
RISC-V is currently already being used in MCUs such as the popular ESP32 line. So I’d say it’s looking pretty good for RISC-V. Instruction sets don’t really matter in the end though, it’s just licensing. It’s not like you’ll be able to make a CPU or even something on the level of old 8-bit MCUs at home any time soon and RISC-V IC designs are typically proprietary too.
RISC-V is currently already being used in MCUs such as the popular ESP32 line. So I’d say it’s looking pretty good for RISC-V. Instruction sets don’t really matter in the end though, it’s just licensing for the producer to deal with. It’s not like you’ll be able to make a CPU or even something on the level of old 8-bit MCUs at home any time soon and RISC-V IC designs are typically proprietary too.
Thinking about it, the SoC idea could stop at the southern boundary of the chipset in x86 systems.
Include DDR memory controller, PCI controller, USB controllers, iGPU’s etc. most of those have migrated into x86 CPU’s now anyway (I remember having north and south bridge chipsets!)
Leave the rest of the system: NIC’s, dGPU’s, etc on the relevant busses.
I’m both surprised and not surprised that ever since the M1, Intel seems to just be doing nothing in the consumer space. Certainly losing their contract with Apple was a blow to their sales, and with AMD doing pretty well these days, ARM slowly taking over the server space where backwards compatibility isn’t as significant, and now Qualcomm coming to eat the windows market, Intel just seems like a dying beast. Unless they do something magical, who will want an Intel processor in 5 years?
I haven’t wanted an Intel processor for years. Their “innovation” is driven by marketing rather than technical prowess.
The latest batch of 13900k and again with 14900k power envelope microcode bullshit was the final “last” straw.
They were more interested in something they could brand as a competitor to ryzen. Then left everyone who bought one (and I bought three at work) holding the bag.
We’ve not made the same mistake again.
Intel dying and its corpse being consumed by its competitors is a fairy tale ending.
I also haven’t wanted an Intel processor in a while . They used to be best in class for laptops prior to the M1, but they’re basically last now behind Apple, AMD, Qualcomm. They might win in a few specific benchmarks that matter very little to people, and are still the default option in most gaming laptops. For desktop use the Ryzen family is much more compelling. For servers they still seem to have an advantage but it’s also an industry which requires longer term contracts that Intel has the infrastructure for more so than it’s competitors, but ARM is also gaining ground there with exceptional performance per watt.
The lad is concerned for his privacy, how come the word traitor has ever appeared in your comment at all?! I surely hope you had completely changed topics by then, and replied to the wrong comment.
Kaspersky reported a major iOS exploit to Apple in recent years. They discovered it and helped unravel the details of how it worked. I understand the US decision, but it seems unlikely that they’re bad actors through and through. I guess the Russian state could lean on them to do their bidding though and that potential is enough to consider them a threat.
Amazing how long it took them to figure out that this is an actual risk. Now if they actually want to mitigate risks for the people on the net, they should make the software vendors out there fix the gaping security holes that their three-letter agencies are hoarding for their own gains.
Inherently, even if they proved themselves to be bad actors in the worst way, the US would be unable to prosecute them. I don’t know that it justifies an embargo, but, as el reg notes, it’s not like this move hasn’t been telegraphed for over 5 years now.
theregister.com
Active