Path: utzoo!utgpu!watserv1!watmath!att!rutgers!usc!zaphod.mps.ohio-state.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: Instruction caches and closures Message-ID: <39940@mips.mips.COM> Date: 6 Jul 90 01:23:24 GMT References: <24891@bellcore.bellcore.com> <1756@charon.cwi.nl> <39868@mips.mips.COM> <1782@charon.cwi.nl> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 48 In article <1782@charon.cwi.nl> jack@cwi.nl (Jack Jansen) writes: >In article <39868@mips.mips.COM> mash@mips.COM (John Mashey) writes: >>In article <1756@charon.cwi.nl> jack@cwi.nl (Jack Jansen) writes: >>>This I/D cache discussion sparked a thought: I get the impression that >>>separate I/D caches are used mainly to get the benefit of two-way >>>set associative caches without the cost involved. If there aren't any >>>other added advantages,... >>No, the main reason is to double the peak bandwidth from cache -> CPU >>with the same speed SRAMs. >Ok, but that doesn't invalidate the point: separate I/D caches limit >the OS in the ways it can make best use of the available cache, while >a cache system that uses an address bit (or more address bits) to select >the cache (or cache bank, more correctly) should give the same performance >and more freedom. I must have misunderstood the original posting, as I didn't really understand how this design was supposed to work at all. Either: a) An instruction reference, and a data reference to the same address reference the same bits in the same SRAM. OR b) They don't. People design computers where: a) Is no problem, hence consistency is there, except maybe for prefetch buffers & similar things. b) Consistency is handled by software, explicitly, which is what almost everybody does that has separate I & D. c) Like b), except that extra hardware (somewhere) is used to maintain consistency, most likely by using a multiprocessor cache coherency protocol that must gain ownership of a cache line before doing the write. (Amdahl) Having multiple banks of SRAMs, decoded by address bits, doesn't make the fundamental problem go away, unless I completely misunderstand the description. A convincing description would start with a virtual address, showing Virtual Page Number and Byte Offset fields, and work thru the translation process to a physical address (i.e., page frame, and byte-offset fields), which combined with an I/D bit selection, access the SRAMs. Remember, the standard split I & D cache never makes any I reference or D reference wait for the other one. -- -john mashey DISCLAIMER: UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086