|GPU-aware compiling? email@example.com (Tomasz Chmielewski) (2005-05-20)|
|Re: GPU-aware compiling? firstname.lastname@example.org (Michael Tiomkin) (2005-05-22)|
|Re: GPU-aware compiling? email@example.com (Oleg V.Boguslavsky) (2005-05-22)|
|Re: GPU-aware compiling? firstname.lastname@example.org (email@example.com) (2005-05-24)|
|Re: GPU-aware compiling? firstname.lastname@example.org (Rob Dimond) (2005-05-24)|
|Re: GPU-aware compiling? email@example.com (2005-05-24)|
|Re: GPU-aware compiling? firstname.lastname@example.org (Ray Dillinger) (2005-06-26)|
|Re: GPU-aware compiling? email@example.com (Julian Stecklina) (2005-07-02)|
|From:||firstname.lastname@example.org (Hannah Schroeter)|
|Date:||24 May 2005 10:18:12 -0400|
|Organization:||Schlund + Partner AG|
|Posted-Date:||24 May 2005 10:18:12 EDT|
Oleg V.Boguslavsky <email@example.com> wrote:
>From the compiler's point of view you'll spend much time to make an
>effective compiler. Look at the DSPs market - do you know many C
>compilers which generate instructions for DSP's MAC-unit? which
>generate MAC instead of MUL + ADD? i find 0 compilers, which do it
>(even for such a DSPs like Motorola 56K, TI etc.). Besides - can smb.
>point me to the compilers which do it?
No actual compiler, but it was the simplest part of my diploma thesis
on some aspects of Code Generation for DSPs to do exactly that.
At least it is a simple task if you use code generator generators
which can match subtree (or sub-DAG) patterns which are more complex
For people who can read German, the thesis is available on the pages
of the university department where I did it:
Return to the
Search the comp.compilers archives again.