Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dvorak.amd.com!nucleus!peter From: peter@nucleus.amd.com (Peter Song) Newsgroups: comp.arch Subject: Re: MIPS LL & SC instrs Message-ID: <1991Jun10.182119.5523@dvorak.amd.com> Date: 10 Jun 91 18:21:19 GMT References: <4411@spim.mips.COM> Sender: Peter Song Organization: Advanced Micro Devices, Austin, TX Lines: 31 In article glew@pdx007.intel.com (Andy Glew) writes: | | >... LL/SC only works on locations that | >are marked coherent (and therefore kept up to date with memory by | >hardware). | > | >-- | >Charlie Price cprice@mips.mips.com (408) 720-1700 | | Q: what does MIPS do for synchronization through uncached memory? What are the circumstances where one has to use non-cacheable memory locations for any "meaningful" (meaningful being more than just the producer/consumer relationship) synchronization, given that LL/SC works only with cacheable locations? | E.g. synchronization with an I/O device? Or are all I/O devices cache consistent? Only the dma devices that access "cacheable portions of memory" in a write-back system must understand the data intervention protocol for the dma read (read from the memory). The dma write should be handled correctly by the caches (and let's not think about a dma write to a dirty block). The non-dma i/o devices can rely on the load and store instructions to maintain consistency in the memory space as the data is moved from and to the memory space. There is no use/need to maintain consistency between the memory space and the io space where data is produces and consumed. | | Andy Glew, glew@ichips.intel.com S. Peter Song - 29K Advanced Processor Development - Advanced Micro Devices peter@nucleus.amd.com (800) 531-5202 x54818