Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!dartvax!eleazar.dartmouth.edu!mjm From: mjm@eleazar.dartmouth.edu (Michael McClemen) Newsgroups: comp.sys.mac.programmer Subject: Re: XFCN/XCMD string in LSC C v3.0 Message-ID: <12987@dartvax.Dartmouth.EDU> Date: 11 Apr 89 00:20:29 GMT References: <12964@dartvax.Dartmouth.EDU> <28737@ucbvax.BERKELEY.EDU> <12968@dartvax.Dartmouth.EDU> <6944@hoptoad.uucp> <3756@sybase.sybase.com> Sender: news@dartvax.Dartmouth.EDU Reply-To: mjm@eleazar.dartmouth.edu (Michael McClemen) Organization: Dartmouth College, Hanover, NH Lines: 18 Sender: If (as I read in current trade publications) the 68040 (presumably the wave of the future as far as such things go) has separate data and instruction caches, why would storing data in code space be a problem for a program running on that processor? Being rather ignorant about low-level architecture, my initial perception is that instruction fetches would use one cache, while data fetches would use the other. Now, since you obviously have to be able to write to data-cached locations (a write-through cache, correct?) why wouldn't data fetches from an address also coincidentally stored in the instruction cache go through the data cache and not mind that that memory cell had been written to? This is quite a different matter from self-modifying code, where subsequent fetches from a modified location go through a read-only cache. If there is a flaw in my understanding, I would be grateful if someone would explain this business more throughly; I have had the question for quite a while now. -- Michael McClennen