🚀 go-pugleaf

>You are right about seperate I & D caches being a problem on many
>CISC machines.  You didn't give the main reason though:  CISC machines
>(like x86 series) can dynamically programatically alter their code by
>way of data writes that have to be able to find their way into the
>instruction cache.

RISC machines can do it, too, in principle.  However, the creators of a
new architecture, whether RISC or CISC, may be in a better position to
say "don't do that" than are the creators of an ~10-year-old
architecture with a large installed base of programs that alter their
code without flushing their instruction caches (perhaps because the
original implementation of that architecture didn't *have* instruction
caches, so the writers of that code couldn't stick the flushes into
their code).

On the other hand:

	1) I think the 68K - generally considered a CISC architecture -
	   requires you to flush the I-cache if you've stored into the
	   instruction stream, at least in the 68020 and 68030;

	2) SPARC may require you to do so, but Sun's run-time linker
	   didn't do so on SPARC until Sun came out with a machine with
	   split I&D caches;

so it's not exactly a strict RISC vs. CISC division here....