Self-modifying code

[John Mashey]

In article <12357 at ut-sally.UUCP> nather at ut-sally.UUCP (Ed Nather) writes:
....
>> + Many machines use seperate instruction and data caches.  Instruction
>>   caches can be made much simpler (= smaller = faster) by not
>>   requiring them to pay attention to the data bus.  Writing to a
>>   memory location is not guaranteed to update the I cache, thus you
>>   may or may not execute the modified instruction.  Next week's model
>>   may have a large enough cache that this week's code breaks.
>> 
>
>Again, not a problem.  You don't take the generated code out of the I cache,
>but out of the D cache, since it can (by definition) change.

No, machines that do this don't work that way, i.e., you only execute
code from the I-cache or main memory, not from the D-cache (or the cache
currently acting as the D-cache, in cases where you can swap them).

There is nothing wrong with generating code on the fly.
What is wrong is assuming a model of machines that looks just like
a CPU + DRAM, or with caches that act only like coherent, joint I&D caches.

This is just one instance of a general problem: how do you handle
caches that are visible to the executable code in any way?
What's needed is a good set of cache-control primitives that:
	a) Cover all of the cases
	b) Become widely used enough for people to count on.
	c) Are easy to make nops for enviornments where they don't matter.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash at mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086