home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / misc / 3796 < prev    next >
Encoding:
Text File  |  1992-11-19  |  3.7 KB  |  72 lines

  1. Newsgroups: comp.lang.misc
  2. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  3. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  4. Subject: Re: languages which allow the introduction of new operators
  5. Message-ID: <Bxz8px.FBx@mentor.cc.purdue.edu>
  6. Sender: news@mentor.cc.purdue.edu (USENET News)
  7. Organization: Purdue University Statistics Department
  8. References: <1992Nov15.032459.3069@udel.edu> <Bxr9vx.KBD@mentor.cc.purdue.edu> <1992Nov18.154754.1848@udel.edu>
  9. Date: Thu, 19 Nov 1992 18:58:43 GMT
  10. Lines: 60
  11.  
  12. In article <1992Nov18.154754.1848@udel.edu> carroll@dori.cis.udel.edu (Mark C. Carroll) writes:
  13. >In article <Bxr9vx.KBD@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
  14. >]In article <1992Nov15.032459.3069@udel.edu> carroll@thorin.cis.udel.edu (Mark C. Carroll) writes:
  15. >]]In article <BxMCxA.3nM@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  16.  
  17.             .......................
  18.  
  19. >Any optimization, particularly on modern architectures, has got to
  20. >consider its affect on pipeline fills, branch predictions, register
  21. >allocations, memory and cache uses, and dozens of other factors.  Do
  22. >you think that you're qualified to judge what affect your two-cycle
  23. >savings will have on the rest of your program? If so, you're in the
  24. >wrong field - you should be designing compilers.
  25.  
  26. I am quite aware of all of these.  In most of the cases I have discussed
  27. in any detail, I can see ways that the language design prohibits many of
  28. these considerations.  
  29.  
  30. As to designing compilers, this is a massive operation, not to be done by
  31. one or two people.  And when it comes to optimization, these compiler
  32. designers should ask for things to be considered which they do not now
  33. consider.  This applies to language design, as well.  The people who 
  34. seem to dominate the field assume that their considerations are ALL
  35. that matter.
  36.  
  37. >]The semantic model of the language can, however, greatly inhibit the
  38. >]programmer.  Try communicating floating binary from one machine to
  39. >]another; the only semi-portable way I have seen are to convert to
  40. >]higher precision floating decimal, transmit that, and convert back.
  41.  
  42. >What does that have to do with the semantic model of the language?
  43. >That's a very hardware related issue. If I design a language that uses
  44. >floating point numbers, I'm restricted to using whatever internal
  45. >float format the hardware designer chose for the architecture I'm
  46. >learning. That's got nothing to do with the semantic model of the
  47. >language.
  48.  
  49. Did I say anything about matching the internal representations of
  50. the numbers?  We can communicate binary integers across machines
  51. and implementations; the much used notation 0ddddd for octal and
  52. 0xdddddddd for hexadecimal, bad as they are, do this explicitly.
  53. Algol had a different way to do this, and it could handle other
  54. bases explicitly; I believe it could also do this for non-integers,
  55. but the syntax did not carry over well.  Most languages and 
  56. compilers allow for explicit writing of fixed-point decimals 
  57. and floating-point decimals.  However, there are many situations
  58. in which people may wish to communicate non-integers in hex.  I
  59. have found cases in which decimal is inconvenient and even leads
  60. to confusion.
  61.  
  62. I have seen the problem addressed by coming up with a characterization
  63. of the number of decimal digits which need to be communicated so that
  64. a given number of bits are correctly communicated by conversion.  This
  65. I do not find to be satisfactory, and I see no reason why this insistence
  66. on decimal as the only means of communication is made.
  67. -- 
  68. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  69. Phone: (317)494-6054
  70. hrubin@snap.stat.purdue.edu (Internet, bitnet)  
  71. {purdue,pur-ee}!snap.stat!hrubin(UUCP)
  72.