home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10971 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  2.6 KB
  1. Xref: sparky comp.arch:10971 comp.lang.misc:3818
  2. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!rpi!psinntp!psinntp!dg-rtp!sheol!throopw
  3. From: throopw@sheol.UUCP (Wayne Throop)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: Hardware Support for Numeric Algorithms
  6. Message-ID: <722228704@sheol.UUCP>
  7. Date: 20 Nov 92 00:09:39 GMT
  8. References: <722061187@sheol.UUCP> <1efh6vINNm6c@network.ucsd.edu>
  9. Lines: 46
  10.  
  11. : From: mbk@lyapunov.ucsd.edu (Matt Kennel)
  12. : Message-ID: <1efh6vINNm6c@network.ucsd.edu>
  13. : The point, is, he [..Herman Rubin..]
  14. : wants a high-level real language, with real optimizers,
  15. : that nonetheless, does not consider hardware dependence to be anathema.
  16.  
  17. Except that when such capabilities are pointed out, he sneers at
  18. them, and then asks for something else.  For example, gcc can generate
  19. inline procedures with assembly instructions interspersed.  For pointing
  20. this out, people get sneered at, and told that the notation isn't
  21. simple enough.
  22.  
  23. When solutions to notation problems are presented, such as introducing
  24. operators into gcc by the usual lex and yacc notations, or by
  25. preprocessing with the TXL system mentioned by Matt a bit later, people
  26. get sneered at, and told that specifying syntax in these ways is
  27. too difficult.
  28.  
  29. So as near as I can see, solutions to the problems Herman Rubin
  30. complains about are out there, and available for use now.  Herman Rubin
  31. simply refuses to use them until they are customized for his needs to
  32. an uneconomical extent.
  33.  
  34. The bottom line: Herman Rubin is attributing to malice and stupidity 
  35. what is adequately explained by simple economics.
  36.  
  37. : So if C doesn't know how to do a fp divide with integer quotient and a
  38. : remainder in one instruction, or how to do a "add in parallel, but
  39. : only on those processors in this mask" (a CM),
  40. : then no amount of higher-level rewriting will help.
  41.  
  42. Yes, this is the most central problem, which Jim Giles mentioned also.
  43. Some method is needed which will specify the generated code, and yet
  44. will fit in with the optimizations and register allocations and so on
  45. which are already in place.  Jim says this "isn't too difficult", but 
  46. I think it is the single most difficult part.  I've seen several
  47. solutions, each with some advantages over the others.
  48.  
  49. But ultimately, when you are going after that last 1% or .1% of speed,
  50. you will simply have to spell out the istream, operation by operation.
  51. No amounts of hints to the optimizer will ever be enough, because
  52. ultimately the optimizer can only deal with hints it is prepared to
  53. accept, and if a programmer comes up with something unforseen by the
  54. optimizer, there's no simple way to give a hint about it.
  55. --
  56. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  57.