It's not just that the RISC philosophy became popular, but suddenly it didn't make much sense to design a CISC ISA anymore.
CISC was a great idea when you had really slow and narrow RAM. It made sense to try and make each instruction as short and powerful as possible, usually using microcoded routines. But RAM got cheaper, buses got wider and caches started being a thing. It didn't make any sense to waste transistors on microcode, just put them all in RAM.
The appeal of CISC instruction sets when marketing to programmers lies in their batteries-included stance: they handle more of the binary encoding stuff for you, more of the math operations. With a RISC approach they have to write library code to do the same tasks, which adds some implementation complexity as well as potentially being most of the size of a short program. And that makes sense - if you expect direct instruction encoding to be the whole programming environment, which, for the first computers, it had to be.
By the time you get to the microcomputer era the balance had shifted pretty resoundingly towards working at a higher level - that's why nearly every machine of that generation had a BASIC, and if you have a BASIC it's more important for the instruction set to be efficient, because efficiency becomes the only reason to drop down from a high level environment.
https://www.renesas.com/us/en/products/microcontrollers-micr...
There is also MSP430, a 16 bit microcontroller that is pretty much a PDP-11 with the register set increased from 8 to 16 (4 bit field instead of 3) by reducing the number of addressing modes from 8 (3 bit field for each operand) to 4 for the src operand and 2 for the dst operand. This also gives 1 extra bit for the opcode field.
Incidentally, the M68000 is itself pretty much a 32 bit PDP-11 with the register set increased from 8 to 16 by differentiating D and A registers and reducing most instructions (except MOV) to have 8 addressing modes for only one operand, with the other operand always being a register.
(I've used both of those two examples, but it's been a while, and I don't have any particular desire to crack open their architecture manuals to see how CISCy or RISCy they are. It's kind of an academic distinction anyway at this point.)
Recent ESP32 processors have a "ULP Coprocessor" for ultra-low-power operations. Its instruction set is... well... not very RISCy: https://docs.espressif.com/projects/esp-idf/en/v4.2/esp32/ap...
(Spoiler alert for the lazy: it has single instructions for ADC reads and I2C transactions and such. I don't think it gets more CISC than that!)
That makes it quite RISCy. The overpowered instructions are just because it's an IO processor, they don't do much work on the CPU core itself, just trigger an IO component.
23 + max(1, SAR_AMP_WAIT1) + max(1, SAR_AMP_WAIT2) + max(1, SAR_AMP_WAIT3) + SARx_SAMPLE_CYCLE + SARx_SAMPLE_BIT cycles to execute
4 cycles to fetch next instruction
and when that instruction is one of your ISA's main reasons for existing, and the whole thing is designed to be programmed directly rather than compiled, that's pretty CISC to me. Even if most of the instructions available are your standard RISC stuff (or just the basics).But this whole discussion is and has always been rather fuzzy, so it's something of a moot point.
AS/400 is another interesting one. It was introduced on a System/38 base but intended for future transition to POWER.
When the AS/400 was released in 1988, they weren't thinking about POWER at all. The point of AS/400 was to unify their existing S/36 and S/38 midrange lines; the AS/400 was essentially a new version of the S/38 with added S/36 compatibility features. Its "technology independence" had been a feature of the S/38 since its initial release in 1978; S/38 in turn had inherited the idea from IBM's 1971–1975 "Future Systems" project, a failed attempt to build a successor to the 360/370 mainframe line. RISC wasn't the original motivation for the idea since the term hadn't even been coined when it was first developed.
In 1990, they began a project to develop a successor to the CISC IMPI CPU. They briefly evaluated POWER, but rejected it as unsuitable for their needs – so they started designing their own custom CPU architecture, "Commercial RISC" or "C-RISC" for short. Despite its name, it wasn't a true RISC architecture – it actually kept the CISC IMPI instruction set for backward compatibility, but added new simpler RISC-style instructions alongside it. I think the idea was new compilers would generate the new RISC instructions which would be hardwired, whereas the legacy CISC instructions would be microcoded.
By mid-1991, IBM HQ came to realise they had two different divisions working on "RISC" projects (PowerPC in Austin and C-RISC in Minnesota), and did not approve of the duplication – they ordered C-RISC killed, and the AS/400 was instead to use POWER/PowerPC, with the addition of any necessary extensions. However, while that decision was arguably best for the long-term, it did delay the project by at least a year, since the jump from IMPI to POWER was much bigger than from IMPI to C-RISC. The MI bytecode was only used by applications and the highest levels of the OS; huge parts of the OS were compiled directly to IMPI, and IMPI, while lower-level than MI, still had some rather high-level features which POWER lacks, such as hardware multitasking, and knowledge of the basic structure of the 128-bit capability/single-level-store addresses.
Source: Frank Soltis, Inside the AS/400, 1996
With RVA22, RISC-V has already caught up with ARM and x86 functionality.
Yet, It does not have their complexity. It is not even close.