From owner-freebsd-hackers Thu May 21 17:31:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10679 for freebsd-hackers-outgoing; Thu, 21 May 1998 17:31:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10527 for ; Thu, 21 May 1998 17:30:35 -0700 (PDT) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id JAA00707; Fri, 22 May 1998 09:57:16 +0930 (CST) (envelope-from grog) Message-ID: <19980522095715.R27201@freebie.lemis.com> Date: Fri, 22 May 1998 09:57:15 +0930 From: Greg Lehey To: Jamie Bowden , Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: Intel vs the rest (was `Original PC' and `talk') References: <199805202156.HAA15942@gsms01.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Jamie Bowden on Thu, May 21, 1998 at 08:36:38AM -0400 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 21 May 1998 at 8:36:38 -0400, Jamie Bowden wrote: > On Thu, 21 May 1998, Peter Jeremy wrote: > >> As an example of the impact of an architectural decision on >> complexity: The 68k included a clear split between (non-modifiable) >> instructions and (modifiable) data, the x86 didn't (and early >> applications often used self-modifying code). This means that the x86 >> needs a unified cache, whilst the 68k uses a split cache - which gives >> it two immediate advantages: The I-cache is also somewhat simpler (no >> need for dirty bits or the write-{through,back} logic), allowing more >> of it for the same complexity. Dual caches allow parallel I and D >> accesses - ie effectively doubling the cache <-> CPU bandwidth (dual- >> porting the cache can be done, but entails a substantial increase in >> complexity). (The downside is that a unified cache will adjust to >> different code vs data footprints - giving somewhat better hit rates >> for a given total cache size). > > I have both. > > Data cache size: 16 Kbytes > Instruction cache size: 16 Kbytes > Secondary unified instruction/data cache size: 512 Kbytes on Processor 0 > > All hail high end workstation makers. This is the SGI on my desk, lowly > Indy that it is. And how large is the TLB? And the page size? Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message