Re: Folk Theorem: Assemblers are superior to Compilers

Tony Kennedy <uunet!sun13.SCRI.FSU.EDU!adk> writes:


> float max(float x, float y) {
> union fl {float f; long l;} z;
> z.f = x - y;
> z.l &= ~z.l >> 31;
> return z.f + y;}


Well, when I said "branches are awful" I meant it on the scale of a few
instructions. Coding your method on an 860-like CPU is likely to lose
because of the number of extra operations you do to avoid the branch.
(Again, it's only in a *really* critical, tight loop where this attention
to detail makes sense.)


If you have an absolute-value instruction, you can also use "max(x,y) =
0.5 * (x + y + abs(y-x))". Anyway, identities like this can easily be
programmed by rote into a compiler. My point with my i860 example was
that our trick was extremely effective for the larger idiom "max(x, min(x,
y), -y) with y>0", which is complicated enough to be hard for a compiler
to recognize, and hard for a compiler writer to notice when designing a
set of rote optimizations.


The real answer is to have a cleverer choice of FP instructions. I
believe the Alpha has a conditional move instruction, for example. I've
seen one or two CPU's that had actual "max" and "min" instructions.


CISC can refer to "complex instruction sets" or "sets of complex
instructions." People tend to think in terms of the former as the
downfall of CISC, but actually it's the latter that brings on the
microcoding and the slow cycle times. The 860 is a step in the direction
of RISC processors that still have large, rich instruction sets. I'd like
to see more movement in this direction---why not have conditional move,
*and* min and max, *and* absolute value, and so on. Many of the things
you want are FP instructions, which even tend not to be starved for bits
in the opcode. And compilers would have no trouble using these
instructions, too.


Anyway, this is starting to sound more like comp.arch than comp.compilers.


-- Dave
--

Return to the comp.compilers page.
Search the comp.compilers archives again.