home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / hardware / 14087 < prev    next >
Encoding:
Text File  |  1992-07-23  |  4.8 KB  |  98 lines
  1. Newsgroups: comp.sys.mac.hardware
  2. Path: sparky!uunet!nntp1.radiomail.net!fernwood!metrop!robert
  3. From: robert@metropolis.com (Robert Munyer)
  4. Subject: Re: 040 caching
  5. Message-ID: <1992Jul23.064630.24591@metropolis.com>
  6. Sender: robert@metropolis.com (Robert Munyer)
  7. Organization: Metropolis Software, Inc.
  8. References: <1992Jul22.025300.10797@news.columbia.edu>
  9. Date: Thu, 23 Jul 1992 06:46:30 GMT
  10. Lines: 86
  11.  
  12.  
  13. In article <1992Jul22.025300.10797@news.columbia.edu>
  14. gmw1@cunixa.cc.columbia.edu (Gabe M Wiener) writes:
  15.  
  16. > Can someone explain exactly what is going on when a program "trips over" the
  17. > 040 cache?
  18.  
  19. People will try to tell you that the problem is caused by self-modifying code,
  20. but that's not the whole truth.  The problem happens any time the processor
  21. tries to execute code at ANY location that has recently been modified, unless
  22. the cache has since been flushed.  It doesn't matter who modified the location.
  23.  
  24. The problem is that the processor funnels data from ONE memory address space
  25. through TWO caches, and these two caches do not automatically communicate with
  26. each other when they need to.  Because the caches don't handle the situation
  27. automatically, the programmer has to do it manually.  But of course, in some
  28. cases, the program was written BEFORE the 68040 was designed!
  29.  
  30.                           +-----------------+
  31.                      _____|Instruction Cache|____
  32.                     /     +-----------------+    \
  33.           +---+    /                              \    +------+
  34.           |CPU|---<                                >---|Memory|
  35.           +---+    \         +----------+         /    +------+
  36.                     \________|Data Cache|________/
  37.                              +----------+
  38.  
  39. Let's say the CPU (actually, the program that is running in the CPU) wants to
  40. save a machine-language routine into the memory starting at location 2E30A6,
  41. and then later on it wants to run that routine.  When the CPU is saving the
  42. routine, it sends the data to the Data Cache.  On the 68030, the Data Cache
  43. will immediately send these data on through to the memory, because the 68030
  44. has a "write-through" cache.  On the 68040, the Data Cache does NOT immediately
  45. send the data on through -- it waits until it "feels like it".  When the CPU
  46. tries to execute the routine at location 2E30A6, it reads the data through the
  47. Instruction Cache.  Now, if this happens before the Data Cache has "gotten
  48. around to" sending those data on through to the memory, the CPU will be getting
  49. the data that USED TO BE THERE instead of the data that are SUPPOSED TO BE
  50. THERE NOW.  Most likely the user will see "Sorry, a system error occurred".
  51.  
  52. The 68030 also has two separate caches that do not communicate automatically,
  53. but on the 68030 the Data Cache is "write-through" so this problem does not
  54. occur.  There is a similar problem that DOES occur on the 68030, but it only
  55. happens if the CPU tries to
  56.      (1) execute a location, and
  57.      (2) modify that location, and
  58.      (3) execute that location again.
  59. (Remember that on the 68040, just doing number 2 and number 3 will cause a
  60. crash, even without ever doing number 1).  This 68030 situation is probably the
  61. source of the belief that "self-modifying code" is what causes the problem.
  62.  
  63. > Does the 040 cache have any relation to the external cache that can be added
  64. > in the PDS slot?
  65.  
  66. Not in this case.  The PDS cache cards have only ONE cache, and there is no
  67. "back way" for the CPU to get to the memory without going through the cache, so
  68. there is no way for the data to get "out of sync".  Now, if you had TWO cache
  69. cards, and they didn't communicate with each other, and the CPU chose between
  70. them more or less at random, THEN you'd have a similar problem.  Peripherals
  71. which use DMA might cause a similar problem with cache cards, but that's
  72. "beyond the scope of this discussion 8^)".
  73.  
  74. > Why does this problem not manifest itself on IIci's with cache cards?
  75.  
  76. See above.
  77.  
  78. > Apparently there is some sort of Apple CDEV that can be used to turn the 
  79. > 040 cache on and off.
  80.  
  81. I think the Apple one requires you to reboot whenever you turn the cache on or
  82. off.  There's a better control panel device (called CacheOut, I think) that can
  83. turn it on and off automatically whenever you (or your system) switches from
  84. one application to another.
  85.  
  86. By the way, before somebody corrects me, I should mention that on the 68040
  87. the Instruction Cache and the Data Cache are INSIDE the processor chip.  In my
  88. diagram above, when I said "CPU" I meant the central processing unit in the
  89. chip, not the whole chip.
  90.  
  91. Sorry this is a bit long winded.  I hope at least it's easy to understand.
  92.  
  93. ______________________________________________________________________
  94. Robert Munyer            |   "I may be synthetic, but I'm not stupid."
  95. robert@metropolis.com    |      -- Bishop, _Aliens_
  96. Disclaimer: this does not necessarily represent the views of my employer.
  97.  
  98.