🚀 go-pugleaf

In article <nevin-191192004649@90.20.3.209> nevin@apple.com (Nevin ":-]" Liber) writes:

   In article <TMB.92Nov19002135@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas
   M. Breuel) wrote:
   > Actually, sadly, C dictates hardware design these days. I have heard
   > chip designers for some of the latest, greatest chip sets coming soon
   > to a workstation near you say "oh, we did this and that because many C
   > programs assume it; we would really have liked to do this
   > differently". Most of these are related to how characters, integer
   > sizes, and pointers interact in the minds of most C programmers.

   If you could elaborate on what these are, I'm sure that many of us would
   find that an interesting topic to discuss.

Some of the main assumptions are that characters are 8bits, that
the smallest addressable unit is a character, and that the number
of bits in a "machine word" is divisible by the number of bits per
character. Note that these are _not_ assumptions that are written
into the ANSI C standard. They are simply assumptions that C
programmers commonly make. The main fault of the C language is
that it doesn't force programmers to be aware of the places
where they make such assumptions.

   > C's
   > lack (in fact, intolerance) of runtime typing and array bounds
   > checking, on the other hand, mean that hardware designers these days
   > seem to make little effort to support such features,

   I don't see anything wrong with getting rid of features that people aren't
   using.  If those features were popular, C probably wouldn't be as popular
   as it is today.  We have lots of CISC archetectures with cool features that
   very few people ever find useful.  Why waste the silicon?

It is not necessarily a question of adding lots of features, but more
a question of what kinds of (largely unnecessary) assumptions C
programs like to make about word sizes and representations.  This
constrains the kind of choices that chip designers have among equally
RISCy designs.  Furthermore, it is pretty clear that there are lots of
people who do want more runtime safety (Apple's push for Dylan is just
one example), however, at the same time, they also do not want to
throw away all their old C code.

Perhaps my above assessment was a little too negative. Compromises are
already being made. For example, the Sparc has some support for tagged
arithmetic. Furthermore, with 64bit machines, it will be easier to
find space for tags in integers, pointers, and IEEE single-precision
floating point.

					Thomas.