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