5 ms·

I think fragmentation is grossly exaggerated. Or at least, its effects are. It’s not like there’s a single universal ARM binary you can build and run on every S

by shash 4y ago

I think fragmentation is grossly exaggerated. Or at least, its effects are. It’s not like there’s a single universal ARM binary you can build and run on every SoC. At the very least the memory map will be different, the specifics of how peripherals behave is different, and often there are very vendor specific tool chains you need. x86 is different of course but there are two major x86 chip vendors after all. We can take some lessons from Linux fragmentation - real and imagined - to see where all this will end up. Some things are still distribution specific but a lot of things like the FHS are indeed quite standardised. I think that’s where we will end up with RISC-V. Vector is a very obvious place for fragmentation for two reasons; it’s only been a short time since it was ratified, so many of the implementations will be pure ratification, and since it constitutes many players’ competitive advantage they will tend to make it closed and proprietary.

mfuzzey 4y ago
>It’s not like there’s a single universal ARM binary you can build and run on every SoC. That depends how widely you define SoC and what level of "binary" you mean. For example a Linux userspace binary compiled for arm-linux-eabihf will run on most 32 bit ARM systems out there today and there is another one for 64 bit aarch64. So yes, it's not a universal ARM binary but its a long long way from being SoC specificic. Vendor specific toolchains on ARM are pretty uncommon in my experience (they used to be a thing on old 8 bit MCUs). Sure the memory map and peripherals do differ between SoCs but, under Linux at any rate, that is only a problem for the kernel and you can actually build a kernel that will run on multiple SoCs as long as they have the same ISA (by building the different drivers as module and suppling the appropriate DT.) I regularly run the same userspace root filesystem (and in fact the same kernel except for DT) on multiple ARM v7 SoCs.
ip26 4y ago
Fragmentation is often cited as a fundamental cause of Android’s shortfalls, which doesn’t seem like a minor impact. Fragmentation turns out OK when there are strong convergent forces pruning unsuccessful branches or pulling them back into the fold. This can even be good, because you can experiment & evolve. However, when various implementations are comparable yet different in a hundred little ways, neither is selected against and the problem sprawls. It remains to be seen whether there are any strong reconvergent forces acting on RISC-V.
- snvzz 4y ago
  >However, when various implementations are comparable yet different in a hundred little ways, neither is selected against and the problem sprawls. Only RISC-V can ratify specs. And yet, hardware implementations are desirable for testing specs before ratification. Chips that have non-standard extensions will run code built for the standard specs that they implement just fine.

by shash 4y ago

mfuzzey 4y ago

>It’s not like there’s a single universal ARM binary you can build and run on every SoC. That depends how widely you define SoC and what level of "binary" you mean. For example a Linux userspace binary compiled for arm-linux-eabihf will run on most 32 bit ARM systems out there today and there is another one for 64 bit aarch64. So yes, it's not a universal ARM binary but its a long long way from being SoC specificic. Vendor specific toolchains on ARM are pretty uncommon in my experience (they used to be a thing on old 8 bit MCUs). Sure the memory map and peripherals do differ between SoCs but, under Linux at any rate, that is only a problem for the kernel and you can actually build a kernel that will run on multiple SoCs as long as they have the same ISA (by building the different drivers as module and suppling the appropriate DT.) I regularly run the same userspace root filesystem (and in fact the same kernel except for DT) on multiple ARM v7 SoCs.

ip26 4y ago

Fragmentation is often cited as a fundamental cause of Android’s shortfalls, which doesn’t seem like a minor impact. Fragmentation turns out OK when there are strong convergent forces pruning unsuccessful branches or pulling them back into the fold. This can even be good, because you can experiment & evolve. However, when various implementations are comparable yet different in a hundred little ways, neither is selected against and the problem sprawls. It remains to be seen whether there are any strong reconvergent forces acting on RISC-V.

snvzz 4y ago
>However, when various implementations are comparable yet different in a hundred little ways, neither is selected against and the problem sprawls. Only RISC-V can ratify specs. And yet, hardware implementations are desirable for testing specs before ratification. Chips that have non-standard extensions will run code built for the standard specs that they implement just fine.