Xref: utzoo comp.arch:5877 comp.lang.misc:1740 comp.lang.c:11656
Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc,comp.lang.c
Subject: Re: using (ugh!  yetch!) assembler
Summary: What if C can not do the job?
Message-ID: <856@l.cc.purdue.edu>
Date: 3 Aug 88 11:35:55 GMT
References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp> <474@m3.mfci.UUCP> <11699@steinmetz.ge.com>
Organization: Purdue University Statistics Department
Lines: 50

In article <11699@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes:
> In article <37406@linus.UUCP> munck@faron.UUCP (Robert Munck) writes:

> | Mixing languages is not a terrific idea if your program is to be
> | maintained and enhanced over the years.  Languages change, too, and
> | trying to keep up with diverging languages...
  
>   A few words on that... One way to preserve portability is to get the
> whole program working in C, and identify the problem areas. Then the
> assembler output of C can be massaged by hand for efficiency. By always
> starting with compiler output you avoid having the C source and the
> assembler source out of phase to the point where the C won't work
> anymore.
> 
>   I know this is clumsy, that's why I recommend it. It will make you
> think before spending a lot of time trying to make small gains in
> performance, as opposed to rethinking the whole algorithm.

But what do you recommend if your languages (C, FORTRAN, etc.) are
incapable of doing even a remotely reasonable job with the program?
I can provide relatively simple examples of programs which can be
handled in a reasonably portable manner, but for which C does not 
have the concepts needed at all.  These are not esoteric concepts;
anyone who understands that machine words are composed of bits in
a structured manner, and that the bits of a structure can be used in
any manner compatible with the structure, can understand them.

Another problem is the fact that what one can do with a single instruction
on one machine takes many on another.  An example is to round a double 
precision number to the nearest integer.  If you think this is unimportant,
every trigonometric and exponential subroutine, or a subroutine computing
elliptic functions, etc., uses this or something similar.  On some machines,
this should be a moderately lengthy series of instructions.  On others, there
is a machine instruction which does precisely this.  Now many (all that I have
seen, but I have been told that there are ones which do not have this problem)
C compilers will not allow asm instructions to use the compiler's knowledge of
which registers are assigned to which variables.

C cannot do the job.  The present assemblers have the disadvantage that they
are atrociously difficult to read and write.  This is not necessary; COMPASS
for the CDC6x00 and its descendents were easier, but not easy enough, and CAL
on the CRAY easier still, but more can be done.  I wonder how difficult it 
would be to use an overloaded operator weakly typed assembler.  Some think that
C is this; maybe it was intended as a replacement for such an object, but it
fails badly.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)