6 ms·

ARM is very old as well and has plenty of technical debt. RISCV, on the other hand...

by bcatanzaro 6y ago

mikece 6y ago
What do you suppose the chances are of Apple compiling/running iOS and macOC on RISCV?
- pram 6y ago
  zero percent
- dathinab 6y ago
  Closer to zero, it's an open architecture something the king of walled gardens wouldn't touch from a mile away. ;=) Jokes aside the real reason why it's extremely unlikely is that they put a lot of money into ARM and they simply have no reason to switch to it. For this to happen ARM would need to do something like massively increase the price of their IP licenses, or simila. Which won't happen.
- monocasa 6y ago
  Apple has even a less incentive then most to support RISC-V versus ARM. They were a super early investor in ARM back in the early 90s (to the point where ARM probably wouldn't exist today without Apple). I'd be surprised if they pay more than a token amount for their core licenses. For all intents and purposes, RISC-V being open just puts it on the same footing for Apple as ARM is for them.
monocasa 6y ago
AArch64 is pretty clean. I'd be surprised if their cores ran AArch32.
- saagarjha 6y ago
  Apple’s? They don’t.
Jasper_ 6y ago
RISC-V is basically a nonstarter. It has a lot of ridiculously goofy decisions in its ISA, it doesn't seem like competent CPU nor compiler engineers were ever in the loop for its design, and the number one benefit seems to be the licensing terms that make it super easy to extend or even replace 90% of the ISA while still calling it "RISC-V".
- monocasa 6y ago
  Can you enumerate some of these goofy decisions?
  - Jasper_ 6y ago
    Sure. The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing. Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA. Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the source and destination addresses. But for branch prediction reasons, and prefetching, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance". There's a lot more that I can go into.
    - monocasa 6y ago
      > The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing. Those use cases work just fine with the shifts and adds trick you can do for multiply by constant. Honestly I was always baffled that ARMv6-M required a multiplier. Seemed to be the closest thing to an albatross over it's head, so much so that there were those M0's with an iterative, 32 cycle latency, bit serial multiplier. > Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA. ARMv7-M (the closest ISA to Rv32-EM) requires integer divide. > Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the return address. But for branch prediction reasons, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance". I don't really see this as a problem. For instance it neatly encodes unconditional jump without link as a jump with link to x0. Reminds me of some of the cute ways to encodes jumps from SH without being quite as ascetic. > There's a lot more that I can go into. Please do. Like totally unironically. I obviously have a pretty high opinion of RISC-V, but I appreciate someone who helps keep my biases in check.
klelatti 6y ago
Any ARM CPU that Apple uses in Macs will almost certainly be 64 bit A64 only - A64 is the only instruction set that has been supported on Apple SoC's since the A11 in 2017. A64 is part of ARMv8 which was announced in October 2011 and was a brand new instruction set. It is not compatible with legacy 32 bit ARM applications and doesn't carry the relevant technical debt. RISC-V was announced in 2010. It may have many admirable qualities but claiming that it has the advantage of a newer architecture is not correct in this context. Incidentally, I think one of the remarkable features of ARM's recent commercial success - generally completely unremarked on - is how they have, relatively seamlessly, switched users from legacy 32 bit to an new 64 instruction set.

ARM is very old as well and has plenty of technical debt. RISCV, on the other hand...

mikece 6y ago

What do you suppose the chances are of Apple compiling/running iOS and macOC on RISCV?

pram 6y ago
zero percent
dathinab 6y ago
Closer to zero, it's an open architecture something the king of walled gardens wouldn't touch from a mile away. ;=) Jokes aside the real reason why it's extremely unlikely is that they put a lot of money into ARM and they simply have no reason to switch to it. For this to happen ARM would need to do something like massively increase the price of their IP licenses, or simila. Which won't happen.
monocasa 6y ago
Apple has even a less incentive then most to support RISC-V versus ARM. They were a super early investor in ARM back in the early 90s (to the point where ARM probably wouldn't exist today without Apple). I'd be surprised if they pay more than a token amount for their core licenses. For all intents and purposes, RISC-V being open just puts it on the same footing for Apple as ARM is for them.

monocasa 6y ago

AArch64 is pretty clean. I'd be surprised if their cores ran AArch32.

saagarjha 6y ago
Apple’s? They don’t.

Jasper_ 6y ago

RISC-V is basically a nonstarter. It has a lot of ridiculously goofy decisions in its ISA, it doesn't seem like competent CPU nor compiler engineers were ever in the loop for its design, and the number one benefit seems to be the licensing terms that make it super easy to extend or even replace 90% of the ISA while still calling it "RISC-V".

monocasa 6y ago
Can you enumerate some of these goofy decisions?
- Jasper_ 6y ago
  Sure. The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing. Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA. Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the source and destination addresses. But for branch prediction reasons, and prefetching, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance". There's a lot more that I can go into.
  - monocasa 6y ago
    > The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing. Those use cases work just fine with the shifts and adds trick you can do for multiply by constant. Honestly I was always baffled that ARMv6-M required a multiplier. Seemed to be the closest thing to an albatross over it's head, so much so that there were those M0's with an iterative, 32 cycle latency, bit serial multiplier. > Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA. ARMv7-M (the closest ISA to Rv32-EM) requires integer divide. > Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the return address. But for branch prediction reasons, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance". I don't really see this as a problem. For instance it neatly encodes unconditional jump without link as a jump with link to x0. Reminds me of some of the cute ways to encodes jumps from SH without being quite as ascetic. > There's a lot more that I can go into. Please do. Like totally unironically. I obviously have a pretty high opinion of RISC-V, but I appreciate someone who helps keep my biases in check.

klelatti 6y ago

Any ARM CPU that Apple uses in Macs will almost certainly be 64 bit A64 only - A64 is the only instruction set that has been supported on Apple SoC's since the A11 in 2017. A64 is part of ARMv8 which was announced in October 2011 and was a brand new instruction set. It is not compatible with legacy 32 bit ARM applications and doesn't carry the relevant technical debt. RISC-V was announced in 2010. It may have many admirable qualities but claiming that it has the advantage of a newer architecture is not correct in this context. Incidentally, I think one of the remarkable features of ARM's recent commercial success - generally completely unremarked on - is how they have, relatively seamlessly, switched users from legacy 32 bit to an new 64 instruction set.