If you think about it, instruction encoding is really a compression method.
I wonder, if it would make sense to decouple compression and microcodes. So you could take a body of Code and find the best compression for it.
Or even be able to change "lookup tables" before starting the operating system. Possibly have different compression methods (x86 / arm..) run on the same CPU, without any drawbacks. Which could get you around licensing an ISA. (Yes I'm a software engineer thinking about hardware)
The “without any drawbacks” part never panned out, though.
It also is fairly similar to what Apple has done with emulating 68k on PPC, PPC on x64, and x64 on ARM (but those, AFAIK, do not offer full emulation of the host CPU, as they don’t need to run code in kernel mode)
"The jack of all trades is the master of none." Being able to do any type of ISA means you have to put in the circuits to do everything those ISAs can do and those extra circuits are just expensive deadweight when the processor is configured as a specific ISA.
The most interesting concept here (to me) is the idea of taking a variable length instruction set and optionally promising to align instructions. If you did this, the code could switch between dense and wide as it pleased, getting either the best footprint in the instruction cache or allowing extremely wide decode.
I wonder, if it would make sense to decouple compression and microcodes. So you could take a body of Code and find the best compression for it. Or even be able to change "lookup tables" before starting the operating system. Possibly have different compression methods (x86 / arm..) run on the same CPU, without any drawbacks. Which could get you around licensing an ISA. (Yes I'm a software engineer thinking about hardware)