Xref: utzoo comp.lang.c++:2088 comp.lang.c:14311 comp.lang.forth:656 comp.lang.fortran:1516 comp.lang.misc:2170 comp.arch:7329
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.forth,comp.lang.fortran,comp.lang.misc,comp.arch
Subject: Re: Assembly or ....
Summary: And what about all the things not in the ken of your HLL?
Message-ID: <1031@l.cc.purdue.edu>
Date: 27 Nov 88 12:29:38 GMT
References: <1388@aucs.UUCP> <729@convex.UUCP> <1961@crete.cs.glasgow.ac.uk> <6529@june.cs.washington.edu>
Organization: Purdue University Statistics Department
Lines: 59

In article <6529@june.cs.washington.edu>, kolding@june.cs.washington.edu (Eric Koldinger) writes:
> In article <1961@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes:
> >I don't agree that there is ever any necessity to code in assembler. We
> >have languages that produce code just as good as hand crafted assembler
> >(such as C), so why not use them for this sort of thing.
> 
> Ah, but wouldn't that be nice.  Optimizing compilers that could generate
> code as good as we can generate by hand in all cases.  Let me know when
> someone writes one.

I agree completely.  Also, on the various machines I know, there are operations
I want to use about which the compiler knows nothing.  To SOME extent, SOME
of these can be added to the HLL.  But I have not seen a scheme to do this
which will not mess up attempts at automatic optimization.  

Also, these interesting and useful instructions vary somewhat from machine to
machine.  I am appalled by what the language designers have left out, and also
what has been relegated to subroutines.  What can one think of a compiler 
designer who has relegated to a subroutine an operation whose inline code
is shorter than the caller's code to use the subroutine?  This is rampant.

I recently had the occasion to produce a subroutine for a peculiar function.
In principle, it should have been done in a HLL.  I would prefer to do so.
BUT, the following was needed:

  Take a double floating number, and extract the exponent and the mantissa.
  This involves having a double long type.

  Reverse the above operation.

  Addition, shifting, Boolean operations on double long.

  Checking an "overflow field."  Not the usual overflow.

If these are available, C would do a good job PROVIDED it put everything
in registers, if possible.

A few of the compilers I have seen do a fair job; the others would get 
a D--.  (Since D-- = C in C, this might be why C is so bad :-))  But one
of the most amazing things that I have seen in the workings of the 
designers is the assumption that the compiler has all the information
necessary to produce optimized code!  There is no provision for input
as to frequency of branches.  Should the common condition be the branch
or the rare condition?  Does it make a difference in the combination?
Since I have examples where the branches are of comparable frequencies,
examples where the ratio of the frequencies are from 10-200, where the
ratio is a few thousand, and where one branch may never occur, I certainly
feel that I have input.  I think the compilers should be interactive, and
discuss the various possibilities with the programmer.  I can even give
cases where the dictum to remove a calculation from within a loop is wrong.

All of mankind does not know enough to produce a good language, or to 
produce a good implementation of a language.  There are more operations
appropriate to hardware than are dreamed of in all computer scientists'
philosophies.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)