Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!lanl!beta!jlg
From: jlg@beta.lanl.gov (Jim Giles)
Newsgroups: comp.arch
Subject: Re: using (ugh!  yetch!) assembler
Message-ID: <20894@beta.lanl.gov>
Date: 27 Jul 88 20:08:40 GMT
References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp> <474@m3.mfci.UUCP> <2442@pt.cs.cmu.edu>
Organization: Los Alamos National Laboratory
Lines: 30

In article <2442@pt.cs.cmu.edu>, lindsay@k.gp.cs.cmu.edu (Donald Lindsay) writes:
> I've seen some big wins from recoding into assembler. I've seen bigger
> wins from switching compilers, and even bigger wins from rethinking
> the algorithm. The biggest wins come from rethinking the problem.
> Yes, I can give examples.

I've never seen switching compilers do better than recoding in assembly.
I guess it could happen if you have a bad programmer do your assembly code.
The fact is, a good starting point for an assembly version of ANY code
is the output of some good compiler.  Using this technique, you can always
do AT LEAST as good as the best compiler you have.

There are only two good reasons for using assembler.  If you have either
of these, you probably should consider assembler.

    1)  Your 'high-level' language doesn't have some feature that the
	hardware does.  This includes test-and-set instructions for
	semaphores, vector mask instructions, etc..  If you need to
	use these features to get your job done, there is not alternative
	to assembly code.

    2)  Your code is VERY time or space critical.  If you've go only
	so many clocks, of only so much memory for the code, assembly
	may be your only chance.

Other than this, stick to your high-level languages.  Portability may
no be important to you now, but later you MAY discover that you want
to move the code.

J. Giles