Re: Automatic "code-pattern" recognition, in DSP codes

Bob Sheff <bsheff2@yahoo.com>
11 Jul 2005 06:57:41 -0400

          From comp.compilers

Related articles
Automatic "code-pattern" recognition, in DSP codes Miguel.CasasSanchez@ucd.ie (=?ISO-8859-15?Q?Miguel_Cas=E1s-S=E1nchez?=) (2005-07-05)
Re: Automatic "code-pattern" recognition, in DSP codes jle@ural.owlnet.rice.edu (2005-07-11)
Re: Automatic "code-pattern" recognition, in DSP codes bsheff2@yahoo.com (Bob Sheff) (2005-07-11)
Re: Automatic "code-pattern" recognition, in DSP codes codeworker@free.fr (=?iso-8859-1?q?C=E9dric_LEMAIRE?=) (2005-07-11)
Re: Automatic "code-pattern" recognition, in DSP codes darius@raincode.com (Darius Blasband) (2005-07-11)
Re: Automatic "code-pattern" recognition, in DSP codes drizzle76@gmail.com (drizzle) (2005-07-11)
Re: Automatic "code-pattern" recognition, in DSP codes oliver@first.in-berlin.de (Oliver Bandel) (2005-07-11)
Re: Automatic "code-pattern" recognition, in DSP codes pohjalai@cc.helsinki.fi (A Pietu Pohjalainen) (2005-07-11)
| List of all articles for this month |

From: Bob Sheff <bsheff2@yahoo.com>
Newsgroups: comp.compilers
Date: 11 Jul 2005 06:57:41 -0400
Organization: AT&T Worldnet
References: 05-07-024
Keywords: DSP, architecture

On 5 Jul 2005 19:35:39 -0400, Miguel Casás-Sánchez
<Miguel.CasasSanchez@ucd.ie> wrote:


>I am researching in compilers and source to source code transformations,
<snip>
>compiler reads the program and sets up the data and control graphs,
>recognise that
>
>for(i=0, acc = 0; i < N; i++) {
> acc = h[n] * X[N-n];
>}
>
>can be a FIR filter, that may be substituted as a whole by a fir()
>library function call, most optimised.
>
>Can be also understood as pattern-search in the code control/data graphs?


Hi, Yes many software translation systems (such as my X4MR system) are
specifically designed to recognize patterns such as this and translate
them to function calls or even different idioms in the target
language. The hardest part is enumerating ALL the desired patterns to
recognize and describing them in a general enough terminology:


The above example could have been functionally identical:
acc=0; for(i=0; i<N; ++i){ acc=X[N-n]*h[n];}
or even, renamed:
a=0; for(jj=0; jj<END; ++jj){ a=xxx[END-nn]*hhh[nn];}


I have crafted a translator rulebase that recognized assembly language
shift instructions used for fixed point arithmetic scaling after
multiplication/division and removed them in the resultant C
expressions, because the specification called for changing certain
variables from a "implied decimal, documented in the comments" to a
more natural "double".
This translation also removed those superfluous comments.


regards, Bob


ps: Perhaps the original n should have been a function of i.


Post a followup to this message

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