Re: DSP C Compiler Question???

megauthi@watcgl.waterloo.edu (Marc E. Gauthier)
Sun, 6 Oct 1991 21:28:21 GMT

          From comp.compilers

Related articles
DSP C Compiler Question??? singhvk@eecg.toronto.edu (Vijaya Singh (Vij)) (1991-10-01)
Re: DSP C Compiler Question??? pete@oakhill.sps.mot.com (1991-10-02)
Re: DSP C Compiler Question??? mcdowell@exlog.com (1991-10-03)
Re: DSP C Compiler Question??? megauthi@watcgl.waterloo.edu (1991-10-06)
| List of all articles for this month |

Newsgroups: comp.dsp,comp.compilers
From: megauthi@watcgl.waterloo.edu (Marc E. Gauthier)
Keywords: DSP, C
Organization: University of Waterloo
References: 91-10-007 91-10-011
Date: Sun, 6 Oct 1991 21:28:21 GMT

In article 91-10-011 pete@oakhill.sps.mot.com (Pete Percosan) writes:
>> I don't (yet!) have access to any of these compilers, I'm curious
>> as to how "poor" the results are. That is, can these compilers take
>> advantage of or effectively utilize:
>[...]
>> - dual data memory banks
> If, by dual memory, you mean dual DATA memory (the X and Y data space
>of the DSP56000/1), the current Motorola compiler will not take full advantage.
>The primary reason for this is due to the run-time overhead that would be
>required to dynamically test pointers (i.e. does a pointer point to X or Y
>data space?).


The solution to this would be to implement pointer type modifiers, much in
the same way as Turbo C does with "near" and "far" pointers. Except in
this case, you'd probably have "X", "Y", "generic data" (X or Y),
"Program", and "generic" (X or Y or PROG) pointers. But since you're
basing your compiler on GNU GCC, I don't know how cleanly this can be
done. It would be extremely useful, however.


E.g., you could have "xdata" and "ydata" modifiers (that work a bit like
"const", "volatile" and other modifiers), and say,


static ydata int table1[256]; /* allocated in Y data space */
static xdata int table2[256]; /* allocated in X data space */
static int table3[256]; /* allocated in default (?) data space */
...
{
        ydata int *p1;
        xdata int *p2;


        for (p1=table1,p2=table,n=256; n>0; p1++,p2++,n--)
*p2 += *p2 * *p1;
        ...
}


It would probably not be acceptable that the default pointer type be the
generic pointer, which is expensive to use, so it should be possible to
tell the compiler what is the default pointer type (e.g., "xdata"), and
use a specific modifier for generic pointers (e.g., "genericdata" or
"generic"). There is perhaps still an advantage to using generic pointers
as the default type (if you use modifiers where speed is important), which
is that data items would be by default allocated in either space as the
compiler sees fit.


I think one nice thing about generic pointers on the DSP56001 is that they
wouldn't take more space than other pointers, since only 16 bits are
significant, yet everything is stored in 24 bits. (is this correct?)


><< comp.compiler guys fade out ... >>
>
>Putting on my marketing hat, I can say that our current set of compilers for
>[...]
Could you give a brief idea of the prices (assuming this is of general
interest), whether there are special prices for educational institutions
or students, and whether the prices might become lower in the future, etc.?


-Marc
--
Marc E. Gauthier megauthier@watcgl.waterloo.edu
Computer Graphics Lab, University of Waterloo [129.97.140.64] +1 519 888 4548
--


Post a followup to this message

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