Re: Intel IA-64 Architecture

mwolfe@pgroup.com (Michael Wolfe) writes:


>
> > ... Is this a compiler writers nightmare (or dream)?
>
> This is the latest amendment to the "Full Employment Act" for compiler jocks.
> How else can we stay employed?
> [Phew. I feel better now. -John]


From the public information about IA-64, I don't think the IA-64 is
that much of a compiler writer's nightmare. If anything, it seems
like the machine has a lot that would make generating code for it fun.


From my point of view, here are the interesting features:


      1) More registers than conventional RISC processors means less chance for
spilling registers, and hence more optimal code. It does mean the
various loops in the compiler iterating over registers will get slower,
but hey, machines are getting faster.


      2) Conditional execution to eliminate small if-then-else statements is a
reasonable next step to work around the bubble in pipelines that
branches cause. I added support for conditional execution to the
GNUPro tools for the Mitsubshi d10v, and it didn't take that much
time all told. It did increase the number of patterns that must be
searched in the compiler, which means the compiler is slightly slower,
and to build the compiler needs more memory to build the machine
generated portions of GCC (building and compiling the insn-* files).


The ease that conditional execution went into the GNU GCC rtl
intermediate language did drive home to me how flexible it is, compared
to say more classical triples.


      3) Bundling 3 instructions into a VLIW may mean some hair for the
debugger, as you may have up to 3 statements represented in one bundle.
Statements may be part of an if-then-else sequence converted into
conditional execution, which means the debugger will probably have to
look at the state of the flags before announcing that the breakpoint
has been reached. I don't think this is an unsolvable problem by any
means.


      4) Speculative loads will probably add some hair (and of course increase
register pressure). I see them helping things like:


if (p != (char *)0 && *p == '\0')


but won't help more than one level of pointer chasing.


I do have a couple of concerns:


      1) I hope there is a way to do int<->fp conversion without going through
memory, but this is fairly minor.


      2) I do worry that there seems to be less diversity amongst general
purpose machines (with DEC seeming to throw in the towel, etc.), which
means less of a need for compiler people :-(


--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax)
--

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