Path: utzoo!utgpu!watmath!clyde!att!ihlpb!nevin1
From: nevin1@ihlpb.ATT.COM (Liber)
Newsgroups: comp.lang.misc
Subject: Re: Assembly or ....
Message-ID: <9147@ihlpb.ATT.COM>
Date: 6 Dec 88 00:02:54 GMT
References: <1388@aucs.UUCP> <407@ubbpc.UUCP>
Reply-To: nevin1@ihlpb.UUCP (55528-Liber,N.J.)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 48

In article <407@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes:

> (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 is NOT the way to go about learning an HLL.  As you point out
later, compilers may have bugs, and you may also be depending on features
which are in the implementation but are not in the language.  For
example (no double-entendre intended :-)), consider the following C
fragment:

	for (stuff in here not relevant to example)
	{
		int temporary;
		...
	}

Is the value of temporary preserved between iterations of the for
loop?  If you look at the output of most (but not all) compilers, you
would answer this question Yes.  If you look at the language
definition, however, you would conclude that the answer is No.

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

If you don't have a complete description of the language,
how are you going to be able to tell the difference between a bug and a
feature in the first place?  When the results of running a program are
not the same as the results predicted by the documentation, I diagnose
that there is a compiler bug.  Although knowing assembler helps in
determining exactly what went wrong, it is not strictly necessary for
finding compiler bugs.

> (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".

I agree with you on this point.  This does lead to another problem,
though:  hand-optimizing the HLL code to get the compiler to output the
best assembler code.  In this case you might as well be programming in
assembler, since maintaining the assembler code would be easier than
maintaining the HLL code.  It is overkill to use an HLL as a super-
macro-assembler; HLLs are better used when you can abstract and can
follow the paradigm of the language.
-- 
NEVIN ":-)" LIBER  AT&T Bell Laboratories  nevin1@ihlpb.ATT.COM  (312) 979-4751