Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!rutgers!cmcl2!ccnysci!alexis From: alexis@ccnysci.UUCP (Alexis Rosen) Newsgroups: comp.sys.mac.programmer Subject: Re: XFCN/XCMD string in LSC C v3.0 Keywords: A4-relative data, blessing or curse? Message-ID: <1582@ccnysci.UUCP> Date: 14 Apr 89 08:50:38 GMT References: <12964@dartvax.Dartmouth.EDU> <28737@ucbvax.BERKELEY.EDU> <12968@dartvax.Dartmouth.EDU> <6944@hoptoad.uucp> Reply-To: alexis@ccnysci.UUCP (Alexis Rosen) Organization: City College of New York Lines: 35 In article <6944@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <12968@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle >R. Horton) writes: >> Several problems exist with this approach. The chief one is >>writing to the code resource. This is bad. It can lead to strange >>bugs on 68020 machines. > >[...] There would only be a problem if the address where A4 is >stashed were executed. That's the only way the address could find >its way into the instruction cache and cause problems: by being executed. >Since it's just being handled as data, there's no problem. This was my initial reaction as well. But I'm not so sure. First of all, is code stashed in the cache on a byte-by-byte basis? Maybe, in the 020/030, it is. I'm not sure. (I can't see it reading ahead in 32-word chunks, really. Too slow.) But in the 040 there are 4K bytes of instruction cache. Does the CPU tag each word? If not, data could wind up being sucked into the cache along with instructions. Not much, but some. On the other hand, this probably wouldn't affect things anyway, since there wouldn't be a cache hit in the i-cache when it's looking for data, would there? confusion reigns... --- Alexis Rosen alexis@ccnysci.{uucp,bitnet} p.s. Why haven't there been any discussions of the '040, either here or in comp.arch? Wasn't the information announced enough to start a half-dozen flame wars?