home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.arch
- Path: sparky!uunet!iWarp.intel.com|ichips!ichips!glew
- From: glew@pdx007.intel.com (Andy Glew)
- Subject: Re: CISC Microcode (was Re: RISC Mainframe)
- In-Reply-To: avg@rodan.UU.NET's message of 15 Jul 1992 13:44:54 -0400
- Message-ID: <GLEW.92Jul23183353@pdx007.intel.com>
- Sender: news@ichips.intel.com (News Account)
- Organization: Intel Corp., Hillsboro, Oregon
- References: <19920714.070713.843@almaden.ibm.com> <13v85hINN2og@rodan.UU.NET>
- <GLEW.92Jul14234349@pdx007.intel.com> <141o6mINN10h@rodan.UU.NET>
- Date: Fri, 24 Jul 1992 02:33:53 GMT
- Lines: 28
-
- Sure. You also have to check caches for consistency in multi-processor
- systems and when you do DMA, so the circuits or software are already in place.
- It can be done by cache controllers which monitor the bus or by invalidating
- cache entries which correspond to the target memory area.
-
- Hmmm... My background is in Motorola systems and minicomputers. In
- my experience most I/O devices are *not* cache coherent, so the
- circuits are not in place. Plus, even when cache coherent, there was
- frequently a performance advantage to not being coherent.
-
- Now, admittedly, in the PC world I have been surprised by how common
- cache coherent I/O is. How about other worlds? Which is more common,
- cache coherent or cache incoherent I/O? I believe John Mashey already
- noted that on the R3000 I/O was non-coherent, but on the R4000 I/O is
- coherent.
-
-
-
- --
-
- Andy Glew, glew@ichips.intel.com
- Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy,
- Hillsboro, Oregon 97124-6497
-
- This is a private posting; it does not indicate opinions or positions
- of Intel Corp.
-
- Intel Inside (tm)
-