using (ugh! yetch!) assembler

Herman Rubin cik at l.cc.purdue.edu
Wed Aug 3 21:35:55 AEST 1988


In article <11699 at steinmetz.ge.com>, davidsen at steinmetz.ge.com (William E. Davidsen Jr) writes:
> In article <37406 at linus.UUCP> munck at 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 at l.cc.purdue.edu (Internet, bitnet, UUCP)



More information about the Comp.lang.c mailing list