371–380 of 480 posts
What does all this have to do with Intel and AMD calling a truce?
Earlier quoted context omitted.
> Yeah, it's a little harder than for pure fixed-width Arm64, but it is massively massively easier than for amd64. For those who haven't read the details of the RISC-V ISA: the first two bits of every instruction tell the decoder whether it's a 16-bit or a 32-bit instruction. It's always in that same fixed place, there's no need to look at any other bit in the instruction. Decoding the length of a x86-64 instruction…
Why do they use two bits for it? Do they plan to support other instruction lengths in the future?
To increase the number of 16-bit instructions. Of the four possible combinations of these two bits, one indicates a 32-bit or longer instruction, while the other three are used for 16-bit instructions.
> Do they plan to support other instruction lengths in the future?
They do. Of the eight possible combinations for the next three bits after these two, one of them indicates that the instruction is longer than 32 bits. But processors which do not know any instruction longer than 32 bits do not need to care about that; these longer instructions can be naturally treated as if they were an unknown 32-bit instruction.
On mobile devices efficiency is so important, I don't see how Qualcomm would be able to live without ARM licences. RISC-V and other architectures like x86-64 are nice, actually I think the peripheral libraries, boot and stuff like that are bigger headache to replace for Qualcomm's clients given that they can just switch the gcc to a different arch - still if your code is 25% less efficient, that'll be quite noticable…
Earlier quoted context omitted.
That is a good comment, and I agree things like CSR differences could be annoying, but compared to the engineering challenges of designing the Oryon cores from scratch… I still think the scope of work would be relatively small. I just don’t think Qualcomm seriously wants to invest in RISC-V unless ARM forces them to.
> I just don’t think Qualcomm seriously wants to invest in RISC-V unless ARM forces them to. That makes a lot of sense. RISC-V is really not at all close to being at parity with ARM. ARM has existed for a long time, and we are only now seeing it enter into the server space, and into the Microsoft ecosystem. These things take a lot of time. > I still think the scope of work would be relatively small I'm not so sure ab…
Why do you say this?
Earlier quoted context omitted.
> I just don’t think Qualcomm seriously wants to invest in RISC-V unless ARM forces them to. That makes a lot of sense. RISC-V is really not at all close to being at parity with ARM. ARM has existed for a long time, and we are only now seeing it enter into the server space, and into the Microsoft ecosystem. These things take a lot of time. > I still think the scope of work would be relatively small I'm not so sure ab…
> verification of a very high-powered RISC-V core that is going to be manufactured in high-volume is probably much more expensive and time-consuming than the case for an ARM design. Why do you say this?
- People who have been working with spec and technology for decades
- People who have implemented ARM machines in fancy modern CMOS processes
- Stable and well-defined specifications
- Well-understood models, tools, strategies, wisdom
I'm not sure how much of this exists for you in the RISC-V space: you're probably spending time and money building these things for yourself.
Earlier quoted context omitted.
The Qualcomm online defenders are something else too. Qualcomm have been acting badly for years, including attempting to turn RISC-V into Arm64 but without the restrictions. You cannot trust people that behave like this, where everything they do is important and everything you do is worthless. The funny thing is Qualcomm do have some wildly impressive tech which is kept secret despite being so ubiquitous, but they ha…
> throwing their partners under the bus I found it telling that every single smartphone vendor refused to license Qualcomm's proprietary tech for smartphone to satellite messaging. > In a statement given to CNBC, Qualcomm says smartphone makers “indicated a preference towards standards-based solutions” for satellite-to-phone connectivity https://arstechnica.com/gadgets/2023/11/qualcomm-kills-its-c...
Usually that gun is the latest wireless standard like 4g or 5g.
Earlier quoted context omitted.
Aren’t Android binaries in Dalvik so you only need to port that to get it to run on RISC-V?
Many games, multimedia apps (native FFMPEG libs), and other apps that require native C/C++ libs would require a recompile/translation for RISC-V.
Earlier quoted context omitted.
> attempting to turn RISC-V into Arm64 but without the restrictions This flew past me, do you have a link?
Brucehoult mentions it further down. > This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that…
Earlier quoted context omitted.
It's a Cortex-M33, a 32bit microcontroller core with no virtual memory. Are we really comparing microcontrollers to modern aarch64 processors?
Yes? Because nobody has released a RISC-V MPU comparable to what you perceive as "moden" arm64 MPUs. RISC-V is simply a ISA and not a core. The ISA affects some of the core architecture but the rest is also implementor specific. High-end cores will take time to reach market. Companies with big guns like Qualcomm can most likely pump out if they wanted to, and will most likely be doing so in the future since they are…
And it's not been proven that RISC-V is a good match for the second group (yet).
Remember it's sometimes very non-obvious what quirks of an ISA might be difficult until you actually try to implement it - one of the reasons ARM had a pretty much "clean sheet" rewrite in ARMv8 is things like the condition codes turned out to be difficult to manage in wide superscalar designs with speculative execution - which is exactly the sort of thing required to meet the "laptop-tier" design performance requirements.
It may be they've avoided all those pitfalls, but we don't really know until it's been done.
Earlier quoted context omitted.
Qualcomm's migration would be much easier than Apple's. Most of the Android ecosystem already runs on a VM, Dalvik or whatever it's called now. I'm sure Android RISC-V already runs somewhere and I don't see why it would run any worse than on ARM as long as CPUs have equal horsepower.
Yeah, but Qualcomm doesn’t control Android or any of the phone makers. It’s hard for large corps to achieve the internal coordination necessary for a successful ISA change (something literally only Apple has ever accomplished), but trying to coordinate with multiple other large corps? Seems insane. You’re betting your future on the fact that none of the careerists at Google or Samsung get cold feet and decide to just…