home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / misc / 3828 < prev    next >
Encoding:
Internet Message Format  |  1992-11-21  |  3.1 KB
  1. Path: sparky!uunet!spool.mu.edu!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: Pointers
  5. Followup-To: comp.lang.misc
  6. Date: 22 Nov 92 01:38:04
  7. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  8.     Perceptive)
  9. Lines: 49
  10. Message-ID: <TMB.92Nov22013804@arolla.idiap.ch>
  11. References: <1992Nov7.115620.29967@syacus.acus.oz.au> <TMB.92Nov19002135@arolla.idiap.ch>
  12.     <nevin-191192004649@90.20.3.209>
  13. Reply-To: tmb@idiap.ch
  14. NNTP-Posting-Host: arolla.idiap.ch
  15. In-reply-to: nevin@apple.com's message of 19 Nov 92 08:53:49 GMT
  16.  
  17. In article <nevin-191192004649@90.20.3.209> nevin@apple.com (Nevin ":-]" Liber) writes:
  18.  
  19.    In article <TMB.92Nov19002135@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas
  20.    M. Breuel) wrote:
  21.    > Actually, sadly, C dictates hardware design these days. I have heard
  22.    > chip designers for some of the latest, greatest chip sets coming soon
  23.    > to a workstation near you say "oh, we did this and that because many C
  24.    > programs assume it; we would really have liked to do this
  25.    > differently". Most of these are related to how characters, integer
  26.    > sizes, and pointers interact in the minds of most C programmers.
  27.  
  28.    If you could elaborate on what these are, I'm sure that many of us would
  29.    find that an interesting topic to discuss.
  30.  
  31. Some of the main assumptions are that characters are 8bits, that
  32. the smallest addressable unit is a character, and that the number
  33. of bits in a "machine word" is divisible by the number of bits per
  34. character. Note that these are _not_ assumptions that are written
  35. into the ANSI C standard. They are simply assumptions that C
  36. programmers commonly make. The main fault of the C language is
  37. that it doesn't force programmers to be aware of the places
  38. where they make such assumptions.
  39.  
  40.    > C's
  41.    > lack (in fact, intolerance) of runtime typing and array bounds
  42.    > checking, on the other hand, mean that hardware designers these days
  43.    > seem to make little effort to support such features,
  44.  
  45.    I don't see anything wrong with getting rid of features that people aren't
  46.    using.  If those features were popular, C probably wouldn't be as popular
  47.    as it is today.  We have lots of CISC archetectures with cool features that
  48.    very few people ever find useful.  Why waste the silicon?
  49.  
  50. It is not necessarily a question of adding lots of features, but more
  51. a question of what kinds of (largely unnecessary) assumptions C
  52. programs like to make about word sizes and representations.  This
  53. constrains the kind of choices that chip designers have among equally
  54. RISCy designs.  Furthermore, it is pretty clear that there are lots of
  55. people who do want more runtime safety (Apple's push for Dylan is just
  56. one example), however, at the same time, they also do not want to
  57. throw away all their old C code.
  58.  
  59. Perhaps my above assessment was a little too negative. Compromises are
  60. already being made. For example, the Sparc has some support for tagged
  61. arithmetic. Furthermore, with 64bit machines, it will be easier to
  62. find space for tags in integers, pointers, and IEEE single-precision
  63. floating point.
  64.  
  65.                     Thomas.
  66.