home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10442 < prev    next >
Encoding:
Text File  |  1992-11-07  |  2.4 KB  |  52 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sun-barr!ames!agate!rsoft!mindlink!a684
  3. From: Nick_Janow@mindlink.bc.ca (Nick Janow)
  4. Subject: Re: What's wrong with stack machines?
  5. Organization: MIND LINK! - British Columbia, Canada
  6. Date: Fri, 6 Nov 1992 05:44:19 GMT
  7. Message-ID: <17189@mindlink.bc.ca>
  8. Sender: news@deep.rsoft.bc.ca (Usenet)
  9. Lines: 41
  10.  
  11. lindsay+@cs.cmu.edu (Donald Lindsay) writes:
  12.  
  13. > Surely typical stack-language programs can be mechanically transformed
  14. > (recompiled) into non-stack forms.
  15.  
  16. Sure, and you can emulate a 486 on a 6502; it just doesn't run as fast.
  17. Stack-oriented programs tend to have a lot of subroutine calls.  This would
  18. bog down a non-stack processor.  There are other programming techniques that
  19. run fast on a stack machine, but not on a non-stack one.  I don't think you
  20. can mechanically transform that stack program to one that runs efficiently on
  21. a non-stack processor.  Stack-oriented programs are structurally different
  22. from non-stack programs.
  23.  
  24. > As far as I can tell, the only win for stack machines is code density when
  25. > speed doesn't matter.
  26.  
  27. Stack machines tend to be smaller and simpler than the typical processors
  28. coming out these days (486, Alpha, SPARC, etc), without compromising speed.
  29. Looking at it the other way, for the same amount of silicon and engineering
  30. effort, the stack machine would probably be a lot faster.
  31.  
  32. Code density does affect speed in many cases.  If you only have 8Kbytes of
  33. high-speed RAM, wouldn't you like to be able to stick much of the program in
  34. that space?  Stack machines are optimized for code re-use.
  35.  
  36. A processor with multiple stacks is probably easier to design for parallel
  37. operations than one with a large array of random access registers.  The RTX,
  38. for example, allows simultaneous access (one clock cycle) to both stacks,
  39. memory, and two I/O ports.  Future processors might add a floating point
  40. stack, a string stack, a logic (IF, WHILE, etc) stack, a locals stack, or any
  41. other specialized stack that was appropriate.  Memory access could be split
  42. into data and instruction.  Parallel processing ports could be added.  Note
  43. that present stack processors offer high performance without pipelining or
  44. memory caching.
  45.  
  46. Processor design has mainly focused on optimizing for non-stack languages;
  47. there's a lot to explore in stack processor hardware and software design.
  48.  
  49. --
  50.  
  51. Nick_Janow@mindlink.bc.ca
  52.