From: ctm@ardi.com (Clifford T. Matthews)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: ARDI
Date: Mon, 31 Aug 92 10:05:45 GMT

Charles Lasner just posted:
"...
The closest one was someone who stated that a compiler was able to produce
the *same* algorithm as I used in assembler.  It was *almost* the same,
but was actually different, because it required double-precision arithmetic
(longwords) to guarantee that the code worked.  The assembler solution is
to admit to a restriction, and depend on programmer competence to avoid the
mathematical pitfalls of the limitation should it apply, or to provide
safeguards such as safety conditionals around the code to force errors should
the code be unworkable.
..."

I assume he is refering to me; I sent Charles some e-mail, starting out
by saying that I use assembler occasionally, (my perverse occupation demands
it), but his test with one compare little trick could be done in C.
I provided an example and he claimed it was wrong.  I had a very hard time
getting his reasoning out of him, but finally it amounted to "your algorithm
won't work in certain cases", however, the certain cases were the exact
same cases that his algorithm wouldn't work in assembly.
He was seemed quite positive that I hadn't been aware of the restriction,
yet anyone who would have sent my solution would surely be aware of it's
limitation; it depends on knowing about how twos complement arithmetic works
and the differences between signed, unsigned and how overflow works.
I suggested that using his logic, an equivalent challenge would be:
"You can't add two single precision integers in a HLL, like you can in
assembly".  When challenged he could just as easily state, "Well, what about
overflow?  Assembly programmers know about overflow, HLL programmers don't".

Note Charles' many confusions about what compilers are, what they do and
how they work (a simple example is in the paragraph above; compilers
don't produce algorithms).  In my correspondence, I repeatedly implored
Charles to look at gcc, since the source is freely available and gcc produces
better assembly than I do (and I quite firmly suspect better than Charles
does).  Our correspondence discussed things like defered pops and omitting
frame pointers, two simple optimizations that compilers can do easily,
but are a real bitch for humans to do.  Discussing compilers with Charles
is like talking to someone about why computers are so cool, having the
person repeatedly disagree, and finally seeing the person get apoplectic
and blurt out: "Oh yeah!  If computers are so darned smart, how come they
can't add columns of numbers faster and more accurately than I can by hand?"
The problem is that he is quite sincere in his misconceptions, it is
impossible to argue with such unmitigated ignorance.

My original mail to Charles was to point him in the direction of C and gcc,
so he could see for himself, and perhaps be delighted in the grace of a
modern compiler.  I tend not to criticize people on the net, since that only
makes them defensive, but since Charles insists on saying patently ridiculous
things, even after being shown counter-examples, I figured it would be worth
calling him on this one.

If Charles would like, I can post all of our letters back and forth (there
are about half a dozen of them, I believe).  You can judge for yourself.

BTW, Charles is quite right about there being things you can do in assembler
that you can't do in a high level language, but he is quite wrong about the
fixed range check with one compare.

I would guess that most people reading this are not going to change their
mind about the merits of high level languages, but just in case you think
that there's no way that a compiler could do ___ where ___ is a really cool
optimization, go look at the source to gcc.  It can't do everything, but it
can do a hell of alot more than I could do by hand.  Look at the optimizations
that it performs on the rtl, and the backend templates.  It's pretty
darned cool what it does, and how it works.

A good programmer with a modicum of game theory should be able to write a
program that can beat the programmer at checkers or chess.  A good compiler
writer should be able to write a compiler that can produce better assembly
than the compiler writer.  Stallman wrote gcc; Stallman's an *excellent*
programmer.  Note, this was not always the case, "PDP-8"s just did not have
the memory to put in all of the code that a modern compiler needs.  "PDP-11"s
too would require overlays, since 64k instruction + 64k data just doesn't cut
it.  Take a look at gcc.  It does a lot of work.

BTW, I too cut my teeth on "PDP-8"s, "PDP-11"s and "PDP-10"s.  My preferred
"language" was Fortran + assembler before I learned C, over ten years ago.
My masters emphasis was compiler construction and my current work is
rewriting the Macintosh ROMs from scratch, in C, using no dissassembly of
any of Apple's ROMs or System file.  My company, ARDI, has a product out
that emulates a Macintosh using the code that I wrote.  If you have a NeXT,
check out our product, Executor(tm) (see the Winter of issue of NeXTWORLD, due
out in early October).

I truly believe that Charles knows a lot about machines of the past, but his
idea of where assembly is appropriate is founded on ignorance and is hopelessly
outdated; his scorn for modern programming techniques as taught in academia
is wholely misplaced.  In short, w.r.t. compilers, Charles is a crank.  You
know, someone who has special insight as to why conventional wisdom is wrong.
Of course if he were correct, he could make a fortune leveraging his superior
knowledge into a company to topple Microsoft; after all, their software
runs p-code (i.e. is interpretted at run time).  Gosh golly, what schmucks.

	--Cliff
Newsgroups: alt.folklore.computers