home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10894 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  2.6 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!agate!doc.ic.ac.uk!uknet!acorn!armltd!dseal
  2. From: dseal@armltd.co.uk (David Seal)
  3. Newsgroups: comp.arch
  4. Subject: Re: What's RIGHT with stack machines
  5. Message-ID: <9840@armltd.uucp>
  6. Date: 18 Nov 92 17:43:11 GMT
  7. References: <dak.721621337@messua>
  8. Sender: dseal@armltd.uucp
  9. Distribution: comp
  10. Organization: A.R.M. Ltd, Swaffham Bulbeck, Cambs, UK
  11. Lines: 45
  12.  
  13. In article <dak.721621337@messua> dak@messua.informatik.rwth-aachen.de
  14. (David Kastrup) writes:
  15.  
  16. >See the MIPS processors (micro without interlocking pipeline stages) for
  17. >a clever design idea: they have simply left out all instruction scheduling.
  18. >If you start a command using a register which a previous command still has
  19. >to fill up, there is no delay, but the OLD value is used.
  20. >So the compiler/assembler will have to include nops by hand in order to
  21. >prevent register clashes. On the other hand, command interlocking can be
  22. >done by compilers. And you can use the die space thus gained for other
  23. >purposes (bigger cashes, etc.). And because of the Harvard bus architecture,
  24. >there is no difference between waiting for interlock or fetching a nop.
  25. >Only problem: code tends to get longer.
  26.  
  27. Second problem: if a second implementation has different "natural" delays
  28. for instructions to produce their results, then something is going to break.
  29. Within limits, you can choose what it is - e.g. any of the following will
  30. do:
  31.  
  32.   * The second implementation has to reintroduce the instruction scheduling
  33.     hardware. It probably doesn't have to reintroduce *all* of it - e.g. if
  34.     your original implementation had one load delay slot and your new one
  35.     has two, you only have to protect one of them. But simply having
  36.     instruction scheduling hardware at all is a large fraction of the
  37.     complexity involved, so this may not save as much as you might have
  38.     thought.
  39.  
  40.   * All code has to be recompiled for the new hardware. Unfortunately, not
  41.     all vendors give you the sources...
  42.  
  43.   * You impose a rule on yourself that you simply won't use implementations
  44.     that change the natural delays. Of course, this may well give
  45.     less-than-optimal results in a few years' time.
  46.  
  47. Personally, I see this technique and others that expose implementation
  48. details to the programmer as being rather short-sighted. They buy you a nice
  49. short-term gain, at the cost of long-term problems. (Of course, if you're a
  50. small company trying to get your architecture off the ground, you may *need*
  51. the short term gains: if you don't get them, there won't *be* any long term
  52. to worry about...)
  53.  
  54. David Seal
  55. dseal@armltd.co.uk
  56.  
  57. All opinions are mine only...
  58.