home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10531 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  3.2 KB
  1. Xref: sparky comp.arch:10531 comp.lang.forth:3459
  2. Newsgroups: comp.arch,comp.lang.forth
  3. Path: sparky!uunet!email!vlsivie.tuwien.ac.at!mike
  4. From: mike@vlsivie.tuwien.ac.at (Michael Gschwind)
  5. Subject: Re: What's RIGHT with stack machines
  6. In-Reply-To: pazsan@Informatik.TU-Muenchen.DE's message of Wed, 4 Nov 1992 10: 30:08 GMT
  7. Message-ID: <MIKE.92Nov9004026@guam.vlsivie.tuwien.ac.at>
  8. Sender: news@email.tuwien.ac.at
  9. Nntp-Posting-Host: guam.vlsivie.tuwien.ac.at
  10. Organization: Vienna University of Technology
  11. References: <Bx5AIr.EAy.2@cs.cmu.edu> <1992Nov4.103008.2641@Informatik.TU-Muenchen.DE>
  12. Date: Sun, 8 Nov 1992 23:40:26 GMT
  13. Lines: 50
  14.  
  15. In article <1992Nov4.103008.2641@Informatik.TU-Muenchen.DE> pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:
  16.    Thanks to your interresting report. I have little to add.
  17.  
  18.    Code size and performance: reduced code size for equal operations means less bus
  19.    bandwidth is requested. As busses (and DRAMs) are today the von Neumann's
  20.    bottlenecks, stack CPUs reduces costs for main memory and second level caches and
  21.    may increase performance, if the costs are equal.
  22.  
  23. Yes, but you pay a heavy price. Stack machines basically compute
  24. expressions of the type 
  25. ((((...) op A) op B) op C) 
  26. so each operation depends on the previous (if nothing else, since all 
  27. ops operate on the stack, there is the stack pointer dependency), so
  28. super scalar or even deep pipelining  are totally out of the question.
  29. I used to like stack machines, they are beautiful, simple, allow easy
  30. compilers, BUT THEY JUST DID NOT SCALE - neither in modern design
  31. technologies nor when it comes to compilers.
  32.  
  33.    Compiler complexity: Tanenbaum had a compiler project, that did much optimizing
  34.    on the intermediate stack machine code. I think you have little to do to convert
  35.    this code for a stack machine, whereas you have a lot of work to allocate
  36.    registers and schedule instructions, as you have to do on "conventional" RISC
  37.    processors.
  38.  
  39. Yes, for simple arithmetic expressions, they allow way cool
  40. optimizations. But what do you do when you get to things like CSE? DUP
  41. DUP SWAP SWAP ROT? Hardly efficient! 2 memory accesses for DUP, 4 for
  42. swap, 6 for ROT. You simply have to shuffle intermediate results too
  43. much. Or save them in memory - definitely more expensive than a
  44. register. Once again, with technology of 10 years ago, they were nice,
  45. but it does pay to allocate registers and do scheduling, AND WE HAVE
  46. THE TECHNOLOGY NOW to do it.
  47.  
  48.    Spill&Fill: did anyone thought about automatic spill&fill-buffers? (if the
  49.    available stack cells decreases to a certain level, a number of stack items are
  50.    load (4 or 8 would be great), and if it increases over a certain level, the same
  51.    amount of stack items is spilled (have a hysterese of about 8 stack entries).
  52.  
  53. I figure implementation of this is just to hairy - on the same real
  54. estate, you can put 16 extra registers ;) 
  55.  
  56. mike
  57. --
  58.  
  59. Michael Gschwind, Dept. of VLSI-Design, Vienna University of Technology
  60. mike@vlsivie.tuwien.ac.at    1-2-3-4 kick the lawsuits out the door 
  61. (currently somewhere in         5-6-7-8 innovate don't litigate         
  62. the Bay Area, back sometime     9-A-B-C interfaces should be free
  63. at the end of this year)    D-E-F-O look and feel has got to go!
  64.      
  65.