Path: utzoo!attcan!uunet!cs.utexas.edu!samsung!rex!ames!sun-barr!ccut!ascgw!fgw!flab!ayumi!yuhara From: yuhara@minako.stars.flab.fujitsu.co.jp (Masanobu Yuhara) Newsgroups: comp.arch Subject: Re: Instruction caches and closures Message-ID: Date: 2 Jul 90 09:52:35 GMT References: <771.267e5501@waikato.ac.nz> <39466@mips.mips.COM> <90Jun19.064421edt.2802@ois.db.toronto.edu> <1694@kunivv1.sci.kun.nl> Sender: news@ayumi.stars.flab.fujitsu.co.jp (News) Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan Lines: 34 In-reply-to: ge@kunivv1.sci.kun.nl's message of 20 Jun 90 10:39:08 GMT When I designed Cache/MMU for a microprocessor, I came across the same problem (Consistency between I-cache and D-cache). Self-modifying code does not frequently appear, but processors should support it somehow. What I had in mind was a garbage collector of Lisp. At least one of our Lisps do garbage collection of code area as well as heap area. Our solution was to provide an instruction called PIB (Purge Instruction Buffer). This instruction guarantees the modification of code is reflected. It is NOT a privileged instruction. On most processors, cache purge is privileged. But not all operating systems provide cache purge system call. (I heard SUN-OS has such a system call though not documented. ) The processor I designed has separate instruction and data caches with snooping. (Physical cache, write through, dual-port TAG, invalidation type snooping). Instruction cache snoops stores not only by other processors but also the same processor. This means PIB instruction does not have to purge the instruction cache at all. All you have to do is to purge the instruction queue and the pipeline, and to ensure that a write from the same processor was snooped. This scheme requires very little additional hardware and has no impact on performance. ------ yuhara@flab.fujitsu.co.jp Masanobu YUHARA Fujitsu Laboratories