home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10949 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  3.4 KB
  1. Xref: sparky comp.arch:10949 comp.lang.misc:3804
  2. Path: sparky!uunet!usc!rpi!psinntp!psinntp!dg-rtp!sheol!throopw
  3. From: throopw@sheol.UUCP (Wayne Throop)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: how to advocate new software/hardware features
  6. Message-ID: <722143392@sheol.UUCP>
  7. Date: 19 Nov 92 00:35:00 GMT
  8. References: <TMB.92Nov17181419@arolla.idiap.ch>
  9. Lines: 59
  10.  
  11. : From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  12. : Message-ID: <TMB.92Nov17181419@arolla.idiap.ch>
  13. : If anything, if you are going for efficiency, the C approach is more
  14. : portable, saying that "int" is whatever is fastest and "long" gives
  15. : you extra bits. "int" essentially used to mean "CPU register size" and
  16. : "long" was largely intended to mean "probably twice CPU registers
  17. : size, which coincidentally is what multiply may give you, unless
  18. : that's too inconvenient". The only problem with this approach was
  19. : that the early C compilers for 32bit machines messed up and didn't
  20. : make "long" 64bits.
  21.  
  22. It isn't clear that choosing 32 bits for long was a case of "messing up"
  23. at that point.  The "messing up" happened long before that, IMHO, in
  24. that the notion of the int/long distinction inherrently encouraged
  25. users towards ambiguity.
  26.  
  27. In particular, in addition to meaning "register size" and "twice
  28. register size", they were used for "int = index into memory-sized
  29. things" and "long = index into file-sized things", and "int = counting
  30. chars in strings" and "long = counting lines in files", and other such
  31. distinctions.
  32.  
  33. Given the existing code base at the time of the 16-bit-cpu to 32-bit-cpu
  34. transition in the "minicomputer" world, it would have been disastrous
  35. to use the "register size" distinction, and make long be 64 bits.
  36. Most code used long to mean "index into a file" or "counting lines
  37. in files" and so on.  The 16-to-32-bit transition simply made the
  38. size of memory comparable to the size of files, and so the choice
  39. of having both int and long be 32 bits, instead of having both
  40. short and int be 32 bits, seems an appropriate one.
  41.  
  42. So while it was a Good Thing to have a portable name for "an integer
  43. size natural to the machine" and other such, it was a Bad Thing to
  44. make this a language primitive and then encourage everybody to use it
  45. to express other unrelated abstract properties.
  46.  
  47. I think the "right way" would have been to make the primitive notation
  48. be a range type, and then have certain standard named types in a
  49. standard include file, to address the "whatever's best for this
  50. machine" issue.
  51.  
  52. : So again, the problem of having machine independent access to machine
  53. : specific features hasn't been solved because it's inherently not
  54. : solvable. With somewhat better conventions, however, we might be able
  55. : to do a little better than we are doing now.
  56.  
  57. Agreed.  But replacing existing solutions with new, better solutions
  58. is often not economically feasible.  For example, replacing internal
  59. combustion with external combustion or remote combustion or hybrid
  60. systems is not done, not because of perversity or stubbornness, but
  61. because of the economics of the situation.  C's "short/int/long" is
  62. an example of this internal-combustion-engine scenario, as is
  63. Herman Rubin's problems getting the language features he wants.
  64.  
  65. It's an economic thing.  So the way to make progress is to find
  66. a way to solve the economic problems involved.  The technological
  67. problems are easy by comparison.
  68. --
  69. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  70.