Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site trsvax
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!convex!trsvax!uhclem
From: uhclem@trsvax
Newsgroups: net.arch
Subject: Re: MMU Cache revisited
Message-ID: <32800004@trsvax>
Date: Wed, 21-Aug-85 17:47:00 EDT
Article-I.D.: trsvax.32800004
Posted: Wed Aug 21 17:47:00 1985
Date-Received: Wed, 28-Aug-85 08:47:15 EDT
References: <2581@sun.uucp>
Lines: 34
Nf-ID: #R:sun.uucp:-258100:trsvax:32800004:000:1253
Nf-From: trsvax!uhclem    Aug 21 16:47:00 1985


/* Written 11:03 am  Aug 13, 1985 by fortune.U!wall in trsvax:net.arch */

>...
>Anyone care to agree with that?  Anyone care to tell me what 
>reasonable application or operating system spends 50% of its time
>in loops that are smaller that 256 bytes??
>...
>    But, hey, I could be wrong. It's happened before. So let's hear
>it. Anyone who claims high cache hit rates on normal applications,
>let's hear the justification for them.

Here are a couple of examples:

1.	Machine code for screen scrolling on bit-mapped graphic systems.
	If you are doing the entire screen, a few block moves will do.
	But if you are scrolling a particular area of the screen, the
	grunt-code needed fits nicely into 256 bytes.

2.	Graphic tiling or painting on bit-mapped systems.
	Once again, the painters' algorithm will fit (or the majority
	of it will fit) into 256 bytes.

I don't have any benchmarks on this stuff on a 68.02K yet, but I can
tell you how slow it runs on a ipax186 with its pipeline flushing
at the end of each scan line (end of loop) and whenever a jump is needed.


<The above is my opinion and not that of my employer; they don't 
 even know what the question is.>
						
						"Thank you, Uh Clem."
						Frank Durda IV
						@ <trsvax!uhclem>