From owner-freebsd-hackers Sat Apr 12 18:29:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA08783 for hackers-outgoing; Sat, 12 Apr 1997 18:29:32 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA08778 for ; Sat, 12 Apr 1997 18:29:29 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA17951; Sun, 13 Apr 1997 10:58:07 +0930 (CST) From: Michael Smith Message-Id: <199704130128.KAA17951@genesis.atrad.adelaide.edu.au> Subject: Re: 430TX ? In-Reply-To: <3.0.1.32.19970412103112.006b22b4@bugs.us.dell.com> from Tony Overfield at "Apr 12, 97 10:31:12 am" To: tony@dell.com (Tony Overfield) Date: Sun, 13 Apr 1997 10:58:06 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, steve@visint.co.uk, langfod@dihelix.com, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tony Overfield stands accused of saying: > > The "dual bus architecture" is not related to the split I&D cache. Thanks for the clarification. > Michael Smith said: > > > >It Intel are hailing this as some sort of 'breakthrough', then that's > >just one more reason to laugh loudly at them. > > 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'. > Of course, the win from a split I&D cache is not really related to > a low ratio of instruction and data mixing. The win comes from the > concurrency that it makes possible. ... 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). > The CPU can fetch instructions > and data from the I and D caches at the *same time* with obvious > performance benefits. If I recall correctly, the data cache supports > two simultaneous data references, so there can be up to three cache > data references in progress at any given instant. 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) > 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 sniff a manufacturing compromise here. > 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". > David Langford said: > ) What I really dont understand is why HP and ALR(?) seem to be the only > ) folks doing memory busses larger than 64 bits wide. > > 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. -- ]] 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 [[