Date: Sun, 13 Apr 1997 17:24:09 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: tony@dell.com (Tony Overfield) Cc: msmith@atrad.adelaide.edu.au, steve@visint.co.uk, langfod@dihelix.com, hackers@freebsd.org Subject: Re: 430TX ? Message-ID: <199704130754.RAA18796@genesis.atrad.adelaide.edu.au> In-Reply-To: <3.0.1.32.19970413023332.007bd100@bugs.us.dell.com> from Tony Overfield at "Apr 13, 97 02:33:32 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Overfield stands accused of saying: > >Unless I'm missing something here, this basically just means that > >the L1 cache got lots bigger, but now because it's slower, it too > >is cached. > > I think you're missing something here. ;-) > > The L1 cache is getting bigger but it's not getting slower. The L2 cache, > which has traditionally been attached to the external CPU bus just like the > memory controller and CPU-PCI bridge, is being attached to an independent > bus on the "side" of the CPU instead of to the CPU/memory bus. This makes > the CPU/memory bus available to other things (PCI bus masters, posted CPU > memory bus cycles, etc.) while the L2 cache is being concurrently accessed > by the CPU. It really makes a lot of sense when you think about it. Oh, I agree that it makes sense, I'm just looking at it from the opposite angle; in effect what you're describing is the application of L1-cache access strategies to the L2 cache. Because the onboard L2 is so big though, it's on a seperate die (correct?) so it's slower than a "real" L1, so the existing L1 is still used to cache it. Actually, I wasn't aware that Intel were still hanging the cache off the external CPU bus; I would have thought the CPU/cache were on the other side of the cache controller, but obviously I'm wrong there 8) > >I sniff a manufacturing compromise here. > > What are you referring to? It's true that some manufacturing issues are > improved by the newer designs, but that's not a bad thing. The "ideal" way to go would be to have all the new onboard L2 available to L1 access policies, but that would make for an unmanufacturable die. Hence, the compromise - two dies, and a gradual fading of the L1/L2 distinction. > >> I can't speak for Intel, but Intel says this on its www site: "In > >> addition, the Dual Independent Bus architecture supports the > >> evolution of today’s 66 MHz system memory bus to a 100 MHz system > >> memory bus within the next year." > > > >"we shortened some of the signals". > > Actually, it's because of some new signalling strategies, such as > those used by synchronous DRAM, which relieve the signals from > wiggling so fast. Ok, so "we shortened some of the cycles". It still doesn't seem to have much to do with the DIB, other than perhaps with respect to bandwidth. I meant to add a '8)' to the above. > Tony -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704130754.RAA18796>