home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / arch / 12063 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  1.4 KB
  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!acorn!armltd!abaum
  2. From: abaum@armltd.uucp (Allen Baum)
  3. Newsgroups: comp.arch
  4. Subject: Re: Superscalar vs. multiple CPUs ?
  5. Message-ID: <11091@armltd.uucp>
  6. Date: 4 Jan 93 15:39:03 GMT
  7. Organization: Advanced RISC Machines Ltd
  8. Lines: 28
  9.  
  10. I'm pretty sure this didn't make it out last time 
  11. (cross posting problems- why comp.sys.intel?), so here it is again:
  12.  
  13.  
  14. >pcg@aber.ac.uk (Piercarlo Grandi) writes:
  15. >>This is another reason for which I think hyperscalar is premature:
  16. >>a vector instruction has the very nice property that it implies a very
  17. >>definite memory access pattern, 
  18.  
  19. >    This is one reason I've been advocating smarter caches, particularily
  20. >the ability to do predictive pre-fetching.  There are a couple of ways to
  21. >set this up:
  22.  
  23. >1.    Instruction sets address, bound, and perhaps amount to fetch....
  24.  
  25. This sounds just like the WM machine. It has an instruction that says: start a
  26. vector fetch from this base with this stride and put it in this FIFO. The FIFO
  27. is accessed as a GPR, which any instruction can use (including, presumably, another
  28. load for gather/scatter. There are two read FIFOs and a write FIFO in the WM design.
  29.  
  30. The HPPA has some bits in the short displacement load/store
  31. instructions that can be used for cache hints of the type you want- I
  32. think only one combination has been defined so far
  33. -- 
  34. -- 
  35.  
  36. ----------------
  37. Allen J. Baum        Apple Computer        baum@apple.com, abaum@armltd.co.uk
  38.