Comment by dfox
7 years ago
Actually it would be fourth time around, as the K7 Athlons/Thunderbirds were electrically compatible with Alpha 21264, although OK, it was not pin nor mechanically compatible as Alpha CPUs need additional directly attached serial (EE)PROM with boot PALcode/microcode/firmware/initial contents of L2 cache. On the other hand on typical lowend Alpha systems this PROM contained complete enought i386 emulator that it could run PC-style BIOS as part of hardware initialization (ie. work with ISA/PCI cards with x86 code in PROMs), somewhat ugly and scary is the fact that large part of the firmware variant needed for booting Windows NT was actually i386 code running in said emulator. (And then there is Linux, which in the somewhat Tour de force way does not care about the underlying PALcode API)
--- ) Alpha is to a large extent the ultimate RISC architecture that on the user side does not have any implicit sideefects of instructions and syscalls and interrupts work by simply exchanging two register sets. The idea is that there is PALcode which is the only privileged code running on the CPU, which then keeps track of whether whatever is currently running in userspace is user or kernel code and passes messages between these, to some extent it is microkernel as part of the CPU, which you additionally can as an OS modify (in reality you could not, because the PALcode is amalgamation of both the OS semantics, quirks of the actual CPU implementation and the actual motherboard in given system)
RISC-V is very VERY close to Alpha in this respect. There are no flags, everything is communicated via registers (which makes semantics clean and dynamic scheduling cheaper), and the equivalent of PALcode exist (called platform specific SBI calls, executing in M-mode).
IMhO, RISC-V is slightly better than Alpha on a many fronts: the conditional branches which compares two registers would take two instructions on Alpha (on the critical path), RISC-V code density is better with compressed, the encoding is slightly cheaper for hardware, it ISA is more forward-looking/extensible, oh and it's open of course. The only thing I miss are the POPC/CTZ/CLZ instructions, but the B set will include them for implementations that have it.
UPDATE: more RISC-V upsides
Also, RISC-V hasn't been bought, litigated, and buried. Alpha is great, but we're about as likely to get new implementations of it at this point as we are of the 6809 or v20.
RISC-V's future is looking better and better. Who knows? Maybe TSMC or Samsung or one of the smaller fabs puts out a multicore version on a fairly modern process node and gets a multi-player motherboard market built in Taipei, Seoul, and Shenzen. It could be a player in laptops, desktops, tablets, and mobile rather than just embedded and SBCs. It could even be done without a premium going to Intel, AMD, ARM, nVidia, TI, Freescale, or IBM. The possibilities are exciting, because every time I hear about this ISA and its implementations it's better news.
I was under the impression that Linux did care about the underlying PALcode, requiring the version originally meant for Tru64?
IIRC it is slightly more complex: the Tru64 callPAL API is the common subset of all the three variants (VMS/Tru64/NT), but the NT/AlphaBIOS has slightly incompatible ABI which Linux can detect and work around. And also IIRC original Linux port to Alpha expected the NT PALcode, which makes sense given the fact that DEC sold systems that didn't have SRM in PROM (ie. Multia and a-series PWS) and thus only supported NT or Linux.