home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / hardware / 22085 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  2.8 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!ee!bloc1469
  2. From: bloc1469@ee.ee.uwm.edu (Gregory R Block)
  3. Newsgroups: comp.sys.amiga.hardware
  4. Subject: Re: Data/Instruction Cache & BURST modes on 68030? Why/when?
  5. Date: 26 Dec 1992 19:42:04 GMT
  6. Organization: Electrical Engineering Dept. University of Wisconsin - Milwaukee
  7. Lines: 48
  8. Message-ID: <1hicicINN5t3@uwm.edu>
  9. References: <72192@cup.portal.com> <smcgerty.725067816@unix1.tcd.ie> <1992Dec23.212118.3625@nic.csu.net>
  10. NNTP-Posting-Host: 129.89.2.33
  11.  
  12. In article <1992Dec23.212118.3625@nic.csu.net> matthewd@csufres.CSUFresno.EDU (Matthew Davidian) writes:
  13. >The main rationale I've read for the "Harvard" or split cache setup is that
  14. >they can both be accessed at the same time; in pipelined architectures this
  15. >can be especially good, since in one stage you might be fetching & decoding
  16. >an instruction, while another stage might be fetching the operand for another
  17. >instruction; both at the same time.
  18.  
  19. Right.  Harvard architecture allows for a more useful pipeline.  To
  20. say the LEAST.  :)
  21.  
  22. >A side effect of having data and instruction caches is that self modifying
  23. >code (which is not a good thing anyway) won't work--your writes to modify
  24. >the code will go into the data cache (because it's assumed to be data) and
  25. >the instruction caches doesn't get the change.
  26.  
  27. Well, again, we find self-modifying code a problem.  Just as a
  28. side-point to make, C= and Apple have both said to avoid
  29. self-modifying code.  I have never found a purpose for self-modifying
  30. code, except in the case of copy protection, which I think shouldn't
  31. exist.
  32.  
  33. >In an article I read before the P5/586/Pentium was announced, the writer
  34. >swore that Intel would never produce an 80x86 with a Harvard architecture
  35. >because so many DOS programs use self-modifying code--including Windows.
  36. >In order to pull this off, they must have added some extra stuff to check
  37. >data writes against the instruction cache, or some such magic, or else
  38. >the caches will have to be disabled for self-modifying code.
  39.  
  40. How quickly things change when performance becomes an issue over
  41. compatibility, eh?  I doubt seriously they have--if anything, if you
  42. fall back into compatibility mode (if it is true that the P5's native
  43. mode isn't compatible with the 486 and previous), you probably lose
  44. both caches.
  45.  
  46. Probably.
  47.  
  48. Adding a ton of kludges wouldn't be beyond Intel, but it does appear
  49. that for once they're trying to shrug off the kludges of their past
  50. and start anew--I don't believe they'd do this by introducing Yet
  51. Another Kludge.
  52.  
  53. Greg
  54.  
  55. --
  56. (: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
  57. (: "Our father, who art in Iowa, Hollow be thy head, Thy ideas run    :)
  58. (:  Thy will be done, At Commodore as it is at Apple"  -Dan Barrett   :)
  59. (: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
  60.