drw@eddie.mit.edu (Dale Worley) (12/18/87)
Doug Pardee writes: | There is a modern aphorism that "It's much harder to program in assembler | than in a high-level language". That's no surprise, considering that the | typical programmer has neither training nor experience in assembler coding. | We further hobble him by providing stone ax assembler tools, and then we | have the gall to complain that the resulting program looks like it was | butchered with a stone ax. It may well be that Un*x assembler tools are pitiful. But the general observation that "assembler is hard to program in" was learned on systems (like OS/360) where the assembler-coding tradition was strong, and the programmers had the requisite tools and skills. In many cases, the system support for assembler was *much* better -- most HLLs don't have a macro facility at all, and only fairly recently has the concept of source-level debugging become popular. (On OS/360, the *only* run time debugging facilities required that you know the machine language and even the assembler coding *conventions* intimately.) The reason is that it generally takes more lines of assembler to do a given job. And, not surprisingly, the number of lines of code is a primary determinant of the amount of effort needed to write and maintain an application. Assembler is also prone to errors of the "oops, R7 doesn't have what I thought it had" type. (Remember C back when "all the world's an int"?) It has always taken more time, money, and skill to produce a working application in assembler than in an appropriate HLL, even on systems that support assembler well. As time has progressed, the fraction of applications which must be written in assembler for efficiency reasons has gone down. The quality of compiler-generated code has gone up. The availability of languages (like C) that let you do the sort of sneaky back-door things assembler used to be needed for has increased. Porting has become more important. The price of hardware vs. labor has plummeted. Assembler is still important, and its supporting tools should be as rich as those for an HLL, but the area in which it can be economically uses is gradually shrinking. The moderator says: | Indeed, I know people who | use the 370 assembler as a macro processor, getting their results directly on | the listing or in the object "deck," never generating an executable program, The batch control file for an entire OS/360 system generation was the preprocessor output of a bunch of macros! Dale -- Dale Worley Cullinet Software ARPA: culdev1!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
johnl@ima.UUCP (12/20/87)
Dale Worley writes: >Assembler is still important, and its supporting tools should be as >rich as those for an HLL, but the area in which it can be economically >uses is gradually shrinking. Shrinking, indeed, but still most of the market. The following programs all have two things in common: a) Lotus 1-2-3 b) Microsoft Basic c) MS-DOS d) dBase II e) Turbo Pascal Those two things are: 1) They are the most widely used programs in the world, and 2) They're all written in assembler And a third thing is: 3) They wouldn't have become #1 if not for #2 Some of these products are migrating to HLLs, and some products could be on the list because they became popular while in assembler, and then migrated. The list is shrinking, but we should still remember that today, in terms of customer demand, most software is written in assembler. So it is surprising that assembler tools aren't better, and it's also interesting that for all the advances in compiler technology, assembler programs still dominate. --- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473 [I note that all of these programs run on micros; how much important mainframe software is still in assembler? I gather that PARS/ACP, the airline system, still is because of its extraordinary performance requirements, e.g. handling 1000 transactions/second, but is anything else? -John] -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
drw@eddie.mit.edu (Dale Worley) (12/23/87)
Somebody writes: | The list is shrinking, but we should still remember that today, in terms | of customer demand, most software is written in assembler. So it is | surprising that assembler tools aren't better, and it's also interesting | that for all the advances in compiler technology, assembler programs still | dominate. Quite true. But one can also say: In terms of man-hours spent, most software is written in Cobol. (Three-quarters (!) of all professional programmers write in Cobol.) The difference between these two statements isn't surprising... Programs which are written once and used zillions of times are written in assembler because the cost/benefit tradeoff favors it. Programs which are not distributed so much have different tradeoffs. -- Dale Worley Cullinet Software ARPA: culdev1!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
franka@mntgfx.MENTOR.COM (Frank A. Adrian) (12/24/87)
In article <816@ima.ISC.COM> you write: >Dale Worley writes: >>Assembler is still important, and its supporting tools should be as >>rich as those for an HLL, but the area in which it can be economically >>uses is gradually shrinking. > >Shrinking, indeed, but still most of the market. The following programs >all have two things in common: < list of products that I wish I had royalties to :-) > >Those two things are: > 1) They are the most widely used programs in the world, and > 2) They're all written in assembler >And a third thing is: > 3) They wouldn't have become #1 if not for #2 I agree with number 3, but probably for an extremely different reason than the original poster. Most people, when they focus on the differences between HLL's and assemblers, focus mainly on two issues: 1) Speed and size of code 2) Programmer productivity As we all know, assembly code is usually faster and smaller than an equivalent program written in an HLL (The usual caveats apply. We all have horror stories about incompetent programmers, I am sure). In general, the programmer productivity (measured in lines of code per diem) is about constant, so the language with the more functionality per line of code provides more functionality in a shorter amount of time, right??? Well, maybe not. In my experience, people who design code expecting to use assembler design much different products from those who design expecting to use HLL's. Being that it is harder to program in assembler, people who do so tend to avoid "creeping featuritis". In addition, they tend to use simple, statically sized data structures. As well, they tend to use simple (but sufficiently fast, given the bounded data size) algorithms. The end product is often more robust than an overengineered and overfeatured program done in the same amount of time because one has used an HLL. Does this always happen? No. But in most cases, the time saved in HLL's is not spent in more design or testing. It's usually spent in getting one more whizzy for marketing in (and probably incorrectly at that). In any case, because changing assembler is so hard, more time usually goes in up front in designs targeted in assembler in the first place, and the product provided is in the form of a small set of orthogonal utilities which are pieced together to form a powerful environment. Sound familiar? Too bad it doesn't happen all that often in more products. Frank Adrian Mentor Graphics, Inc. P.S. I will not, however, say that I would be willing to go back to the days of all assembly coding. Besides myself being lazy when doing the "grunt work" of coding, there are some products which deserve all the bad design they get. -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
johnl@ima.UUCP (12/25/87)
>[I note that all of these programs run on micros; how much important mainframe >software is still in assembler? I gather that PARS/ACP, the airline system, >still is because of its extraordinary performance requirements, e.g. handling >1000 transactions/second, but is anything else? -John] I know of a rather large IBM shop which still does most of their work in assembler. Lots of custom work with large databases. Constant rewriting. What do they do you ask? You know that stuff that shows up in your mailbox and leaves you wondering where they got your name? What's more perfect than junk mail programs written in assembler? They are not on the net of course. --- Denny Page -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
johnl@ima.UUCP (12/26/87)
In article <816@ima.ISC.COM> watmath!looking!brad (Brad Templeton) writes: >The list is shrinking, but we should still remember that today, in terms >of customer demand, most software is written in assembler. Considering software technology solely as a function of total units sold of particular programs is highly misleading. All of the examples you have given of best-selling software written in assembler were designed to run on 8-bit machines, specifically the Z-80/8080 and the 8088 of the IBM PC. For these machines, efficient HLLs either are not, or were not (Lotus, MS-DOS), available. If and when compilers of sufficient efficiency become available, as they are beginning to for the IBM PC, I would expect the use of assembler- only coding to drop significantly. I doubt, for example, that the same analysis, if made in five years, would show the same results. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.arpa | Tom Reingold, from alt.flame -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request