Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!rochester!ken
From: ken@rochester.arpa (Ken Yap)
Newsgroups: comp.misc
Subject: Re: Assembly Language
Message-ID: <1211@sol.ARPA>
Date: Sun, 9-Aug-87 01:34:42 EDT
Article-I.D.: sol.1211
Posted: Sun Aug  9 01:34:42 1987
Date-Received: Sun, 9-Aug-87 13:24:40 EDT
References: <892@edge.UUCP>
Reply-To: ken@rochester.UUCP (Ken Yap)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 62
Summary: try to get the best tool for the job

|Folks, just because it looks *different* doesn't mean it's hard.  ANY
|language looks hard to someone who doesn't know the language.  To an
|assembly language programmer, C looks hard.  It's all in what you're
|familiar with.

Speaking from real experience with half a dozen assembler languages,
and not just micros, I found, as you say, that it wasn't any harder
than higher level languages once you get used to the notation. But that
catch is, you don't get as much accomplished for the same amount of
effort as you would with a HLL.

|Assembly is just another language.  Like other languages, it has strong
|points and it has weak points.  Its strong points are efficiency, both in
|speed and in memory space, unlimited flexibility, and ease of debugging (yes,
|EASE of debugging).  Its weakest point is non-portability.  It's also a bit
|weak where a lot of subroutine calls have to be made using HLL interface
|specs -- unless you have a good assembler program with nice macro facilities
|you'll have to do a lot of messing around.

You forgot another weak point - data structures. To set up a
structure/record in this PDP/11 macro assembler I used, I had to
generate the offsets with this non-intuitive syntax of equating symbols
with the relative addresses of fields. I don't want to do this kind of
niggly bookkeeping, that is what compilers are for.

|Assembly language programming isn't "impossibly hard", and it *is* still
|widely used in the non-Unix world.  Regardless of what college professors
|and Unix fans would have you believe.  There are a lot of applications out
|there where portability is of no interest, but performance is critical.  For
|those applications, assembly is clearly the language of choice.

Very often you can get the performance you want with a mixed language
approach - HLL for the non-critical portions, assembler for that
critical 5%.  But first I would check if there isn't a better
*algorithm* before fiddling with assembler code.

To the person who said that some applications like video games have to
fit into 256Kb of memory or whatever or it won't sell, I agree and
understand the constraints. The first Mac ROM was like that.  I'm just
glad I don't have to do that kind of shoehorning.

You're right, assembler sometimes gets bad press. It will be around as
long as Von Neumann architectures are with us, maybe even longer. Just
like every EE should know how to use a soldering iron, every computer
scientist should "dirty one's hands" at least once with assembler, if
only to get a better insight about how machines work at that level.

Assembler is just another option in a good programmer's bag of tools.
In an ideal world, one should choose and get the best tool for the
job.  In real world other reasons often decide the tools: "we have all
this code in FORTRAN already", "Pascal is nice but we can't afford to
buy a compiler", "yes, we would prefer C but none of the compilers are
reliable", "the DoD says we have to use Ada for this one".

Also don't forget there are even higher level languages like APL or
Icon.  I'm having fun writing this set partitioning program in Icon
right now.  No malloc'ing, no string length counting, no need to write
my own data abstraction routines. Compiles very quickly, executes
slower than C of course but it is fast enough. I may never bother to
recode the program in C after I get it working.

	Ken