Date: Sun, 13 Apr 1997 02:33:32 -0500 From: Tony Overfield <tony@dell.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: msmith@atrad.adelaide.edu.au, steve@visint.co.uk, langfod@dihelix.com, hackers@freebsd.org Subject: Re: 430TX ? Message-ID: <3.0.1.32.19970413023332.007bd100@bugs.us.dell.com> In-Reply-To: <199704130128.KAA17951@genesis.atrad.adelaide.edu.au> References: <3.0.1.32.19970412103112.006b22b4@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:58 AM 4/13/97 +0930, Michael Smith wrote: >> Every Pentium CPU that Intel has ever made, starting four or five years >> ago with the very first P5, has had split I&D caches, so you shouldn't >> laugh at Intel in this case. > >The "laugh" proposal was a direct follow-on to the proposition that >Intel might be suggesting that split I&D was a 'breakthrough'. Yes, I know. I was just trying to clarify things. The discussion to that point had placed me in astonishment mode. :-o >... only if the CPU can get at both the I&D caches at the same time. >In most modern implementations, this is certainly the case, although >in single-chip micros this usually leads to lots of pins (expensive) >or putting the split cache onboard (size constraints). For Pentium and Pentium Pro, of course, it's the latter. >A deeper pipeline can often achieve equivalent results to this, >although you will correctly raise the problems with deep pipelines and >speculative execution/branch prediction, etc. and I will have to >concede that a short pipeline and fast cache access/decoding are >better 8) Yes, though I'd probably state it even more strongly. >> On the other hand, Intel's "dual independent bus architecture" was first >> put into the Pentium Pro and it refers to the separate L2 cache bus, made >> practical (due to the large number of signals involved) because the L2 >> caches were integrated. The Pentium II also has this feature, again made >> practical because the L2 caches are built into the processor module. >> This feature allows the CPU to access the L1 and L2 caches while the CPU >> bus is busy. > >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. >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. >> 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. >> Since the CPU only has a 64 bit data bus, the extra bits are harder >> to take advantage of. > >You would have to brew your own memory controller (and possibly fiddle the >behaviour of the cache controller) to take advantage of a wider memory bus, >and it wouldn't buy you much. Right. It's mighty hard to get funding to design and build a custom memory controller these days, especially when the "over the counter" chipsets perform so well, unless you're in that business anyway. - Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.19970413023332.007bd100>