Path: utzoo!attcan!uunet!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Compiler Costs
Message-ID: <2319@l.cc.purdue.edu>
Date: 7 Jul 90 13:45:46 GMT
References: <1797@apctrc.UUCP> <373@e2big.mko.dec.com>
Organization: Purdue University Statistics Department
Lines: 63

In article <373@e2big.mko.dec.com>, gillett@ceomax..dec.com (Christopher Gillett) writes:
> In article <1797@apctrc.UUCP> zrra07@backus (Randall R. Appleton) writes:
> >I have a simple question:  Does anyone know what sort of speed-up
> >on gets by going from a good implementation of some algorithm in a
> >third generation language (C, Fortran) and a good optimizing compiler
> >to hand-coded assembly?

			.........................

>      3.  How talented are you?  The art of assembly language programming
>          is rapidly dying out.  Many people are really gifted high level
>          programmers who fall apart in the assembly world (absolutely no
>          jabs at anybody at all intended here, btw :-) ).  Problems are
>          solved much differently in the two different worlds.  If you try
>          to do a straight translation from high level to low level, you're
>          not doing much better than the compiler (in fact, probably much
>          worse).  However, if you are a gifted machine-level hacker, and
>          you have really understand the program you want to convert (like,
>          did you write it yourself?), then you might gain significantly
>          by converting the code. 

I am inclined to doubt that those suffering from lack of understanding of
the relation between architecture and "how to do it efficiently" will even
be gifted high level programmers.  To produce good code, it is necessary to
understand the cost considerations, and I find it difficult to believe that
this can be done at the limited level of HLLs.

There are two problems with the present assembler.  First, there is the
gosh-awful syntax and arbitrariness of them.  Suppose that for appropriate
x, y, and z, the operation x = y - z can be performed by a single machine
instruction.  Now I understand what the machine is doing, but how do I
communicate it to the assembler?  Those who have used more than one assembler
are likely to have seen assemblers with the orders of x, y, and z quite
different.

There is also the attitude in the computer field that the user need not take
these things into account, that the compiler is a great genius and should do
it all for you.  This is similar to the attitude which existed in the public
schools almost universally, and is not completely gone yet, that reading
should be learned only by the whole word method, and the idea of sounding
out words, especially in English where there are "so many exceptions", should
not be taught until much later.  I would put the hardware of the most
machines I know as considerably simpler than any HLL.

> These are just the first few things that pop into mind.  My opinion on the
> whole matter is that you should consider language issues long before putting
> down any code.  The very nature of the program should dictate which language
> to use.  Further, it's been my observation that code conversion jobs (whether
> from one high level language to another, or from a high level to a low level,
> or low to high) are expensive, time consuming, and not very rewarding.

I would disagree somewhat.  I have found starting with a Fortran program 
usually not helpful, but not the case with C.  Even the talented human can
learn from the apparently stupid observations made by the less talented,
including the compiler.  Others have observed that reverse engineering 
their own programs can result in improvements.

But one is unlikely to produce an artist by having the apprentice color within
the lines.  
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)