From owner-freebsd-hackers Sun Apr 13 02:03:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA25362 for hackers-outgoing; Sun, 13 Apr 1997 02:03:15 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA25350 for ; Sun, 13 Apr 1997 02:03:10 -0700 (PDT) Received: from bugs.us.dell.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0wGLBl-00091dC; Sun, 13 Apr 97 02:03 PDT Received: from ant.us.dell.com (ant.us.dell.com [198.64.66.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id DAA22993; Sun, 13 Apr 1997 03:55:06 -0500 Message-Id: <3.0.1.32.19970413035504.007ceb90@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sun, 13 Apr 1997 03:55:04 -0500 To: Michael Smith From: Tony Overfield Subject: Re: 430TX ? Cc: steve@visint.co.uk, langfod@dihelix.com, hackers@freebsd.org In-Reply-To: <199704130754.RAA18796@genesis.atrad.adelaide.edu.au> References: <3.0.1.32.19970413023332.007bd100@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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