nw@palladium.UUCP (Neil Webber) (11/23/87)
In article <17223@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) writes: > > Won't work. The M68020 has an on-chip cache which stores 32-bit > address values. Even if the external memory addressing only uses fewer > bits, the cache always checks all 32. On a system where the high address > byte is unused by the memory, the following sequence will produce > unwanted effects: > > Read address A. > Write new value to A + 0xff000000 > Read address A - get the OLD value! > > Like it or not, the M68020 is a 32-bit machine. > > John Nagle The 68020 cache does NOT present any impediments to using the upper address bits as tag bits. The 68020 cache is an instruction only cache. The scenario described above can't happen unless it is the *instruction stream* that is being modified. Now, I don't know anything about Prolog internals or externals. If Prolog regularly modifies the instruction stream (i.e., self-modifying code) then it has a problem whether or not the upper address bits are used for tag bits. Prolog has to flush the I-cache at appropriate times (flushing the cache is a supervisor-only operation, by the way). For more details, see chapter 7 of the Motorola 68020 "User's Manual". From a quick reading of my 68030 preliminary "Technical Summary", it looks like the upper-address-bits-as-tags technique is NOT viable on the 68030. The 68030 has a data cache. At first, it looks like the tag bit technique would work, because addresses are resolved to specific cache locations based only on the lower-order address bits. In other words, address A and address A + 0xff000000 would resolve to the same cache location. "Cache alignment" is a common technique for resolving cache coherency problems. Unfortunately, the 68030 data cache does not allocate cache locations on a write-miss. Thus, the sequence: Read address A. Write new value to A + 0xff000000 Read address A - get the OLD value! could in fact happen on the 68030. -- Neil Webber / Epoch Systems, Marlboro MA / (617) 481-3717 {harvard!cfisun, linus!alliant}!palladium!nw