From owner-freebsd-bugs Wed Jun 7 02:44:39 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA11800 for bugs-outgoing; Wed, 7 Jun 1995 02:44:39 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA11791 for ; Wed, 7 Jun 1995 02:44:31 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id CAA01756; Wed, 7 Jun 1995 02:44:14 -0700 From: "Rodney W. Grimes" Message-Id: <199506070944.CAA01756@gndrsh.aac.dev.com> Subject: Re: 2.0.5-A: Very disheartening? To: davidg@Root.COM Date: Wed, 7 Jun 1995 02:44:14 -0700 (PDT) Cc: maddox@CS.Berkeley.EDU, sysseh@devetir.qld.gov.au, bugs@FreeBSD.org In-Reply-To: <199506070537.WAA02429@corbin.Root.COM> from "David Greenman" at Jun 6, 95 10:37:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1653 Sender: bugs-owner@FreeBSD.org Precedence: bulk > > >> No. If you don't have cache coherency for things the *CPU* writes to memory, > >> you may as well pack up your marbles and go home. The problem isn't likely > >> caused by any sort of cache problem (even though it is apparantly effected by > >> disabling the cache). > > > >Unfortunately, not all CPU designers agree with you. It is common > >practice for instruction caches and prefetchers to assume that code is > >immutable once execution begins, and to require special provisions in > >software when this assumption is violated, even if the writing is done > >by the CPU itself! This is common on machines with split I/D caches, > > That may be, but that's not what is happening here. I agree that > self-modifying code would likely require special provisions for it to > work correctly. The gzip kernel is not modified in place. There is a > decompress program attached at the beginning and the compressed kernel > text/data is then decompressed into its destination memory area. And unlike the RISC chips such as the PA-RISC mentioned the Intel X86 architecture does not suffer from self modifiying code in the cache. For X in X86 of value 4 or smaller there is the prefetch buffer that can cause problems for self modifing code, but for the value of 5 even this is handled if I am recalling my reading of the architecture manual correctly. I do know for certain that any write to memory of data that is in the Pentium I cache will cause it to invalidate the I cache line. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD