Re: The development tendency of compilation tech?

Mayan Moudgill <mmoudgill@sandbridgetech.com>
17 Mar 2007 14:44:02 -0400

          From comp.compilers

Related articles
[9 earlier articles]
Re: The development tendency of compilation tech? stevem@ans.com.au (Steve Murray) (2007-01-31)
Re: The development tendency of compilation tech? tom@infoether.com (Tom Copeland) (2007-01-31)
Re: The development tendency of compilation tech? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-01-31)
Re: The development tendency of compilation tech? bmoses-nospam@cits1.stanford.edu (Brooks Moses) (2007-02-16)
Re: The development tendency of compilation tech? codeplay@gmail.com (2007-02-25)
Re: The development tendency of compilation tech? idbaxter@semdesigns.com (Ira Baxter) (2007-03-01)
Re: The development tendency of compilation tech? mmoudgill@sandbridgetech.com (Mayan Moudgill) (2007-03-17)
| List of all articles for this month |

From: Mayan Moudgill <mmoudgill@sandbridgetech.com>
Newsgroups: comp.compilers
Date: 17 Mar 2007 14:44:02 -0400
Organization: Posted via Supernews, http://www.supernews.com
References: 07-01-043
Keywords: history, design
Posted-Date: 17 Mar 2007 14:44:02 EDT

Yunzhi Xue wrote:


> I'm working on a survey of the development tendency of compilation
> technology. But there are too many issues and I am such a Green
> Hand. So could anybody please tell my about the possible major trend
> of compilation tech?
>
> Best wishes
> Yunzhi
> [So what's new in compilers this year? -John]


FWIW: changes in compilers arise when new language concepts are
introduced, or when application domains change, or when the target
changes, or when the compilation environment changes. (And, of course,
when the benchmarks change.)


In the last category (environment), I put changes such as:


- profile directed feedback
- JIT
- additional resources (memory/execution speed).


Unfortunately, while each of these had great impact on the practice of
compilers, they didn't have much impact on the theory. For instance,
greater resources enabled the wide-spread application of
resource-hungry optimization techniques that, in the past, could be
applied to only small snippets of code and/or in the largest
supercomputers.


Target changes arise when a new ISA is introduced, or an old one is
extended, and the ISA/extension is radically different. There is
little such change in the mainstream; the latest changes (ARM+Cortex,
PowerPC+Altivec, x86+SSE2) have all been simple SIMD extensions, with
nothing very challenging.


Out of the mainstream, it is not clear that the demand exists to
support a compiler effort that extends compiler technology. Consider
extensible architectures such as Tensilica or ARC: the different
extensions might be generally exploitable by a compiler. However, the
extensions are concieved of as accelerators for a single kernel, and
it makes more economic sense to rewrite that one kernel in assembler.


Three target changes which people have mentioned as possible drivers
of innovation are GPUs, FPGAs, and multi-core. These are all
interesting areas of research, with wide deployment of the
target. However, note that there is a fairly large amount of
compilation technology that is applicable to these targets. Obviously,
any innovations on multi-core have to be built on the prior history of
multi-processor compilation research. FPGA compilation can be viewed
as an instance of behavioral synthesis. I don't know enough about
current GPUs to comment.


Language feature changes can cause disruptions in compiler technology,
as it seeks to exploit the information provided by the change (e.g.
restrict/type-aliasing in C) or to overcome a performance inhibitor
(e.g. virtual function calls in C++/Java etc.). A recent example of
research in this area is the streaming language stuff from
MIT/Stanford.


New languages are, in some cases, driven by focus on a new application
domain. Streaming, for instance, arises from multi-media/signal
processing applications. Of course, the new application domain must
have concepts that are not conveniently expressible in an existing
language, or in a minor extension to the existing
language. (Occaisionally, high-level languages are created to expose
the internals of the hardware - the graphics processing languages are
an instance of that.)


Of course, the fact that there is an opportunity for a compiler to do
something, does not mean that it is possible to implement that. For
instance, it may require a large amount of infrastructure that may not
be economically viable to implement.


Its very hard to come up with anything that drives real innovation in
the compiler area - our company, for instance, is building a compiler
that compiles from C to a multi-threaded/multi-core processor focused
on digital signal-processing algorithms. We're developed a
sophisticated compilation infrastructure. Despite all that, the number
of true innovations we've developed can be counted on the fingers of
one hand.


Post a followup to this message

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