Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!husc6!panda!genrad!decvax!mcnc!unc!rentsch From: rentsch@unc.UUCP (Tim Rentsch) Newsgroups: comp.lang.misc Subject: Re: assembly programming prefereable to HLL programming ? Message-ID: <384@unc.unc.UUCP> Date: Wed, 10-Dec-86 01:37:23 EST Article-I.D.: unc.384 Posted: Wed Dec 10 01:37:23 1986 Date-Received: Sun, 14-Dec-86 20:48:44 EST References: <646@instable.UUCP> <476@atari.UUcp> Reply-To: rentsch@unc.UUCP (Tim Rentsch) Organization: CS Dept, U. of N. Carolina, Chapel Hill Lines: 109 From previous articles.... > > 1. The ONLY siginificant advantage of HLL is a shorter CODING time. > > 2. Design, documentation, testing time is (almost) the same in both cases. > > 3. The assembly program will run 2-5 times faster. > > 4. So, after enough runs of the program the coding time gap will be > > swallowed. From then on, the assembly program gains non-stop. > > Generally, assembly-language programs will run faster (and will > be smaller) than compiler-generated code. Depending on your > machine's architecture, though, you may never want to program in > its assembly language (e.g. IBM 801 and other RISCs). Friendlier > machines like the 68000 are another story. > > 1. No one cares how much you suffered. The *only* thing that > a user sees is the product's performance . . . or lack therof. > The user doesn't care what you wrote it in. Once the product > gets to market it stands on its own merit. > > 2. It probably *is* more expensive to write a system in assembly > than in an HLL. Is it worth the effort? What's the return? > > 3. Given a piece of source code to compile, some present day > compilers may well be able to out-perform a human (not for > compilation speed, but for execution speed and space). I can't believe I am reading this debate in 1986! Where were you guys during the 1970's and 80's? Didn't you ever hear of structured programming? Sheesh! Software engineering has taught us a few things which should by now be common knowledge. (I presumed everyone knew them. I see I was in error.) For example: 1. A given programmer writes the same number of lines of code per day, independent of language. 2. HLL code is about 5 times as functional, on a per-line basis, as assembly language. 3. The variability between programmers is much greater, on the order of 25 to 1. 4. "Most" of the time in a program is spent in a "small" amount of the program. Sometimes these numbers are reported as 80% and 20%; sometimes 90% and 10%. 5. It is very difficult to know ahead of time where the 10% will be. The lesson to be learned is to code your entire program in HLL, then after it is running go back and recode the "important" parts in assembly language. To know what the important parts are, use a performance monitor (e.g., statement level execution statistics). It is true (in my experience, anyway) that human-generated assembly language tends to be smaller than compiler-generated code. But not by a lot. Programs running on contemporary machines (where a mere eight chips is already one megabyte) tend to need space for DATA rather than for CODE. The space-time tradeoff between various data representations is better expressed in HLL, unless it is at a time-critical point in the program. But remember, you don't know when you write the program where those bottlenecks will be, so you are still better off doing the initial version in a HLL, and then recoding the important parts in assembly. > But this is not what happens when a human writes in assembly > language. Many perfectly acceptable structures in assembly > are illegal or difficult to express in an HLL. The whole > flavor of the project changes . . . not just the code generator. Question: do those structures even need to be expressed in the HLL? The answer is, No, they do not. Once the program is working and the bottlenecks re-written in assembly (10% of the total program, remember?), the structures can be changed so that only the assembly language primitive routines can access them, and the HLL structures can be filled in with appropriate "dummy records". The global program structure remains intact, with only local changes to representation of key data types and access methods. > Humans are perfectly capable of using those "wierd, high level" > instructions that compiler writers claim are useless. (Show me > a 68000 C compiler that uses MOVEP, TAS or SNE!) Those instructions are useless to compiler writers, and useful to human assembly language programmers. That still doesn't mean the entire program should be written in assembly; the assembly language part should still be the 10% that is necessary for the program to run fast. > Lotus-123 is non-portable, written mostly in assembly, and has made > its writers a *bundle* of money. I don't suppose they're complaining > about how hard it was to write. That doesn't prove a thing. Yes, it *can* be done. So what? It is possible to simulate weather on a Turing machine, too -- and I'm sure that if there was someone willing to pay it, someone else would do it. But it still would be easier to write in another (HL) language. So, cmon, guys, get with it. Join the present. The assembly language debate was settled in the last decade. Let's also end it here. "Can you say 'BALR?' Horrors!" cheers, txr