> Another example is that Apple's M1 proves that wider frontends are possible in traditional architectures, as long as the instruction size is fixed.
Doesn't the M1 prove that you can transpile code from one architecture to another and gain performance benefits? As in, Rosetta code works at comparable or better speed at far lower power consumption?
The original Rosetta used the same underlying tech with the exception of the memory model stuff, but Transmeta never had to deal with that since they only handled single cores. (And Sparc shipped TSO/WMO switch from a control register all the way back in the mid 90s).
Programmer's got cut off from the microcode starting in the 80s, had this not been the case, I think we would have seen more activity lower in the stack.
ISA lockin is a much smaller issue now.
DAISY https://www.microarch.org/micro33/tutorial/tutorial.html
FX!32 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.2...
I've recently been studying AM2900 (bit-slice) processor design. There are still people out there putting microcoded systems together on FPGAs!
I am investigating it, because I think there might be some useful design aspects that could be re-used, but mostly out of retro computing interest :)
https://en.wikipedia.org/wiki/AMD_Am2900#Members_of_the_Am29...
There are two other branches of system design which are really interesting
* CGRAs, Course Grain Reconfigurable Architecture [1]
* FPGA Overlays [2]
[2] https://ieeexplore.ieee.org/abstract/document/6239797 https://www.seekdl.org/conferences/paper/details/9227 https://www.semanticscholar.org/paper/An-efficient-FPGA-over...
To see if it, against the odds, can provide some significant benefit or not. The proof is in the pudding, I hope they get to make the pudding.
The change happened, but not as fast as we would like it to.
They have some cool ideas, but many are incompatible with existing software, e.g. all the memory protection stuff. Other ideas like how memory loads work could be integrated (and have been in place in GPUs for a long time, though not in CPUs) but still depend on compiler changes, which presumably they've done, but past experience with hardware projects that rely on compiler changes is that the compiler changes aren't performing well enough in practice. Or perhaps compilers improve so slowly that traditional architectures can easily absorb the ideas in time.
Another example is that Apple's M1 proves that wider frontends are possible in traditional architectures, as long as the instruction size is fixed. There's no particular reason to believe that the Mill would be inherently better at this than a traditional architecture.
If you have a lay person's interest in hardware architecture and haven't looked at their docs yet, do so. The ideas will likely tickle your brain in a good way -- they did for me. But don't expect much, if anything, from them in production.