From: repo@depo.UUCP (repo man)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re:  The need for an assembler (was: Favorite CPU)
Distribution: world
Date: 17 Aug 92 04:30:08 EST
Organization: Organized?  HAH!

In article <1992Aug14.081326.24359@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>This gets to the heart of the matter: hll programmers depend on the compiler
>to do "magic" of various hues and colors for them; for most of them, they
>haven't a clue as to what's going on, and the best they can do is to "tinker"
>with what little options are available to them, namely the command-line
>switches to operating the compiler.  They have given over so much control
>of the ultimate running code to the compiler that they can never take it back.

All I expect from a compiler is to produce the most efficient code it can,
with the least amount of hassle.  Lets face it, most compilers do a more than
reasonable job of producing efficient code for most applications.  Ever use
GCC?

Not everyone shares your obsession with assembly language, nor does everyone want to take compiler-optimization 101.  You are also insinuating that high
level language programmers are generally less adept than assembly language
programmers, which is utter nonsense.  I personally am more interested in
portability, than limiting myself to using 68000 exclusively.  'C is usually
quite sufficient for my needs, but like life there are always exceptions.

I think the tools used to develop your application should be determined
directly by the scope in which the application will be used.  That is,
programs such as file compression utilities and the like should be developed
with portability kept strictly in mind, whereas some program which exploits
unique features of hardware should obviously be done in a lower-level
language.  The bottom line is, anyone who limits their experience for
whatever reason is only fooling themselves.

>Admittedly there will be unusually qualified hll writers who truly understand
>how to make the compiler do what they want.  So, instead of tinkering with
>the option switches, they tinker with the code.

My compiler does EXACTLY what I want.  Of course, my program may be slightly
slower than yours, which does the same thing, but if its not some time
critical routine, then what's the point?  What's more, while you're still 
optimizing, I'm finished and have written another program.  This whole
argument is beginning to resemble the CLI/GUI argument.

>
>By and large, assembly language programmers *do not* tinker.  I don't want to
>know if a compiler may/may not do it the "right" way.  I know that as an
>assembly programmer I can ensure that myself.  Even those better-qualified
>hll code-writers have to admit that they sometimes use assembly language
>in spurts to correct limitations of the compiler, thus they are still
>tinkerers, because effort is going into deciding where to apply how much.  This
>seems to imply a moving target with the attendant problems.

Must everyone know exactly how a microwave works, to determine the precise
time and setting required to produce the perfect cheeseburger?  The answer is
no.  Most people couldn't care less HOW it works, only that their burger
comes out neither over nor undercooked.  The whole idea is to be productive,
and that is entirely subjective.

--
		depo!repo@weird.miami.fl.us	"Of all the things I've lost,
repo man	...!mthvax!weird!depo!repo	 I miss my mind the most."