*BSD News Article 28641


Return to BSD News archive

Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!goanna.cs.rmit.oz.au!aggedor.rmit.EDU.AU!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!pipex!sunic!EU.net!chsun!hslrswi!aut!nbladt
From: nbladt@autelca.ascom.ch (Norbert Bladt)
Subject: Re: Shared Library Status ?
Message-ID: <CMn8G1.MA4@autelca.ascom.ch>
Organization: Ascom Autelca AG, Guemligen, Switzerland
References: <2liu8h$6k6@u.cc.utah.edu> <CONKLIN.94Mar9160535@ngai.kaleida.com> <hastyCMGnnx.DAE@netcom.com> <michaelv.763331698@ponderous.cc.iastate.edu> <2lqck0$11k@pdq.coe.montana.edu>
Date: Mon, 14 Mar 1994 07:21:36 GMT
Lines: 29

nate@bsd.coe.montana.edu (Nate Williams) writes:

>In article <michaelv.763331698@ponderous.cc.iastate.edu>,
>Michael L. VanLoon <michaelv@iastate.edu> wrote:

>>>>Earlier this week, Intel posted an announcement of 75MHz & 100MHz
>>>>clock-tripled i486's in comp.arch.  For some strange reason, Intel
>>>>calls them DX4's.
>>
>>One would hope they also increased the internal cache size.  I'm sure
>>a chip like this could potentially spend a lot of time twiddling its
>>thumbs waiting on memory.  However, knowing Intel, they probably
>>didn't think of this.

>C'mon Michael, what experience do you have developing chips?  On-board
>cache takes up a *huge* chunk of the available space on the chip. 
>Increasing it would mean losing the FPU processor at least (which is
>what IBM did to get the speed out of their Blue Lightning).

>If you have fast enough secondary cache you will still see a big performance
>increase, since the 8K cache still does a fine job of fetching ~90% of the
>instructions needed.
That's why Intel increases the size of the cache to 16kB ?!

Norbert.
-- 
Norbert Bladt, Ascom Autelca AG, Worbstr. 201, CH-3073 Guemligen, Switzerland
Phone: +41 31 999 65 52			FAX: +41 31 999 65 44
Mail: nbladt@autelca.ascom.ch   UUCP: ..!uunet!mcsun!chsun!hslrswi!aut!nbladt