Re: Reference Works wanted: compiler techniques for parallel hardware?

George Neuner <gneuner2@comcast.net>
5 Jul 2005 19:35:09 -0400

          From comp.compilers

Related articles
Reference Works wanted: compiler techniques for parallel hardware? bear@sonic.net (Ray Dillinger) (2005-07-02)
Re: Reference Works wanted: compiler techniques for parallel hardware? gneuner2@comcast.net (George Neuner) (2005-07-05)
Re: Reference Works wanted: compiler techniques for parallel hardware? drizzle76@gmail.com (dz) (2005-07-11)
| List of all articles for this month |
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: 5 Jul 2005 19:35:09 -0400
Organization: Compilers Central
References: 05-07-007
Keywords: parallel, architecture
Posted-Date: 05 Jul 2005 19:35:09 EDT

On 2 Jul 2005 20:21:52 -0400, Ray Dillinger <bear@sonic.net> wrote:


>Are there any well-developed strategies for developing languages that
>take advantage of parallel hardware?
>
>When people want to take advantage of DSP's or Graphics coprocessors
>that do a lot of parallel and/or dataflow stuff, it seems like they
>almost always wind up going down to the bare wires and coding in
>assembler. IOW, the compiler writers so far have been failing these
>people. And it's hard to imagine language constructs that allow such
>things to be used in a general and efficient way.
>
>So, I'm looking for reference works; have any books been written about
>the design of languages to support parallel and dataflow operations on
>massively concurrent hardware like DSP's, or about how compilers for
>them are implemented? It seems like code generation would become a
>nonlinear problem.


Hi Ray,


I have no experience with GPUs, but most DSP instruction sets are
variations of VLIW and strategies for compiling to that model will
take you in the right direction.


The problem with HLLs on DSPs is that most languages use a single
threaded computation model. Fully utilizing the DSP requires the
programming language have (or mesh well with) a model of overlapped
operations - that's why most people resort to assembler.


Compiler controlled threading would be a viable way to attack the
overlap problem, but I'm not aware of any DSP compiler that
automagically threads overlapped operations - the normal practice is
to use an interrupt or poll for completion. And, of course, apart
from Ada, Occam, and a few others, most HLLs have no way to specify
parallel operations.


If looking at some code would help, you can get the source for Analog
Devices's G21K compiler [210xx family]. G21K was open sourced several
years ago when they switched to an ACK based compiler for their
VisualDSP product line. The source for the compiler is available on
their ftp site.


ftp://ftp.analog.com/pub/dsp/210xx/dev_tools/3.3/


I never used G21K myself so I can't speak to the quality of it's code
generation. However, I got the impression that Analog retired GCC as
a platform because their 21x6x (Sharc) line of chips were becoming
very complicated and GCC was proving too difficult to work with.


George


Post a followup to this message

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