Re: Help on TI C64x+

Homer Griffin wrote:
Thank you for the reply. Here is the function.
The array combined is correct for the first iteration, but wrong
afterwards.
But if I print it out, it is correct. The last line of code gives a
wrong result
as well.
demoded[i] = _bitr(maxid)>>26;

I do use a struct type. Maybe that's the problem?


typedef struct
{
int corrOut;
short position;
int chan;
} finger_t;

short demod(short *restrict in, short *restrict qu, unsigned char
*restrict demoded,
unsigned char * restrict eraslocs, finger_t *restrict
finger)
{
int i, j;
int hii, loi, hiq, loq, tmp, tmp1, tmp2;
short combined[64];
int f1, f2, f3;
int maxid;


f1 = finger[0].position;
f2 = finger[1].position;
f3 = finger[2].position;
for(i =0; i<63; i++)
{
for(j= 0; j<128; j+=4)
{
tmp1 = 0;
tmp2 = 0;
hii = _hi(_memd8_const(&in[f1+j]));
loi = _lo(_memd8_const(&in[f1+j]));
hiq = _hi(_memd8_const(&qu[f1+j]));
loq = _lo(_memd8_const(&qu[f1+j]));
tmp = _pack2(hiq, hii);
tmp1 += _dotp2(tmp, finger[0].chan);
tmp = _pack2(loq, loi);
tmp2 += _dotp2(tmp, finger[0].chan);

hii = _hi(_memd8_const(&in[f2+j]));
loi = _lo(_memd8_const(&in[f2+j]));
hiq = _hi(_memd8_const(&qu[f2+j]));
loq = _lo(_memd8_const(&qu[f2+j]));
tmp = _pack2(hiq, hii);
tmp1 += _dotp2(tmp, finger[1].chan);
tmp = _pack2(loq, loi);
tmp2 += _dotp2(tmp, finger[1].chan);

hii = _hi(_memd8_const(&in[f3+j]));
loi = _lo(_memd8_const(&in[f3+j]));
hiq = _hi(_memd8_const(&qu[f3+j]));
loq = _lo(_memd8_const(&qu[f3+j]));
tmp = _pack2(hiq, hii);
tmp1 += _dotp2(tmp, finger[2].chan);
tmp = _pack2(loq, loi);
tmp2 += _dotp2(tmp,finger[2].chan);

_mem4(&combined[j/2]) = _pack2((tmp1>>3), (tmp2>>3));

}
f1 += 128;
f2 += 128;
f3 += 128;


fht(combined);

maxid = DSP_maxidx(combined, NN+1);

demoded[i] = _bitr(maxid)>>26;

}
return 0;

}



On Mar 20, 7:46 pm, Nils <n.pipenbri...@xxxxxxxxx> wrote:
Homer Griffin schrieb:

Why are the possible reasons for different results with different
compiling opt levels?
If I don't use optimization, the result is correct. However, when I
use -o3, the
result is really weird. What's more weird is that the result is
correct again when I add
a line of printf in my code.
Hi.

This happends if you calculate something but the result is never used.
In this case the compiler will remove the dead code. Your printf
statement makes use of the result and as such the code gets compiled.

A common cause of this problem is violation of the c language aliasing
rules.

The function below may or may not work as expected because the compiler
is free to optimize the code away. All it sees is that the ptr is
written to a local variable but never used anymore. The reference to the
variable via the union does not count as an access because the types in
the union are different. This is just one example of breaking the
aliasing rules, and not the best example either because this use-case is
so common that compilers often don't include unions into their
aliasing-optimization passes.

Please try to isolate the problem to a small piece of code and post it
here.

typedef union
{
int i;
void * ptr;

} testunion;

int DoStuff (int * ptr)
{
testunion temp;
temp.ptr = ptr+100; // calculate something
return temp.i; // return different typed field.

}

> My code contains three instrinsics
> _memd8_const, _dotp2, and _pack2

That should not be a problem. The intrinsics will work.

Nils


The 64x+ compiler uses a software pipelining technique to for best optimization. However, if there is a function call within the loop (printf) then it will disqualify the loop from using this software pipelining technique. You should ensure proper data alignment by using #pragma DATA_ALIGN(myvar, 8) if you need something double word aligned. If you're using an intrinsic that depends on double-word alignment and your data is not actually double-word aligned then your code will fail. Also, make sure you have the latest codegen tools so you're not getting bitten by any known bugs. I believe the current 64x+ compiler is version 6.0.18.

Brad
.

Relevant Pages

  • Re: Help on TI C64x+
    ... int corrOut; ... short demod(short *restrict in, short *restrict qu, unsigned char ... tmp = _pack2; ... In this case the compiler will remove the dead code. ...
    (comp.dsp)
  • Re: C99 Restrict
    ... "restrict" is there to help optimising compilers. ... int f ... But a compiler must be right 100% of the ... an lvalue is based on a "restrict" object if its ...
    (comp.lang.c)
  • Re: restrict example - reasonable?
    ... int test ... I wanted to be able to compile some code with various optimisations ... and then to introduce 'restrict' to show it get fixed. ... However (although I am not, and never have been compiler writer), I ...
    (comp.lang.c)
  • Re: Using C99 "restrict" with newly allocated and initialized arrays/structures
    ... return (int) x; ... The use of "restrict" here is intended to inform the compiler that x ... I think this is OK despite the wording you have quoted. ...
    (comp.lang.c)
  • Re: restrict example - reasonable?
    ... I'd be very interested to know what compiler you're using - and its ... int test ... and then to introduce 'restrict' to show it get ... parameters as restrict and show that this allows certain optimizations ...
    (comp.lang.c)