Path: chuka.playstation.co.uk!news From: Alex Herbert Newsgroups: scee.yaroze.programming.libraries Subject: More D-Cache thoughts... Date: Tue, 21 Jul 1998 15:30:24 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 19 Message-ID: <35B4A5FF.37EDA583@ndirect.co.uk> References: <359E82E9.1134@dial.pipex.com> <01bdafbf$5c177f20$f2e832a2@gbain.wav.scee.sony.co.uk> <35AF051F.708C@dial.pipex.com> <35AF1307.C1D4198B@scee.sony.co.uk> <35B33151.6DE1D612@easynet.co.uk> <35B34475.D898F644@scee.sony.co.uk> <35B4695C.C29FB50D@hinge.mistral.co.uk> Reply-To: aherbert@ndirect.co.uk NNTP-Posting-Host: dialin0-35.ndirect.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 [en] (Win95; I) I can see why the D-cache is a nice place to put the stack, as the stack is probably the most used area of memory in most C programs. But it is only 1K (which can easily be eaten up if you're using lots of local variables, and nesting lots of functions), and if some of the library functions trash the D-cache then it can only be used this way at certain times. In most cases I think it would be better to use the D-cache as a temporary scratch pad or work area. GsSortObject4() is a perfect example. Another example... If you've got heavy nested looping (e.g. collision detection between a large number of objects) it would be worth putting variables used for loop counters, array indexes and intermediate calculations in the D-cache. OK, so putting the stack in the D-cache would have the same effect, but with this method at least you would know what's in the D-cache, where it is in the D-cache, and exactly how much of the D-cache is in use. I don't know... Maybe just sticking the stack there maybe easier, just remember not to overwrite your own stack by calling another function which also moves the stack into the D-cache when it's there already. Herbs