Xref: utzoo comp.std.c:293 comp.lang.c:12030 comp.arch:6134
Path: utzoo!attcan!
From: leichter@venus.ycc.yale.edu (Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)leichter@venus.ycc.yale.edu (Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)leichter@venus.ycc.yale.edu (Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)leichter@venus.ycc.yale.edu (Jerry Leic)
Newsgroups: comp.std.c,comp.lang.c,comp.arch
Subject: Re: Third public review of X3J11 C (a scientist speaks up)
Message-ID: <36243@yale-celray.yale.UUCP>
Date: 23 Aug 88 16:57:33 GMT
Sender: root@yale.UUCP
Organization: Yale Computer Center, New Haven
Lines: 105

In article <887@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes...
 
>I use C for numerical programming, and then have to edit the resulting .s
>file.  All of the languages, including C, are woefully deficient is letting
>the user use the capacities of the machines.  If C is to be a good flexible
>language, the committee should widely advertise for complaints about the
>deficiencies of the language before starting out.

On the contrary:  C is NOT woefully deficient for the vast majority of
applications to which the vast majority of "paying users" are interested in
applying it.  As later comments make clear, the kinds of users Mr. Rubin has
in mind are rather different.  The fact of the matter is, hardly anyone thinks
that "fixed-point arithmetic" (as opposed to integer) is important.  It just
does not come up in the vast majority of uses to which computers are put.

Developing software is an expensive proposition.  Everything added to a
language has to be implemented somewhere, by someone.  Then it has to be
debugged, supported, and maintained.  There are only two ways this will
happen:  If someone is willing to pay for it; or when someone is willing
to do it out of their own love for the subject.

>I would have no trouble coming up with pages of these items.  But the last
>time I did something like this, in reply to the open invitation to attend
>the meeting on the IEEE floating-point convention, was to receive an invi-
>tation to attend!  I do not have the time to attend meetings on software.

Ah, so Mr. Rubin is willing to COMPLAIN, but he is NOT willing to do the work
out of his own love for the subject.  He certainly gives no indication that
he is willing (or able) to pay to have it done either.

>Another problem is that the language gurus are unsympathetic to ideas which
>run counter to their perception of computing needs.

I am a "language guru", though my interests happen to be in parallel program-
ming languages.  Again, why should I care what Mr. Rubin thinks "computing
needs" are when he can't provide money, isn't willing to invest his own time,
and can only provide the most specialized examples of what such features might
be used for?

>						      They see integer 
>arithmetic as primarily for addressing and looping; I see integer arithmetic
>as important for number-crunching.  What about fixed-point (_not_ integer)
>arithmetic?  What about the use of overflow?  What about division with
>simultaneous quotient and remainder?  What about an operation or function
>returning a string of values?  What about table-driven branches?  What 
>about inserting new operators, using the processor syntax to specify the
>argument structure of these operators?  In fact, what about using the 
>easy-to-use hardware operators on most machines?  A good example is &~,
>which is more useful than &, and is hardware on many machines, including
>the ones for which C was initially written.  Many of those machines do not
>even have a hardware &.

What about all these things?  Being absolutely brutal about it:  Why should
I (or other readers) care?  What will it gain us to worry about this?

>How many useful instructions have disappeared from hardware because they
>do not occur in the HLLs?

Along the same brutal lines, my answer is:  No USEFUL instructions have
disappeared at all.  What has disappeared are a lot of non-essential ideas
that were tossed in back in the days when computer architecture was a new
field, with a large research component.  No one really knew what would turn
out to be "useful".

Well, for better or for worse, computer architecture isn't like that any more.
Computer design is a multi-billion dollar industry.  It is driven, not by what
people might WANT in some abstract sense, but by what they are willing and
able to pay for.  THAT is the only workable definition of "useful", and on
that scale the things Mr. Rubin wants have long ago fallen to the bottom of
the list.

>			    Multiprecision arithmetic needs unsigned
>multiplication and division to be efficient, and not floating point
>arithmetic.  The presence of a single hardware instruction can be
>essential to an algorithm being worthwhile; if the instruction is in
>software, it is more likely to appear in hardware.
>-- 
>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
>Phone: (317)494-6054
>hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)

It's painful to see economics dominating a field one loves and pushing it in
directions one is not inclined to go.  I'm not unsympathetic to Mr. Rubin's
position; my own background, way back when, is in mathematics (complex analy-
sis and a bit of analytic number theory).  Even the work I do now is beyond
the current "commercial" leading edge, and I am sometimes frustrated by the
way hardware manufacturers put roadblocks in the way of doing "obviously
useful" things, because they are too busy heading in other directions.  But
that's life.

The USEFUL thing for Mr. Rubin to do, if he really thinks these issues are
important, is to work at convincing others of it.  Not by complaining in this
and other newsgroups about how he is being ignored.  But exactly by spending
some time with those committees, by offering some real alternatives, by
showing how what he proposes is useful to people other than himself.  Frankly,
I doubt anything he can do will ever get major commercial ventures interested.
But that doesn't mean he can't get other researchers interested.  Many people
are able to design and build special-purpose hardware and software today; if
Mr. Rubin talked to some of them, he might discover that many good research
hardware hackers have the tools, but are lacking interesting problems.  I
will say, however, that his chances of getting people interested would improve
markedly if he stopped complaining about how he didn't "have the time to
attend meetings on software".  Very few computer scientists have the time to
attend meetings on statistics either.
							-- Jerry