home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / arch / 9053 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  2.8 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  2. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  3. Newsgroups: comp.arch
  4. Subject: Re: trapping speculative ops
  5. Message-ID: <BtLD9x.IBA@mentor.cc.purdue.edu>
  6. Date: 26 Aug 92 12:56:20 GMT
  7. References: <l8j0qkINNikb@exodus.Eng.Sun.COM> <BtEzrK.Jso.2@cs.cmu.edu> <GLEW.92Aug25180333@pdx007.intel.com>
  8. Sender: news@mentor.cc.purdue.edu (USENET News)
  9. Organization: Purdue University Statistics Department
  10. Lines: 56
  11.  
  12. I seem to have missed the original article by Mr. Lindsay.  But this has
  13. been a major problem since the possibility of any parallelism has occurred.
  14.  
  15.  
  16. >    But this is just a specific optimization. The broader question is,
  17. >    waht about traps while executing speculatively? There seem to be two
  18. >    answers:
  19.  
  20. >    1) Let the hardware do all the speculative execution. This puts it on
  21. >    the hardware's head to not trap until it knows it really should have.
  22.  
  23. >    2) Allow compiled code a way to postpone consequences until it
  24. >    wants to know. This covers e.g.
  25.  
  26. >        if( b != 0 ) c = a/b;
  27.  
  28. >    and an assortment of other cases.
  29.  
  30. >    The problem with (1) is that it makes for complex hardware. The
  31. >    problem with (2) is that instruction sets are generally not set
  32. >    up to allow such leeway.
  33.  
  34. >    Don        D.C.Lindsay     Carnegie Mellon Computer Science
  35.  
  36. The real problem is that if (1) is done, then the hardware may have to
  37. handle a large number of branches, and spend most of its resources on
  38. managing the large variety of cases.  I believe that the attempts to 
  39. do so have not been too successful. 
  40.  
  41. But it often is necessary to put in blocks even when this is not the case;
  42. I recall the following example:
  43.  
  44.     x = a/b;
  45.     if(y<0) x=z;
  46.  
  47. where the division takes long enough that the result of the first statement
  48. is produced after the result of the second.  Whatever the hardware protocol
  49. or the rearrangement of instructions, considerable inefficiency can occur.
  50. This means that alternative (2) causes slow execution.  With the way division
  51. is these days relative to other operations, doing the division first
  52. essentially puts it in the background, so it does not take up much time.
  53. But delaying the issuance of branches does not help, either.
  54.  
  55. I see no simple solution.  In many cases, compiler-programmer interaction may
  56. help, but often not even this.  If the code is necessarily branching, in many
  57. cases a VCISC approach may achieve much, as some types of branches are very
  58. fast in hardware.
  59.  
  60. One place where this is extremely important is SIMD, where a fairly simple
  61. instruction, with the simple branches taken in hardware, gets to be a major
  62. problem in turning processors on and off.
  63. -- 
  64. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  65. Phone: (317)494-6054
  66. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  67. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  68.