Oli Filth wrote:

> robert bristow-johnson said the following on 02/09/2006 15:46:
>> 
>> Hans S�rensen wrote:
>> 
>>> Right now it's implemented like this (but it's slooooooooow):
>> 
>> that's because "%" is often as slow as "/".
>> 
>>>    CyclicCounter=CyclicCounter%256;
> ...
>> in general, for C, the faster way is to mask:
>> 
>>     CyclicCounter=CyclicCounter&0xFF;
> 
> Wouldn't a decent compiler perform this sort of optimisation
> automatically?  (Just as it might optimise x/2 to x>>1, etc.).
> 

On Blackfin, VisualDSP would (or should) automagically set-up and use a
circular buffer when '%' is used. Or at least if the 'CyclicCounter' would
be the counter in for-loop instead of 'i' (I don't know how naive the
compiler is).

In addition there is pragmas or instrics in VisualDSP++ which can be used to
tell the compiler to generate a circular buffer for the given for-loop.

-- 
Jani Huhtanen

Mark Borgerding wrote:
> Andor wrote:
>>> Wouldn't a decent compiler perform this sort of optimisation
>>> automatically?  (Just as it might optimise x/2 to x>>1, etc.).
> 
> If x is signed, they are not the same.
> 
> Divison rounds towards zero, bitshift rounds down.

The rounding of division is implementation dependent. When using integer 
calculation of coordinates, including best approximation of straight 
lines and circles, rounding toward negative infinity avoids extra 
discontinuity around zero.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Andor wrote:
>> Wouldn't a decent compiler perform this sort of optimisation
>> automatically?  (Just as it might optimise x/2 to x>>1, etc.).

If x is signed, they are not the same.

Divison rounds towards zero, bitshift rounds down.

-- Mark Borgerding

Hans S=F8rensen schrieb:

> Have a look here for FIR filtering examples on the ADSP-2136x:
>
> http://www.analog.com/processors/sharc/technicalLibrary/codeExamples/2136=
x_simd_code.html
>
> ---------
>
>
> Thanks. I had a look at it. I'm not sure I can use that since I am not
> trying to implement a FIR filter?

These FIR filters are implemented with circular buffers ...

Hans S=F8rensen wrote:
> Have a look here for FIR filtering examples on the ADSP-2136x:
>
> http://www.analog.com/processors/sharc/technicalLibrary/codeExamples/2136=
x_simd_code.html
>
> ---------
>
>
> Thanks. I had a look at it. I'm not sure I can use that since I am not
> trying to implement a FIR filter?

i'm not quite as sanguine about how good VisualDSP++ is (how good the
compiled code comes out to be).

i know what the syntax was in the "old" SHArC C compiler for assigning
register varibles in C to specific registers in asm (i didn't think it
worked so good).  anyway what is the syntax to do that now?  can you
assign one register float* to B1 and another to I1 (set both to the
buffer base) and then assign a register long to L1 (set it to the
buffer length)? or a similar set of address registers?  then you can
just plop stuff on the buffer using autoincrement on the I1 register
(in the C code) and not worry about it not wrapping.  same thing for
offsets on that register (it should wrap automagically).

r b-j

On 2006-09-02, Oli Filth <catch@olifilth.co.uk> wrote:
>>>    CyclicCounter=CyclicCounter%256;
> ...
>> in general, for C, the faster way is to mask:
>> 
>>     CyclicCounter=CyclicCounter&0xFF;
>
> Wouldn't a decent compiler perform this sort of optimisation 
> automatically?  (Just as it might optimise x/2 to x>>1, etc.).

As the old saying goes, the implementation may cheat, but it must not
get caught.  If CyclicCounter is unsigned, then those are identical.
If it's signed, the compiler has to add extra code to handle negative
values.  It's not nearly as costly as an actual divide, but if you
are counting instructions in an inner loop it might matter.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

dilpreet06 wrote:
> Lol @ the star trek joke.
> 
> Just a thought : i know it wouldnt be a constructive suggestion, but
> wouldnt it be faster to program in assembler?? There is a software
> VisualDSP++ which has a very reliable compiler. I programmed a circular
> buffer to run an echo signal in the 21065 Sharc once, and it worked very
> well. Hmmmm.

Why not constructive? I'm always irked by a need to psych a compiler 
into producing exactly the assembly code I I know I want in the first 
place. As long as I can call the assembly routine from HLL -- sometimes 
even if it means saving and restoring a lot of registers -- it's likely 
to be the most straightforward (hence bug-free) way.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

There is a software
> VisualDSP++ which has a very reliable compiler. I programmed a circular
> buffer to run an echo signal in the 21065 Sharc once, and it worked very
> well. Hmmmm.


I'm using VisualDSP++.

However, I am not an experienced assembly-programmer.

I read somewhere that I can use macros for setting up circular buffers, but
I can't find this litterature....

Have a look here for FIR filtering examples on the ADSP-2136x:

http://www.analog.com/processors/sharc/technicalLibrary/codeExamples/2136x_simd_code.html

---------


Thanks. I had a look at it. I'm not sure I can use that since I am not 
trying to implement a FIR filter?

Lol @ the star trek joke.

Just a thought : i know it wouldnt be a constructive suggestion, but
wouldnt it be faster to program in assembler?? There is a software
VisualDSP++ which has a very reliable compiler. I programmed a circular
buffer to run an echo signal in the 21065 Sharc once, and it worked very
well. Hmmmm.