VDSP 4.0 - ADSP-21369 - optimization while maintaining execution order

Please excuse my rudimentary compiler knowledge.

I am configuring a peripheral from C and it has a DMA feature, there
are a few register loads, but I want to write to the register to start
the DMA last.

When I enable optimization using the #pragma, code is optimized such
that the DMA is started before some of the other peripheral register
loads are performed afterwords, resulting in failure.

I want optimization and I want my statements executed in order. If no
pragma or optimization switch, can I do something at the C level
besides making the enable a function?

thanks,

Dan Start a New Thread

> I want optimization and I want my statements executed in order. If no
> pragma or optimization switch, can I do something at the C level
> besides making the enable a function?

I think the CSYNC and/or SSYNC instructions for the Blackfin wil solve
that problem. Check if your target has similar instructions.

I don't think it's specifically an optimizer problem although the
optimizer probably aggravates the problem.

JJS Start a New Thread

Hello Dan,

can you provide an example of your code?
We are interested in ways that C (mis)handles peripherals as a reason to
code some device drivers in assembly (where there is less ambiguity).

Kind regards,

Alex Young
DSP software Engineer
Consultant for Philips Semiconductors Start a New Thread

I was able to figure out the problem.

I have a structure pointer to the registers in the external device.
If the compiler sees two separate |= statements to the same register,
it combined them.

struct myStructType * pStruct;

Converts:

*pStruct->regx |= CONSTA;
// other code
*pStruct->regx |= CONSTB;

To:

*pStruct->regx |= (CONSTA|CONSTB);
// other code

If I define the structure as volatile, everything is done explicitly
as in the former case.

volatile struct myStructType * pStruct;

So the compiler was behaving as it was trained. I was hoping there
was a compiler switch to tell the compiler not to combine statements.
gcc has all kinds of switches, but this compiler tries to keep it
simple, which I also appreciate.

regards,

Dan

--- In a..., Alex Young wrote:
>
> Hello Dan,
>
> can you provide an example of your code?
> We are interested in ways that C (mis)handles peripherals as a
reason to
> code some device drivers in assembly (where there is less ambiguity).
>
> Kind regards,
>
> Alex Young
> DSP software Engineer
> Consultant for Philips Semiconductors
> Start a New Thread