inline assembly?

[Chris Torek]

(Or, Here We Go Again)

In article <703 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
>Suppose that you have a situation in a program where the implementation of
>your compiler has done something bad, like use 10 instructions and 6 memory
>references where 2 instructions and no memory references can do the job.
>The overhead of a subroutine call is likely to be more than what can be
>saved; a goto construction may not work if part of the problem is that the
>compiler will mess up register use (very common).

Then you do something very implementation dependent and fix the problem
however you have to fix it, and your program runs 10 times faster.  And
when you move it to a different machine your implementation-dependent
code no longer works, but that is all right because you were careful
about how you wrote it, and you fall back on the portable version that
in this case happens to generate nearly optimal code so that the only
thing you could do by fiddling with it is make it run 1.0001 times
faster.

So whatever *is* the problem?  When you need to do something that is
not portable, because it is worth it, you do something nonportable.  By
definition, it is not portable, so why should you care in what way it
is not portable?  There is always *some* way; if necessary, you can
compile, link, disassemble, edit, assemble, and relink---all
automatically.  The existence of some way need only exist; it need
not be portable, because by definition it cannot be portable.

(The portable fix for the problem, of course, is to tweak the compiler
so that it generates nearly-optimal code.  This also has a much bigger
potential payoff.  Inline assembly is merely a band-aid.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris