Здравствуйте.
Осваивая Blackfin (532) и VisualDSP, столкнулся со странной проблемой. При отключенной оптимизации кода программа работает именно так, как ожидается. При включенной оптимизации (100% Speed) наблюдается частичная неработоспособность. Программа написана на С.
В результате анализа работы при помощи симулятора выяснилось, что неправильно работает подпрограмма обработки прерываний, в которой имеется несколько вложенных вызовов подпрограмм. В одну из них параметр передается в регистре R0. Из нее выполняется вызов другой п/п, которая к этому параметру никакого отношения не имеет. Она искажает R0, а затем искаженное значение используется в вызывающей программе.
На первый взгляд кажется, что неправильно работает оптимизатор: не учитывает использование регистров во вложенных подпрограммах. Но, возможно, я чего-то недочитал и есть способ вразумить оптимизатор?
Не знает ли кто способ решения описанной проблемы? Отключать оптимизацию не хочется, во многих местах от нее существенная польза.

Фиговый у них оптимизатор. Я им 2 бага на простых примерах год назад посылал. С третьего раза убедил что это оптимизатор а не мой код. Код предельно простой - вложенное умножение матриц. До сих пор не исправили.

Оптимизация зависит от той информации, которую оптимизатор считает известной. При работе с обработчиками прерываний и вообще с аппаратными ресурсами оптимизатор обычно отбрасывает код, относящийся к обработке значений в регистрах, поскольку он полагает, что всё что не модифицируется программой - никогда не модифицируется вообще. Чтобы запретить ему творить чудеса такие переменные должны использоваться с модификатором volatile. Volatile - это прямое указание компилятору не оптимизировать переменную. Даже если Вы считаете, что компилятор неправильно интерпретирует переменную и volatile не нужно, не нужно бороться с компилятором, этот модификатор всегда помогает преодолеть эти ошибки оптимизатора.

Ещё один источник ошибок - ассемблерные вставки, особенно находящиеся в инлайн функциях. Хотя по соглашению о передаче параметров на входе в процедуру находятся в регистрах данных (R0, R1, ...) но полагаться на это нельзя, а нужно использовать точные спецификации с формальными параметрами asm - %0, %1, .... Иначе включение оптимизации сразу делает код неработоспособным.
Режим автоматическтого inline при оптимизации тоже может творить чудеса. Я до конца так и не понял, что именно строго говоря он инлайнит автоматически. Процедуры с циклами типа FIR он инлайнит точно, в других случаях когда есть вложения инлайновых функций или много логических операторов он этого не делает, по своим соображениям, даже если явно указано inline

Кстати мне показалось, что оптимизатор в VDSP4 ведёт себя значительно более агрессивно чем в VDSP3.5, впрочем без особого эффекта на быстродействие, но иногда работающие в 3.5 с включенным оптимизатором программы работают в 4.0 только без оптимизатора

Спасибо за развернутый ответ, но, как оказалось, я просто пользовался старой версией VDSP4.0. После установки декабрьского обновления описанная проблема исчезла.