home *** CD-ROM | disk | FTP | other *** search
- Path: ar.ar.com.au!not-for-mail
- From: storm@ar.ar.com.au (Storm)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: One hardware-basher's manifesto
- Date: 8 Mar 1996 16:19:52 +1100
- Organization: I need to put my ORGANIZATION here.
- Message-ID: <4hog1o$3op@ar.ar.com.au>
- References: <04000205714080640503@BIRDLAND> <4ge8na$vhe@ar.ar.com.au> <38232623@kone.fipnet.fi> <4gmlg9$jo3@serpens.rhein.de>
- NNTP-Posting-Host: ar.ar.com.au
- X-Newsreader: TIN [UNIX 1.3 941216BETA PL0]
-
- Michael van Elst (mlelstv@serpens.rhein.de) wrote:
-
- : .. and the CPU. A 040 does always use bursts for cachable data, the only
- : way to turn bursts off is to disable the cache and _that's_ slowing down
- : everything significantly. Disabling bursts almost never helps.
-
- I have a question about an 040's data cache! Well, not so much a question,
- I just want to make sure my understanding is correct..
-
- With the copyback mode, any writes to a cached memory location are only
- written to the cache, right? And then, when that bit gets pushed out of
- the cache to make room for something else, they get written to 'real'
- memory, right?
-
- So, if you flush the cache (after self-modifying code for instance), it
- will possibly be forced to write a large amount of stuff to main memory,
- right?!
-
- I want to know, because I've been using self-modifying code taking into
- account that the exec routine to flush caches take ~1 raster line to
- execute on a standard A1200. But then it occurred to me that due to this
- copyback cache on the 040, it could take a _seriously_ longer time -
- long enough that self-modifying code could almost never provide any
- speedup?
-
- Am I right in all of this? Or have I missed something?
-
- -- ______________________________
- \_/ "\/\/\__"\/ "\/ "\/\__"\_/
- Storm / Cydonia / / / / / / / / / / / / ' / Packing class
- / /\/> / / / / / / / / / /__ & kicking arse!
- (coder) \__/ \_/\__/\__/\/\/\/\/\/ \/
-