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