Path: utzoo!utgpu!water!watmath!clyde!ima!necntc!linus!munck From: munck@linus.UUCP (Robert Munck) Newsgroups: comp.arch Subject: Re: using (ugh! yetch!) assembler Message-ID: <37014@linus.UUCP> Date: 25 Jul 88 20:51:08 GMT References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp> <474@m3.mfci.UUCP> <2926@utastro.UUCP> Reply-To: munck@faron.UUCP (Robert Munck) Organization: The MITRE Corporation, Bedford MA Lines: 43 In article <2926@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >I know of no programmer who thinks assembly language is better for all >kinds of programs, nor do I know a good one who feels it is *never* >better for *any* job. Until I can buy a compiler -- for any language -- >than can generate code that runs as fast as I can write by hand, I will >use assembly language where speed is essential. You will, indeed, have >a hard time proving to me that I'm wrong in using the tool that best >fits the requirements of the job. Given real world system sizes, budgets, deadlines, and MAINTENANCE constraints as your "requirements," assembly language will "fit" only the smallest, most toy-like, never-to-be-used-for-real prototypes. If I've got two years and five people to write a system that takes 100,000 lines of Ada or 500,000 lines of assembly code to express (an extremely conservative expansion factor), I have to write it in Ada; the assembly version would never be finished. Note that an Ada program that works is by definition faster than an assembly language program that doesn't. (Done as a military procurment, the Ada version would take 100 people ten years to do; the assembly version would be quietly cancelled in the fifteenth year of development). Of course, we can't "prove" anything in this field; "de gustibus non est dispundandum" only tells us that Gus is still in the West. However, my twenty years of writing code, many anecdotes, and one substantial, well- run experiment tell me this: Given equal amounts of "brain-power" put into the effort, a group of HOL programmers will build a SMALLER, FASTER system than a group of assembly language programmers. Reason: the HOL team can put more thought into efficient data structures and algorithms, while the assembly language group burns up their brains doing register assignment, optimizing five-instruction loops, and generally doing things that compilers are BETTER THAN HUMANS at doing. Don't even think about debugging, maintenance, and enhancement over a long life-cycle. Sure, sometimes the timing requirements are so tight that the HOL version doesn't make it. In that case, instrument the heck out of the HOL, find out which ten statements it's spending 30% of the time executing, and re-write those in assembler. Keep doing this until you meet the timing specs. Almost certainly, you'll have re-written less than 5% of the code. Next year, when you move to a faster CPU, throw away the assembly. -- Bob Munck, MITRE