11–20 of 41 posts
x86 has had a good run. But it's time for it to go. I'm hopeful for RISC-V.
Not only Mill, Microsoft has been working on a VLIW too (yes I know, not exactly VLIW, it's close enough).
IMO these ISA's are the future, compilers and programming languages are nowadays smart enough to be able to figure out how to handle VLIW compilation (plus having learned from Itanium's failures).
x86 has had a good run. But it's time for it to go. I'm hopeful for RISC-V.
RISC-V inherited all the bad ideas of x86 by now. It has an SMM equivalent, a separate hypervisor mode (instead of full orthogonality which lets you get away without one), resident firmware code outside the OS' control, ...
The virtualization extension hasn't been finalized (but they are working with key KVM people), but it will perform a lot better than a theoretically pure self-virtualizable ISA.
x86 has had a good run. But it's time for it to go. I'm hopeful for RISC-V.
I'm putting my bets on Mill winning the race eventually. Not only Mill, Microsoft has been working on a VLIW too (yes I know, not exactly VLIW, it's close enough). IMO these ISA's are the future, compilers and programming languages are nowadays smart enough to be able to figure out how to handle VLIW compilation (plus having learned from Itanium's failures).
Not to mention VLIW wastes CPU instruction cache for instructions that aren't ran.
It is no accident that CPUs and compilers gravitated towards RISC.
Earlier quoted context omitted.
I'm putting my bets on Mill winning the race eventually. Not only Mill, Microsoft has been working on a VLIW too (yes I know, not exactly VLIW, it's close enough). IMO these ISA's are the future, compilers and programming languages are nowadays smart enough to be able to figure out how to handle VLIW compilation (plus having learned from Itanium's failures).
No they really cannot. Many of the optimizations CPU do on the fly are akin to JIT recompilers. (in microcode and schedule side) These cannot be effectively done ahead of time yet, at least not without an instruction accurate profiling. Not to mention VLIW wastes CPU instruction cache for instructions that aren't ran. It is no accident that CPUs and compilers gravitated towards RISC.
VLIW also doesn't really waste instruction cache if your compiler is being smart and aligns branches to an instruction word, though you still blow the pipeline on a branch if you miss but atleast in Microsofts case they include a way for the compiler to include a prediction which it is arguably in a better position to make. This goes double if you use profiling-guided optimization. If the claims of the Mill guys are true then even the "wasted CPU instruction cache" doesn't hurt performance.
CPUs and compilers are gravitating towards lots of things. x86 and ARM aren't the only instruction set. VLIW is healthy and very alive on a lot of DSPs. There are Russian CPUs that use VLIWs in active use. AMD GPUs used VLIW for a while (and some variants still do). You can even get VLIW-based Microcontrollers for cheap.
IMO compilers and CPUs may gravitate towards RISC in the shortterm as it is more similar to CISC in terms of complexity. VLIW needs compilers to be smart and languages to be smart too for optimal use. Rust for example would be capable of really taking advantage of VLIW but LLVM doesn't support that complexity (yet, though there is some work).
In the long term, so my prediction, VLIW will dominate by nature of being simpler, faster and more efficient.
Earlier quoted context omitted.
I'm putting my bets on Mill winning the race eventually. Not only Mill, Microsoft has been working on a VLIW too (yes I know, not exactly VLIW, it's close enough). IMO these ISA's are the future, compilers and programming languages are nowadays smart enough to be able to figure out how to handle VLIW compilation (plus having learned from Itanium's failures).
No they really cannot. Many of the optimizations CPU do on the fly are akin to JIT recompilers. (in microcode and schedule side) These cannot be effectively done ahead of time yet, at least not without an instruction accurate profiling. Not to mention VLIW wastes CPU instruction cache for instructions that aren't ran. It is no accident that CPUs and compilers gravitated towards RISC.
Nah. You can have variable length VLIW instructions.
And you can design an out of order VLIW that still has significant advantages at decoding many operations at once.
Earlier quoted context omitted.
Why RISC-V and not e.g. Arm? Why is RISC-V better than x86 from AMD? Serious questions, I have no idea about these topics and would love to learn more.
I believe you have to pay royalties for Arm while RISC-V is completely open source.
Earlier quoted context omitted.
RISC-V inherited all the bad ideas of x86 by now. It has an SMM equivalent, a separate hypervisor mode (instead of full orthogonality which lets you get away without one), resident firmware code outside the OS' control, ...
> separate hypervisor mode RISC-V, without the hypervisor extension, meets the requirements for Popek-Goldberg virtualization, unlike x86. The problem is that classic virtualization requires shadow paging for memory virtualization, which can be slow. The hypervisor extension (not yet finalized) only adds two level nested paging, a few shadow CSRs, and IIRC a few more interrupt handling registers. The hypervisor exten…
Right, I forgot about RISC-V's MSR equivalent - with a worse assembler implementation (though that's simple to fix without touching the ISA) since the standard assembly expects them to be names, not numbers (that can be #defined away to names).
I had a (very emphatically not) fun time updating coreboot's toolchain and code base in lock step to ensure that risc-v code remained compilable when these changed.
...if I have to endure one more abuse of the "considered harmful" idiom, I'm going to puke.