home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10469 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  1.5 KB

  1. Xref: sparky comp.arch:10469 comp.lang.forth:3451
  2. Newsgroups: comp.arch,comp.lang.forth
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!elroy.jpl.nasa.gov!swrinde!ringer!news
  4. From: braker@ennex1.eng.utsa.edu (Jim Brakefield)
  5. Subject: Re: What's wrong with stack machines?
  6. Message-ID: <1992Nov6.182326.12025@ringer.cs.utsa.edu>
  7. Keywords: register allocation, stack cache
  8. Sender: news@ringer.cs.utsa.edu
  9. Nntp-Posting-Host: ennex1.eng.utsa.edu
  10. Organization: Univ of Texas at San Antonio
  11. References: <1992Nov6.094639.28441@email.tuwien.ac.at>
  12. Date: Fri, 6 Nov 1992 18:23:26 GMT
  13. Lines: 21
  14.  
  15. In article <1992Nov6.094639.28441@email.tuwien.ac.at>  
  16. anton@mips.complang.tuwien.ac.at (Anton Martin Ertl) writes:
  17. > |> The problem is that there hasn't been enough work done on stack  
  18. languages.
  19. > Or on stack machines.
  20. There is a perspective on RISC/register based architectures and CISC  
  21. and/or stack based machines.  It is: when and how do you do register
  22. allocation.  On a RISC machine the compiler does it.  On a stack machine
  23. the hardware does it on-the-fly, i.e., a particular data value or variable
  24. gets allocated to a specific hardware register during execution.  Thus 
  25. the debate reduces to something similar to the virtual memory debate of
  26. 10 years ago: Is hardware memory management efficient enough to displace
  27. programmer memory management?  (notice the context for virtual memory
  28. debate was ram <-> disk I/O, for stack machines it is registers <-> ram
  29. I/O).
  30.  
  31. James C. Brakefield
  32. braker@ennex1.eng.utsa.edu
  33. signal space >> address space >> symbol space
  34.