home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10675 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  2.5 KB
  1. Xref: sparky comp.arch:10675 comp.lang.forth:3485
  2. Path: sparky!uunet!know!cass.ma02.bull.com!mips2!news.bbn.com!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!Sirius.dfn.de!Urmel.Informatik.RWTH-Aachen.DE!messua!dak
  3. From: dak@messua.informatik.rwth-aachen.de (David Kastrup)
  4. Newsgroups: comp.arch,comp.lang.forth
  5. Subject: Re: What's RIGHT with stack machines
  6. Message-ID: <dak.721621337@messua>
  7. Date: 13 Nov 92 02:22:17 GMT
  8. References: <Bx5AIr.EAy.2@cs.cmu.edu> <1992Nov4.103008.2641@Informatik.TU-Muenchen.DE> <MIKE.92Nov9004026@guam.vlsivie.tuwien.ac.at> <id.D6UU.5Z@ferranti.com> <lg0eheINNs7l@exodus.Eng.Sun.COM>
  9. Sender: news@Urmel.Informatik.RWTH-Aachen.DE (Newsfiles Owner)
  10. Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
  11. Lines: 35
  12. Nntp-Posting-Host: messua
  13.  
  14.  
  15. >>I predict that before too long all high performance commodity micros will do
  16. >>scheduling at runtime.
  17.  
  18. >I don't think the situation is as clear-cut as you describe it.
  19.  
  20. >There are certain scheduling techniques that tend to work well no
  21. >matter where you use them -- as long as you have enough registers, it
  22. >doesn't hurt to stick a few instructions between a load into a
  23. >register and the subsequent use of that register.  On superscalar
  24. >machines, it is generally a bad idea to do too many of exactly the
  25. >same thing in a big lump (i.e., ld, ld, ld or fadd, fadd, fadd), and
  26. >if you have the option of mixing things up a bit, you should.
  27. >Increasing the size of basic blocks (through code replication,
  28. >typically) is another trick for helping most machines, since branches
  29. >often stall pipelines.
  30.  
  31. >These are general rules, and they won't yield optimum performance, but
  32. >you must trade them off against the costs of generating
  33. >implementation-specific code.  Those costs include
  34.  
  35. >  (1) less sharing of text and libraries
  36. >  (2) lots of cache flushing and
  37. >  (3) scheduling and register allocation are not necessarily cheap.
  38.  
  39. See the MIPS processors (micro without interlocking pipeline stages) for
  40. a clever design idea: they have simply left out all instruction scheduling.
  41. If you start a command using a register which a previous command still has
  42. to fill up, there is no delay, but the OLD value is used.
  43. So the compiler/assembler will have to include nops by hand in order to
  44. prevent register clashes. On the other hand, command interlocking can be
  45. done by compilers. And you can use the die space thus gained for other
  46. purposes (bigger cashes, etc.). And because of the Harvard bus architecture,
  47. there is no difference between waiting for interlock or fetching a nop.
  48. Only problem: code tends to get longer.
  49.