Re: Assemblers

franka@mntgfx.MENTOR.COM (Frank A. Adrian)
Wed, 23 Dec 87 11:59:54 pst

          From comp.compilers

Related articles
Assemblers culdev1!drw@eddie.mit.edu (1987-12-17)
Re: Assemblers franka@mntgfx.MENTOR.COM (1987-12-23)
Assemblers culdev1!drw@eddie.mit.edu (1987-12-23)
Re: Assemblers harvard!rutgers!hao!scicom!qetzal!upba!ugn!mcmi!de (1987-12-24)
Re: Assemblers ucbvax.Berkeley.EDU!unisoft!gethen!farren (1987-12-26)
| List of all articles for this month |

Date: Wed, 23 Dec 87 11:59:54 pst
From: franka@mntgfx.MENTOR.COM (Frank A. Adrian)
Newsgroups: comp.compilers
In-Reply-To: <816@ima.ISC.COM>
Organization: Mentor Graphics, Beaverton, OR

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.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.