3 ms·

I don't think that makes sense. RISC-V is by definition a new ISA, M1 is based on the existing ARM ISA.

by leonidbelyaev 3y ago

gumby 3y ago
That transition was from x86 to ARM. This is ARM to RISC V.
- spookie 3y ago
  From a mature architecture to another, versus going to a "pretty much only used on embedded devices" arch? Yeah, they really have got their work cut out for themselves!
  - IshKebab 3y ago
    Android phones are pretty much embedded devices though (unfortunately) so I suspect we'll see a load of phones that have super custom kernels with tons of hard-coded driver configs etc. Similar to SBC other than the RPi. It's kind of an issue for ARM too but they're a bit further towards solving it than RISC-V. In any case it's mainly a problem for people that want OS updates or the ability to install other OSes, so it's not going to affect app writers or normal users much.
    - snvzz 3y ago
      >It's kind of an issue for ARM too but they're a bit further towards solving it than RISC-V. Can you elaborate on why you think so? I understand it is the opposite: RISC-V is much further towards solving it. This is because RISC-V has put effort from the start into standardizing boot process (spl -> sbi -> uboot|uefi), ISA (profiles), the firmware-kernel interface (sbi, uefi protocol, acpi) as well as the platform itself (platform spec, standards for interrupts, timers, hypervisor support, the uart requirement, the watchdog and further platform standardization efforts). This has happened (and is happening still) before significant deployment of SoCs using RISC-V microarchitectures as the application processor. Meanwhile, ARM realized, quite late, that this is important, and is lagging behind, with plenty of non-fixable, bespoke platform hardware deployed, and low vendor uptake as they are asking their clients to change what they already have in place.
      - ryukafalz 3y ago
        I haven't been keeping up to date with RISC-V happenings lately but does this imply that it'll be easier for distros to have live images that can install to arbitrary RISC-V machines like we're used to on x86? If so, that's exciting!
        snvzz 3y ago
        >it'll be easier for distros to have live images that can install to arbitrary RISC-V machines like we're used to on x86? Yes. The experience will be equal or better over the IBM PC-derived platform, by design. PC was an accidental platform, RISC-V platform spec is an intentional (and very informed) one.
  - brucehoult 3y ago
    Pretty bad take given that Android recently transitioned from 32 bit ARM to 64 bit ARM, which are essentially totally different ISAs and 64 bit ARM was used in absolutely nothing at all before Phones -- iPhone 5s first, then Android a couple of years later with e.g. Galaxy S6. The one advantage that transition had was that the same CPU could run both ISAs -- something ARM has dropped in their latest (and all future) 64 bit-only CPU cores. And for some time now apps could still be 32 bit but the OS had to be 64 bit. A transition to RISC-V will be cold turkey. It's technically possible of course to build one CPU that can run both A64 and RV64, but only ARM can legally do it, and they probably won't unless they're really losing, sometime 5 or 10 years from now.

I don't think that makes sense. RISC-V is by definition a new ISA, M1 is based on the existing ARM ISA.

gumby 3y ago

That transition was from x86 to ARM. This is ARM to RISC V.

spookie 3y ago
From a mature architecture to another, versus going to a "pretty much only used on embedded devices" arch? Yeah, they really have got their work cut out for themselves!
- IshKebab 3y ago
  Android phones are pretty much embedded devices though (unfortunately) so I suspect we'll see a load of phones that have super custom kernels with tons of hard-coded driver configs etc. Similar to SBC other than the RPi. It's kind of an issue for ARM too but they're a bit further towards solving it than RISC-V. In any case it's mainly a problem for people that want OS updates or the ability to install other OSes, so it's not going to affect app writers or normal users much.
  - snvzz 3y ago
    >It's kind of an issue for ARM too but they're a bit further towards solving it than RISC-V. Can you elaborate on why you think so? I understand it is the opposite: RISC-V is much further towards solving it. This is because RISC-V has put effort from the start into standardizing boot process (spl -> sbi -> uboot|uefi), ISA (profiles), the firmware-kernel interface (sbi, uefi protocol, acpi) as well as the platform itself (platform spec, standards for interrupts, timers, hypervisor support, the uart requirement, the watchdog and further platform standardization efforts). This has happened (and is happening still) before significant deployment of SoCs using RISC-V microarchitectures as the application processor. Meanwhile, ARM realized, quite late, that this is important, and is lagging behind, with plenty of non-fixable, bespoke platform hardware deployed, and low vendor uptake as they are asking their clients to change what they already have in place.
    - ryukafalz 3y ago
      I haven't been keeping up to date with RISC-V happenings lately but does this imply that it'll be easier for distros to have live images that can install to arbitrary RISC-V machines like we're used to on x86? If so, that's exciting!
      - snvzz 3y ago
        >it'll be easier for distros to have live images that can install to arbitrary RISC-V machines like we're used to on x86? Yes. The experience will be equal or better over the IBM PC-derived platform, by design. PC was an accidental platform, RISC-V platform spec is an intentional (and very informed) one.
- brucehoult 3y ago
  Pretty bad take given that Android recently transitioned from 32 bit ARM to 64 bit ARM, which are essentially totally different ISAs and 64 bit ARM was used in absolutely nothing at all before Phones -- iPhone 5s first, then Android a couple of years later with e.g. Galaxy S6. The one advantage that transition had was that the same CPU could run both ISAs -- something ARM has dropped in their latest (and all future) 64 bit-only CPU cores. And for some time now apps could still be 32 bit but the OS had to be 64 bit. A transition to RISC-V will be cold turkey. It's technically possible of course to build one CPU that can run both A64 and RV64, but only ARM can legally do it, and they probably won't unless they're really losing, sometime 5 or 10 years from now.