Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!think!snorkelwacker!spdcc!merk!xylogics!cloud9!jjmhome!m2c!umvlsi!dime!ccs1.cs.umass.edu!shri
From: shri@ccs1.cs.umass.edu (H.Shrikumar{shri@ncst.in})
Newsgroups: comp.arch
Subject: Re: Software modularity vs. instruction locality
Message-ID: <6374@dime.cs.umass.edu>
Date: 6 Nov 89 20:36:33 GMT
References: <17707@watdragon.waterloo.edu> <23604@cup.portal.com>
Sender: news@dime.cs.umass.edu
Reply-To: shri@ccs1.cs.umass.edu (H.Shrikumar{shri@ncst.in})
Distribution: na
Organization: University of Massachusetts, Amherst
Lines: 23

In article <1TMk2X#Qggn6=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) 
writes:
>In <1989Nov4.004529.10049@ico.isc.com> Dick Dunn wrote:
>>                                     Second, I would expect better locality
>> for code reference than for data reference, hence the I cache ought to do
>> more good than the D cache.  Aren't the pathological cache-busting programs
>> generally ones which spray data accesses all over the place?
>
>Not necessarily. There's a subtle problem here; good software modularity
>practices tend to hurt code locality. If you're calling subroutines a lot
>in generated code the PC jumps all over the shop.

This happens for example in a FORTH machine, FORTH typically is
subroutine threaded, so there is a flurry of subroutine calls
happening at about 4 million a second. (in a 8-10 Mhz (?) Novix 2016 
Forth CPU).

In forth there is a subroutine call every five or so instructions
I would guess.

Wonder if some better cache philosophy can help here.

-- shrikumar ( shri@ccs1.cs.umass.edu, shri@ncst.in )