Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.arch Subject: Re: more cache/uncached ld/st Message-ID: <12476@dog.ee.lbl.gov> Date: 25 Apr 91 12:48:39 GMT References: <1991Apr15.193425.3436@waikato.ac.nz> <1991Apr23.053619.13474@kithrup.COM> <1991Apr23.152155.2298@zoo.toronto.edu> <51903@apple.Apple.COM> <1991Apr24.173843.13659@zoo.toronto.edu Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 20 X-Local-Date: Thu, 25 Apr 91 05:48:40 PDT In article <1991Apr24.173843.13659@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >If you can't use burst transfers except by trampling on your cache, your >processor-memory interface is defective. (More precisely, it has been >optimized for the typical case without due consideration of important >atypical cases.) The SparcStation-1 cannot do 16-byte bus cycles for memory => cpu except via the cache. (It never does anything but 4-byte bus cycles for cpu => memory; its cache is write-through.) Yes, this is a pain. (Copy-on-write in the Mach VM is done using physical addresses, meaning that you have you map both pages in somewhere---there is a pair of special virtual addresses for this--- and do a block copy. For speed, the source page should be cached, which mean you potentially blow away one cache page.) On the other hand, SparcStation-1s cost less because of it. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov