Path: utzoo!utgpu!attcan!uunet!peregrine!elroy!ames!ncar!oddjob!uxc!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Self-modifying code (really Bli
Message-ID: <225800046@uxe.cso.uiuc.edu>
Date: 30 Jul 88 12:42:00 GMT
References: <8249@brl-smoke.ARPA>
Lines: 19
Nf-ID: #R:brl-smoke.ARPA:8249:uxe.cso.uiuc.edu:225800046:000:899
Nf-From: uxe.cso.uiuc.edu!mcdonald    Jul 30 07:42:00 1988



>This is indeed part of the answer. The other part is that
>instruction-fetch behavior is much simpler and more predictable
>than operand fetch, and that I-caches don't need to be
>written-through, allowing an isolated I-cache to be simpler
>and more effective than a combined operand/instruction cache.

This statement, unfortunately, connects up with the recurrent self-
modifying-code theme. SEPARATE I and D caches can result in incorrect
program execution if entries in the I cache are not voided if the
D cache gets written at the same location. Fixing this requires either
hardware to do this, or a "flush-cache" instruction. I strongly
prefer that hardware do this sort of housekeeping. It is OK if
there is a "dead period" of a reasonable number of cycles or
instructions during which the I cache is wrong. Some machines,
however, seem to be able to get this down to zero.

Doug McDonald