This will be challenging and painful for many of their existing users.
I wish we'd see more architecture-neutral binaries, based on LLVM or webassembly.
Of course, Plan 9/Inferno had it before others: https://en.wikipedia.org/wiki/Limbo_(programming_language)#V...
(By virtue of being designed as a distributed OS, targeting machines with various architectures).
The single whole-bank migration I was involved with was zSeries to zSeries.
This is where the challenger banks really have an advantage. They're not saddled with the baggage of an overnight batch run of JCL decks and Data Sets to arrive at what their regulators consider the reconciled position of the bank.
RISC-V is kinda in a similar situation as ARM. If I were Microsoft, I'd be investing hard into the RISC-V platform as it still has tremendous growth left.
Note there is progress there with things like ARM's ServerReady which standardises a lot. The Windows-on-ARM requirements also push a lot to be far more standardised (it effectively requires a subset of the ServerReady requirements AIUI).
Sadly, RISC-V is not a good candidate for that. It is an excellent ISA for student implementation projects, but not for real work.
RISC-V is praised only by people who have very little or no experience with different CPU ISAs and with the history of their evolution.
RISC-V sucks more than even the ugliest ISA, x86. At least from the huge x86 ISA it is possible to extract a subset composed mostly of more recently introduced instructions, which can be considered as a decent ISA, except for the weird encoding, with many prefix bytes, which is needed for backward compatibility.
The 64-bit ARMv8 ISA is an example of a good ISA, but its future is clouded by the NVIDIA acquisition.
I'm having trouble actually digging up the reference right now, but I've been told that it was specifically built out of decades of industry experience in what works in building processors/ISAs.
> RISC-V sucks more than even the ugliest ISA, x86.
How so?
> At least from the huge x86 ISA it is possible to extract a subset composed mostly of more recently introduced instructions, which can be considered as a decent ISA, except for the weird encoding, with many prefix bytes, which is needed for backward compatibility.
So, exactly like RISC-V base + extensions?
Do you mean device probing? There's a standard API implemented by Linux for the firmware to communicate this to the kernel, also PCI works on ARM just like x86. No one bothers with this because all of the popular ARM SoCs tend to come from organizations that are extremely hostile to their users though.
Do you mean user space ABI? GlibC on arm7 and aarch64 has had a pretty stable ABI for a while now, I can personally share binaries between all my arm machines that share an architecture (not that flinging binaries around is a good thing.)
That's the problem. Most SoC vendors just don't care and implement drivers in or around forks of the kernel, and also specify the hardware via device trees. IIRC having the firmware give the device tree to the kernel instead of it being baked into the kernel is a new development.
If MS came and said: we want stable interfaces, the vendors would buckle and MS would be able to ship one OS image to all devices, instead of having hw custom images.
I really hope Windows on the desktop goes the way of Windows Mobile and Windows Phone.