home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10893 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  3.0 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!agate!doc.ic.ac.uk!uknet!acorn!armltd!dseal
  2. From: dseal@armltd.co.uk (David Seal)
  3. Newsgroups: comp.arch
  4. Subject: Re: Registerless processor
  5. Message-ID: <9841@armltd.uucp>
  6. Date: 18 Nov 92 18:13:11 GMT
  7. References: <1992Nov13.181654.11692@fcom.cc.utah.edu>
  8. Sender: dseal@armltd.uucp
  9. Distribution: comp
  10. Organization: A.R.M. Ltd, Swaffham Bulbeck, Cambs, UK
  11. Lines: 50
  12.  
  13. In article <1992Nov13.181654.11692@fcom.cc.utah.edu> drdavis@u.cc.utah.edu
  14. (Darren R. Davis) writes:
  15.  
  16. >I have been pondering an idea for a machine architecture.  A processor
  17. >that has no registers.  I am familiar with some architectures that have
  18. >done this.  My twist on this theme is to have a very large cache on chip
  19. >for memory locations (effectivelly becoming registers).  This goes
  20. >against the RISC idea of having very large register sets with load store
  21. >instructions.  This machine would just reference memory, and the most
  22. >common addresses becoming cached internally to the processor giving very
  23. >fast access.  Does anyone know of such a machine, and what are your
  24. >thoughts on this kind of architecture.  I envision the cache being
  25. >something like 8K or greater giving a large effective register set.
  26.  
  27. One common difference between the registers and the cache is that the
  28. register bank is multi-ported, while the cache is single-ported. This
  29. results in the registers supplying a much higher effective bandwidth to the
  30. ALU and other parts of the processor than the cache can. To get equivalent
  31. performance out of a registerless machine, you're going to have to
  32. multi-port the cache - which will make it take up similar amounts of space,
  33. power, etc., as a large register bank.
  34.  
  35. Another big difference is that the register bank usually is usually
  36. addressed statically (i.e. the compiler decides what register is used) and
  37. has comparatively few entries, while the cache is addressed dynamically
  38. (i.e. the processor decides on the fly what cache entry to use) and has
  39. comparatively many entries. A couple of side effects of this are:
  40.  
  41. (a) Register access is generally faster than cache access.
  42.  
  43. (b) Register addresses (i.e. register numbers) are generally shorter than a
  44.     cache address could possibly be, which in turn are shorter than the
  45.     addresses that are actually used for the cache (i.e. memory addresses).
  46.     This improves code density considerably, with various effects on speed
  47.     (denser code requires less memory bandwidth, uses the available cache
  48.     more efficiently, etc.).
  49.  
  50. Overall, for these and other reasons, I believe the experience of the
  51. computing community is that this is one of the situations where having two
  52. levels in the memory hierarchy (i.e. registers *and* cache) is more
  53. cost-effective than just having one. Some of the reasons are in fact very
  54. similar to those for having both cache and main memory rather than just main
  55. memory; some are specific to registers, which tend to be addressed
  56. differently to other layers of the hierarchy because of instruction set
  57. considerations.
  58.  
  59. David Seal
  60. dseal@armltd.co.uk
  61.  
  62. All opinions are mine only...
  63.