home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10485 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  1.9 KB
  1. Xref: sparky comp.arch:10485 comp.lang.forth:3453
  2. Path: sparky!uunet!auspex-gw!guy
  3. From: guy@Auspex.COM (Guy Harris)
  4. Newsgroups: comp.arch,comp.lang.forth
  5. Subject: Re: What's wrong with stack machines?
  6. Keywords: register allocation, stack cache
  7. Message-ID: <15381@auspex-gw.auspex.com>
  8. Date: 6 Nov 92 22:46:20 GMT
  9. References: <1992Nov6.094639.28441@email.tuwien.ac.at> <1992Nov6.182326.12025@ringer.cs.utsa.edu>
  10. Sender: news@auspex-gw.auspex.com
  11. Followup-To: comp.arch
  12. Organization: Auspex Systems, Santa Clara
  13. Lines: 49
  14. Nntp-Posting-Host: auspex.auspex.com
  15.  
  16. >There is a perspective on RISC/register based architectures and CISC  
  17. >and/or stack based machines.
  18.  
  19. Err, does that mean you're throwing CISC machines into the same pile as
  20. stack-based machines?  Most of the CISC architectures I've dealt with
  21. are register based, even though they have memory-to-register or
  22. memory-to-memory arithmetic; i.e....
  23.  
  24. >It is: when and how do you do register
  25. >allocation.  On a RISC machine the compiler does it.
  26.  
  27. ...on those CISC machines, the compiler does it as well.
  28.  
  29. >On a stack machine
  30. >the hardware does it on-the-fly, i.e., a particular data value or variable
  31. >gets allocated to a specific hardware register during execution.
  32.  
  33. Hmm.  I no longer have the paper, but I seem to remember seeing a paper
  34. on compilers for stack-based machines that, as I remember it,
  35. essentially had the notion of Sethi-Ullman numbers for stack machines; I
  36. think the goal was to reduce the maximum stack depth required to
  37. evaluate an expression.
  38.  
  39. I.e., I'm not convinced that all the work of "register allocation" is
  40. always done, or should always be done, in hardware *even on stack
  41. machines*.
  42.  
  43. (Trivial example: you can evaluate a+b+c+d as
  44.  
  45.     push a
  46.     push b
  47.     push c
  48.     push d
  49.     +
  50.     +
  51.     +
  52.  
  53. or you can evaluate it as
  54.  
  55.     push a
  56.     push b
  57.     +
  58.     push c
  59.     +
  60.     push d
  61.     +
  62.  
  63. If the machine has only two top-of-stack registers, the second example
  64. may be better than the first.)
  65.