Path: utzoo!mnetor!uunet!littlei!intelisc!omepd!mcg
From: mcg@omepd (Steven McGeady)
Newsgroups: comp.arch
Subject: Re: 80960 IO
Message-ID: <3385@omepd>
Date: 17 Apr 88 22:05:34 GMT
References: <3358@omepd> <10320@steinmetz.ge.com> <40@radix> <11026@mimsy.UUCP> <3368@omepd> <11067@mimsy.UUCP>
Reply-To: mcg@iwarpo3.UUCP (Steve McGeady)
Organization: Intel Corp., Hillsboro
Lines: 26


In article <11067@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>
>I was unclear in my unclarity.  I remember something about burst
>mode memory access; if there is any sort of data cacheing in the
>80960 architecture itself, one would need a way to inhibit multiword
>reads from the bus during IO space references.
>
>Of course, if data cacheing is to be done externally, this problem
>vanishes (or rather, retreats into the board level).

I should have tried to understand more thoroughly.  The existing
implementations do no data caching per se (other than the stack frame register
cache).  Therefore, the burst mode bus is not a problem.

It should be pointed out that the pipelined bus I/O, coupled with burst mode,
the register cache, and other aspects of the architecture make the 80960
relatively less sensitive to slow memory than other processors (especially
other RISC processors).  The 80960 suffers from 2-10% slowdown per
memory waitstate (7% typical).  This is much lower than many competing
processors, and makes it practical to build 80960 systems without
expensive and board-space-consuming caches.  Another reason why the 80960
is targeted at a controller market, as opposed to a system market.


S. McGeady