Re: Folk Theorem: Assemblers are superior to Compilers

Dave Gillespie <synaptx!thymus!daveg@uunet.UU.NET>
Fri, 29 Oct 1993 22:02:44 GMT

          From comp.compilers

Related articles
[14 earlier articles]
Re: Folk Theorem: Assemblers are superior to Compilers toon@moene.indiv.nluug.nl (1993-10-28)
Re: Folk Theorem: Assemblers are superior to Compilers raymondc@microsoft.com (1993-10-28)
Re: Folk Theorem: Assemblers are superior to Compilers adk@sun13.SCRI.FSU.EDU (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers elliottm@csulb.edu (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers jvn@fermi.clas.virginia.edu (Julian V. Noble) (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers Freek.Wiedijk@phil.ruu.nl (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers synaptx!thymus!daveg@uunet.UU.NET (Dave Gillespie) (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers rfg@netcom.com (1993-10-30)
Re: Folk Theorem: Assemblers are superior to Compilers qualtrak@netcom.com (1993-10-30)
Re: Folk Theorem: Assemblers are superior to Compilers johnson@cs.uiuc.edu (1993-10-31)
Re: Folk Theorem: Assemblers are superior to Compilers henry@zoo.toronto.edu (1993-10-31)
Re: Folk Theorem: Assemblers are superior to Compilers drraymon@watdragon.uwaterloo.ca (1993-11-01)
Re: Folk Theorem: Assemblers are superior to Compilers dmr@alice.att.com (1993-11-02)
[7 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: Dave Gillespie <synaptx!thymus!daveg@uunet.UU.NET>
Keywords: C, optimize, assembler
Organization: Compilers Central
References: 93-10-138
Date: Fri, 29 Oct 1993 22:02:44 GMT

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
--


Post a followup to this message

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