the transition from CISC to RISC involved a transfer of responsibility from hardware to software: addressing modes, scheduling, delay slots, procedure call, etc. were implemented by the compiler rather than with microcode.

say we are deciding if a given feature should be handled by software/compiler or in microcode/hardware. if the information required to handle it isn't known at compile time, it must be left to the hardware. with RTCG one can know more at compile time, thus RTCG is more useful on RISC chips than on CISC.

but RISC isn't the limit: with RTCG sometimes cache/buffer access patterns, data alignment, loop lengths, shift distances, etc are available at compile time. thus Digital Signal Processing (DSP) chips (which replace cache with directly accessed on-chip SRAM and have no alignment circuits) may make an ideal target for RTCG. RISC and DSP both have three levels of memory hierarchy (multi-ported registers, on-chip ram, off-chip ram), but in RISC the cache manages the on-chip ram, whereas DSP leaves it to the programmer/compiler. bypassing the dynamic cache circuits saves some time, but managing it in software is difficult. compare this to the CISC to RISC transition and the appearance of register allocation.

in fact DSP chips are exactly those often used for interactive graphics systems like video games, 3D rendering, and of course audio filtering and effects.

but DSP isn't the limit: Field Programmable Gate Arrays (FPGAs) are a new kind of chip that allow their logic to be reconfigured in the field---at run time! in the same way one writes `ROM' into an EEPROM, one burns custom boolean circuits into an FPGA, thus reprogramming the hardware. these may provide the ultimate target for RTCG [IseSa93].