Open Areas for Compilers Research

I've been talking with some VLSI folks and I was surprised to find out how
many compilers problems they are trying to solve on their own.


For example, they have tools to build application-specific processors with
the number of functional units tailored to the inner loop of the
application. At an architectural level the processors look like
microcoded or VLIW machines, but each one is different. Thus, to program
them in high-level languages, they're using retargetable code generators.
They would like to improve the ease of specification and the quality of
the produced code.


Another example: many of the processors are used in real-time
applications. They can afford to generate the core code by hand, but the
bulk of the code isn't on the critical path and so in practice the
compilers already generate code that's fast enough -- they just want a
better way of reporting the runtime than examining the code by hand. For
example, the compiler could say ``this loop is executed X times and the
longest path through the loop is 53 instructions.''


These problems ae interesting in part because there is a crying demand for
them and because it's been a while since the compilers community has
looked at these problems, so there might be some relatively quick things
that would be very useful right away. If you're interested in finding out
more, you might go talk to your local VLSI gurus, or write to me and I'll
try to hook you up with some folks who are doing this.


;-D on ( Re: search ) Pardo
--

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