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: jcallen@marley.think.com's message of 24 Jul 92 13:21:52
- Message-ID: <GLEW.92Jul26194414@pdx007.intel.com>
- Sender: news@ichips.intel.com (News Account)
- Organization: Intel Corp., Hillsboro, Oregon
- References: <9207081402.AA25575@ucbvax.Berkeley.EDU> <GLEW.92Jul12214745@pdx117.intel.com>
- <BrE09F.4JK@metaflow.com> <1992Jul15.163217.434@urbana.mcd.mot.com>
- <BrM813.Du5@zoo.toronto.edu> <GLEW.92Jul23184629@pdx007.intel.com>
- <JCALLEN.92Jul24132152@marley.think.com>
- Date: Mon, 27 Jul 1992 03:44:14 GMT
- Lines: 30
-
- By the way: creating virtual address aliases with different cache
- properties is a recipe for a complicated, expensive, and lower
- performance than it should be multilevel cache system.
-
- How so? Since the R4000 uses a completely separate bus for the
- secondary cache, I don't see the complication. Uncached access
- go straight to the main memory bus; otherwise the usual cache
- lookup takes place. What am I missing?
-
- If the access is determined to be uncached based on a bit in the TLB
- entry, you have to send it to both the main memory bus and the
- backside cache, because it might have been placed in the cache based
- on a virtual address alias.
-
- Unless, that is, you have required users to have the same cacheability
- in all virtual address aliases.
-
- I call this "cacheability type aliasing". What machines do this?
-
-
- --
-
- 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)
-