using (ugh! yetch!) assembler

[Richard A. O'Keefe]

In article <856 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
>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.

I am sympathetic to Rubin's position, but I can't quite tell which side
he is arguing on here.  Let's replace his example by a still humbler one:
integer multiplication.  I have to include the operation of integer
multiplication in assembly code generated by a "smart" macro processor.
MUL doesn't quite take the non-portability prize; I think DIV does that.
But even MUL is a subroutine call on some machines (not always obeying
the protocol used elsewhere), an instruction on some, a sequence of 20-40
instructions on others.  It is a relief to turn to C (pathetic though a
language which doesn't report overflows may be) and not have to worry
about that[*].  The situation with floating-point is worse.  Once you start
porting generated assembly code between machines with 32/16/11/8 general
registers and varying numbers and arrangements of floating-point registers,
it pretty soon occurs to you that it doesn't matter whether the compiler
will "allow asm instructions to use the compiler's knowledge of which
registers are assigned to which variables" or not, it's not going to port
_nohow_.

If you want to mingle small chunks of assembly code with C code, I'm
convinced that asm("..") is obsolete: /usr/lib/inline is so much better
(e.g. you can switch from C implementations of such functions to inline
assembly code without changing your source, and better still, change _back_).
A trap for asm("...") users: some C compilers switch off optimisation in a
function if you use asm(), even if all you did was plant a label or comment.

[*] I have seriously considered writing C routines to do integer *, /, %,
and calling them from the generated assembly code.  What was that about using
assembly code to get access to machine instructions?