home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10395 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  4.6 KB
  1. Xref: sparky comp.arch:10395 comp.lang.forth:3444
  2. Path: sparky!uunet!europa.asd.contel.com!awds.imsd.contel.com!news!usc!cs.utexas.edu!uwm.edu!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!spool.mu.edu!yale.edu!jvnc.net!nuscc!ntuix!eoahmad
  3. From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
  4. Newsgroups: comp.arch,comp.lang.forth
  5. Subject: Re: What's RIGHT with stack machines (Was Re: What's wrong...)
  6. Message-ID: <1992Nov5.050640.24183@ntuix.ntu.ac.sg>
  7. Date: 5 Nov 92 05:06:40 GMT
  8. References: <Bx5AIr.EAy.2@cs.cmu.edu>
  9. Organization: Nanyang Technological University - Singapore
  10. Lines: 95
  11. X-Newsreader: TIN [version 1.1 PL6]
  12.  
  13. Philip Koopman (koopman+@cs.cmu.edu) wrote:
  14. : 
  15. : 
  16. : This is a consolidated attempt to address some of the points
  17. : people have been bringing up about stack-based architectures.
  18. : It's written from the point of view who has actually
  19. : made a living designing and selling them (first with
  20. : WISC Technologies, later with Harris Semiconductor RTX family).
  21. : 
  22. : PIPELINING
  23. : 
  24. : Stack processors don't need to be pipelined for ALU & 
  25. : operands, because the operands are immediately available
  26. : in the top of stack buffer registers.  Access to the on-CPU
  27.  
  28. Pipelining is required for maximum performance but I do not foresee any
  29. special problems with implementing stack based pipelined operations.
  30. Just use invisilbe registers, and better still multiple stack architecture.
  31. It is extremely attractive to me in DSP applications where lists are the
  32. most common data structures used.
  33.  
  34. : embedded control it matters a lot, especially when you're limited
  35. Refer to another posting on why code size is till important for the ultimate
  36. performance. Basically it is the cache bottle-neck that I observe in 
  37. current microprocessors running only still relatively simple programs.
  38.  
  39. : 
  40. : COMPILERS
  41. : 
  42. : Stack compilers aren't currently very efficient -- but
  43. : that's because no-one has really tried all that hard.
  44. : I've published an algorithm and experimental results that
  45. : suggest that stacks can be made about as efficient as
  46. : registers in terms of keeping local variables at the
  47. : top level of the memory hierarchy.  The work is based on GNU C 
  48. : intermediate code (P. Koopman, A Preliminary
  49. : Exploration of Optimized Stack Code Generation, 1992
  50. : Rochester Forth Conference, in press; uuencoded postscript
  51. : copy of paper available upon request).
  52. : 
  53. : I'm currently working (at hobby level) on a GNU C stack-based compiler 
  54. : that will generate very compact code.  Of course, one could
  55. : always argue that trying to map C to a stack machine will
  56. : necessarily be less efficient than mapping a stack-friendly
  57. : language such as Forth to a stack machine.  The issue starts
  58. : to have more to do with marketing than technology, but
  59. : seems like a neat challenge.
  60.  
  61. I have not tried this yet but from my experience writing a "sissy
  62. compiler", I  notice that my intermediate data structure is a linked list.
  63. It may not be optimal but it is not optimal becaue the input is not 
  64. optimal.
  65.     After all the compiler just generate what we ask it to do.
  66.  
  67. The optimisation should be done at the source code level.
  68.  
  69. I also observe that the advantages of the 3 address opcode is exaggerated.
  70. When I look at a "convolution code fragment", I do not recall any 3 address
  71. instruction genereated by GCC for sparc.
  72.  
  73. What is the point of providing a 3 address when 99% of the cases need only
  74. 2 address? Tanenbaum had written a paper analysing the frequencies of the
  75. number of operands.
  76.     I do not pay particular attention because it is too dependent on the
  77. test programs.
  78.  
  79. Someone will say that "convolution code is not frequent".
  80. You can think of it as operations on link lists.
  81.     Isn't that a very common operation. Of course it can be substituted
  82. by the 3 address instructions, but isn't it more natural to use a special
  83. stack machine for it?
  84.  
  85. I'm posting this article because I could be dead wrong. I'll try to
  86. read Kopman's paper but I doubt it will address my suspicions.
  87.  
  88. Any comment is most appreciated.
  89. : 
  90. : APPLICATIONS
  91. : 
  92. : Overall, I'd say stack machines are now an excellent fit
  93. : for high performance in a low cost system (not necessarily
  94. : highest performance given unlimited cost).  They should do
  95. : especially well in embedded applications.  
  96. : 
  97. I believe you could be wrong. the T9000 is nothing compared to better 
  98. designed stack machines.
  99.     It is only waiting for better compilers and architectures. Admittedluy
  100. it is harder but may be worth it to overcome the von-neuman limitations,
  101. or rather optimizations of bandwidth.
  102.  
  103. --
  104. Othman bin Ahmad, School of EEE,
  105. Nanyang Technological University, Singapore 2263.
  106. Internet Email: eoahmad@ntuix.ntu.ac.sg
  107. Bitnet Email: eoahmad@ntuvax.bitnet
  108.