Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!deimos!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!wsmith
From: wsmith@m.cs.uiuc.edu
Newsgroups: comp.lang.misc
Subject: Re: Assembly or ....
Message-ID: <5200035@m.cs.uiuc.edu>
Date: 29 Nov 88 04:26:00 GMT
References: <1388@aucs.UUCP>
Lines: 46
Nf-ID: #R:aucs.UUCP:1388:m.cs.uiuc.edu:5200035:000:2026
Nf-From: m.cs.uiuc.edu!wsmith    Nov 28 22:26:00 1988


>In article <1388@aucs.UUCP>, 861087p@aucs.UUCP (A N D R E A S) writes:
>> ... if it really worth it to spend time to learn assembly language.
>
> (1) most high level languages are so badly documented that you cannot tell
>     PRECISELY what they will do without examining the assembly language
>     version of the code.

This similar to the problem of proving a program's correctness via test
cases.  You cannot know "PRECISELY" what a compiler will do unless you have 
the source to it.  

> (2) how else can you diagnose compiler bugs? (unless you have a complete
>     denotational semantics description of the language)

How often do you find these? If it is that often, I would consider buying
a new compiler.

> (3) on those few occasions when you need the utmost in performance, you must
>     examine the assembly language listing from the compiler to see how to
>     write the tightest loops, etc.  It is virtually unknown to see a compiler
>     document that describes exactly the transformations of the "optimizer".

Probably because often the most concise specification of the transformation
is the source to the compiler.
> 
> Thus, in the present state of affairs, a high-level language programmer
>MUST know some assembly language to be effective.
 ^^^^

I cite as evidence to the contrary a 20k line project developed on several
different Unix systems in which I never looked at the assembly code produced
by the compiler (even in a debugger).

I took it as a sign of increasing maturity as a programmer to trust the tools
provided enough so that I could with 99.9% reliability blame myself for the
misbehavior of a program without spending hours on a fruitless search for
the evanescent compiler bug.   And, if a bug is discovered, I think it is more
productive to try to find the simplest input case that still has anomalous
behavior than to reverse engineer the output of the compiler.
>-- 
>Bill Hutchison, DP Consultant	rutgers!liberty!burdvax!ubbpc!wgh

Bill Smith
wsmith@cs.uiuc.edu
uiucdcs!wsmith