Date: Sun, 13 Apr 1997 03:55:04 -0500 From: Tony Overfield <tony@dell.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: steve@visint.co.uk, langfod@dihelix.com, hackers@freebsd.org Subject: Re: 430TX ? Message-ID: <3.0.1.32.19970413035504.007ceb90@bugs.us.dell.com> In-Reply-To: <199704130754.RAA18796@genesis.atrad.adelaide.edu.au> References: <3.0.1.32.19970413023332.007bd100@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 05:24 PM 4/13/97 +0930, Michael Smith wrote: >Because the onboard L2 is >so big though, it's on a seperate die (correct?) Correct. The L2 die is separate. >so it's slower than a >"real" L1, so the existing L1 is still used to cache it. Well, yes. But that's the whole point of L1 and L2 caches. They're presumed to be in a hierarchy. Otherwise you'd just have a big single-level cache. 8-) >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) Pentium yes, Pentium II no. That's the essence of the issue. The Pentium has no integrated L2 cache, so you have to hook up the L2 cache to the external CPU bus. The Pentium II has the L2 cache already inside the CPU module, so it can be connected to an internal, dedicated, and private L2 bus (DIB). >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. Well, the ideal way to go would be to have an L1 cache that was very large. But, as you say, there's not enough space available to do that. > Hence, the compromise - two dies, and a gradual >fading of the L1/L2 distinction. You could imagine that the L1 cache is being absorbed into the CPU to the point that the L2 cache seems to be the L1 cache. But, for now at least, the L2 cache is still treated as an "external" device, though it does have a private interface so that it doesn't compete for bandwidth with the usual CPU interface. >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. Agreed. I was simply pointing out that Intel does intend to support greater than 66 MHz memory timings; a fact which had been called into question. - Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.19970413035504.007ceb90>