|Reference Works wanted: compiler techniques for parallel hardware? email@example.com (Ray Dillinger) (2005-07-02)|
|Re: Reference Works wanted: compiler techniques for parallel hardware? firstname.lastname@example.org (George Neuner) (2005-07-05)|
|Re: Reference Works wanted: compiler techniques for parallel hardware? email@example.com (dz) (2005-07-11)|
|From:||George Neuner <firstname.lastname@example.org>|
|Date:||5 Jul 2005 19:35:09 -0400|
On 2 Jul 2005 20:21:52 -0400, Ray Dillinger <email@example.com> 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
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
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.
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.
Return to the
Search the comp.compilers archives again.