The thing that really killed plain vanilla RISC is memory latency. Compared to on-die registers and cache memory might as well be disk. True RISC is more effici

The thing that really killed plain vanilla RISC is memory latency. Compared to on-die registers and cache memory might as well be disk. True RISC is more efficient to execute but it results in more instructions and hence more code that has to be read from RAM. Modern CISC chips that immediately unpack CISC into RISC micro-ops are really something that I've termed "ZISC" -- Zipped Instruction Set Computing. Think of CISC ISA's like the byzantine x86_64 ISA with all its extensions as a custom data compression codec for the instruction stream. We got ZISC accidentally and IMHO without us realizing what we'd actually done. The x86_64 "codec" was not explicitly designed as such but resulted from a very path-dependent "evolutionary walk" through ISA design space. I wonder what would happen if we explicitly embraced ZISC and designed a custom codec for a RISC stream that can be decompressed very efficiently in hardware? Maybe the right approach would be a CPU with hundreds of "macro registers" that store RISC micro-op chunks. The core instruction set would be very parsimonious, but almost immediately you'd start defining macros. Of course multitasking would require saving and restoring these macros which would be expensive, so a work-around for that might be to have one or maybe a few codecs system-wide that are managed by the OS rather than by each application. This would make macro redefinition rare. Apps are compiled into domain specific instruction codec streams using software-defined codec definitions managed by the OS. The neat thing about this hypothetical ZISC is that while 99% of apps might use the standard macro set you could have special apps that did define their own. These could be things like cryptographic applications, neural networks, high performance video encoders, genetic algorithms, graphics renderers, cryptocurrency miners, etc. Maybe the OS would reserve a certain number of macros for user application use.