Path: utzoo!utgpu!attcan!uunet!convex!killer!ames!hc!lanl!beta!jlg
From: jlg@beta.lanl.gov (Jim Giles)
Newsgroups: comp.arch
Subject: Re: using (ugh!  yetch!) assembler
Message-ID: <20921@beta.lanl.gov>
Date: 29 Jul 88 16:23:23 GMT
References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp> <474@m3.mfci.UUCP> <11674@steinmetz.ge.com>
Organization: Los Alamos National Laboratory
Lines: 30

In article <11674@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes:
>   How about a large program? A good C compiler will find common
> subexpressions, partial results, etc. Even a good assembly programmer
> won't rescan the whole program after every change to see if any common
> subexpressions can be eliminated.

You didn't listen.  I recommended keeping the high-level code and
making mods and improvements there.  Only AFTER you have a working
'final' version, and it's still too slow/big, do you convert to
assembly.  Converting to assembly is done by taking the compiler
OUTPUT (which is machine code) and disassembling.  Now you can apply
modifications to this code to make it faster/smaller.  Clearly you can
never do worse than your best compiler did.

Also, most C compilers do a miserable job at common subexpression
analysis, strength reduction, etc..  A critical part of your code
should be rewritten in several different languages - then you keep
the one that produces the best code.  Of course, this assumes that
you can mix languages on the host machine.  But, if you can't do
that, you probably don't have ANY good compilers (or other tools)
on that machine anyway (so you're stuck with assembly for all
critical code).

If the performance and size of a code is important, many languages
should be tried - including assembler.  If only portability is
important, by all means stick to one portable language.  Of course,
this still doesn't address the issue of machine features that the
'high-level' language doesn't support.

J. Giles