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