home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sgi / 12475 < prev    next >
Encoding:
Internet Message Format  |  1992-08-16  |  2.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!mips!mash
  2. From: mash@mips.com (John Mashey)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: R4000 compiler directive, is there one ???
  5. Message-ID: <l8tjcfINN25c@spim.mips.com>
  6. Date: 16 Aug 92 21:50:07 GMT
  7. References: <6984@charon.cwi.nl>
  8. Organization: MIPS Computer Systems, Inc.
  9. Lines: 39
  10. NNTP-Posting-Host: winchester.mips.com
  11.  
  12. In article <6984@charon.cwi.nl> robertl@cwi.nl (Robert van Liere) writes:
  13. >In article <????> mash@mips.com writes:
  14. >  [.... some analysis of R[34]K caches, load/store patterns, thrashing ...]
  15.  
  16. >It isn't a compiler directive, but perhaps the system call 'cachecntl'
  17. >can be used to avoid these problems. The manual says it "allows a process
  18. >to ranges of its address space cacheable or uncachable". I wouldn't know
  19. >how this call can be used in the aforementioned Fortran program, but I
  20. >suspect that it could help in a C program which depicts the same behavior.
  21. >
  22. >How would 'cachecntl' effect this analysis ? On the R3K ? On the R4K ?
  23.  
  24. It is possible ... but I generally wouldn't recommend it.
  25. Cachecntl is plausiably used for things like graphics frame buffers,
  26. which may actually be mostly-write in practice, or for accessing
  27. device registers (whihc must be uncached for sanity).
  28.  
  29. Unless you are very careful with cachecntl, there is great potential
  30. for  difficult-to-find bugs.  The effect you might want to get
  31. (high bandwidth to/from uncached address space) is not as strongly
  32. supported yet by R4000s as you might like, although R4000As
  33. improve it, and in general, it can only work on pagesize
  34. boundaries.
  35.  
  36. Please note, of course, that very few real programs look
  37. remotely like the benchmark described.  In general, the rule
  38. of thumb, on the average, is that loads from memory are 20%
  39. ofthe instruction, and stores to memory 10%.  Rarely does
  40. one find a program that is something like 90% stores....
  41. Although caches certainly od *not* work all of the time,
  42. more often than not they do work.  It remains an unresolved
  43. issue to get the advantages of uncached and cached accesses
  44. together, in general, without difficult programming;
  45. people are certainly working on it for future designs.
  46. -- 
  47. -john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
  48. UUCP:      mash@mips.com [soon to be mash@sgi.com, but not quite moved yet].
  49. DDD:      408-524-7015,  or 524-8253
  50. USPS:    (soon) Silicon Graphics, 2011 N. Shoreline Blvd, Mountain View, CA 94043
  51.