Оптимизация кода Keil Опции

[aanbor]

Добрый день всем.
Давно хотел получать оптимизированный код, все руки не доходили. Сейчас начинаю проект с нуля, самое время начать осваивать. Первым делом начал с эзернета, запустил без оптимизации, пинги проходят. Затем ставлю уровень 3, смотрю что получилось.
Вот кусок из ETH_STM32F2xx:

Код

  id1 = read_PHY (PHY_REG_IDR1);
  id2 = read_PHY (PHY_REG_IDR2);

Обе переменные объявлены локально внутри функции и вроде должны вести себя одинаково. Но если шагать отладчиком, видно, что id1=0x22, а вот id2=not in scope. Почему не отображается id2? Да и много чего не могу посмотреть отладчиком, но видимо все работает правильно, раз плата пингуется. Как тогда отлаживать при включенной оптимизации?

[scifi]

Как тогда отлаживать при включенной оптимизации?

Никак. Отлаживать нужно на самом низком уровне оптимизации. Когда всё работает, повышаем уровень оптимизации до максимального и надеемся, что ничто не сломается. Соответственно, изначально код пишем так, чтобы при повышении уровня оптимизации не вылазили баги (это чаще всего относится к своевременному применению volatile, а также избегаем зависимость от скорости исполнения). Также надеемся, что нет багов в компиляторе.
Если ну очень хочется поотлаживать оптимизированный код, то делаем это через дизассемблер, что может быть очень трудоёмко для нетривиального кода.
Как-то так.

[aanbor]

В принципе я так себе и представлял: отладил-вышел-включил оптимизацию-пересобрал проект-запустил-вышел-отключил оптимизацию-пересобрал проект и так много-много итераций. Тогда возникает вопрос: если памяти хватает, особо высокая скорость не требуется, а так ли нужна эта самая оптимизация?

[scifi]

Тогда возникает вопрос: если памяти хватает, особо высокая скорость не требуется, а так ли нужна эта самая оптимизация?

В этой ситуации (хватает и памяти, и скорости) оптимизация не даёт ничего.
Однако, если вы рассчитываете использовать написанный код в других проектах, в которых может быть включен высокий уровень оптимизации, тестирование кода с включенной оптимизацией может помочь заранее отловить баги, зависящие от уровня оптимизации. То есть по сути дополнительное тестирование как инвестиция в будущее повторное использование кода.

[aanbor]

Спасибо, scifi, за полезную информацию.

[jcxz]

Полностью согласен с scifi. Могу только добавить, что включение полной оптимизации полезно в выявлении скрытых багов, которые могут проявиться при её включении. Если её не включать, то баг останется, но не будет проявляться до некоторого момента, пока так сложатся звёзды на небе и переменные в map-файле, что и без оптимизации перестанет работать, но тогда уже будет непонятно где искать баг.
При полной оптимизации обычно более полно используются регистры, да и вообще - код более перетасовывается, что часто помогает скрытым багам вылазить наружу.
Всё сказанное конечно не относится к случаю если оптимизатор криво реализован в компиляторе. В таком случае оптимизацию вообще нельзя включать.