Неисповедимы пути оптимизатора…

Пишу код и чем больше кода написал тем меньше (sic!) обьем О_о. Вначале было 1280 байт, теперь уже 960 О_О Фак мой мозг! Может я смогу написать программу отрицательной длины?

А вообще Сишный оптимизатор меня раздражает. Вот не с того ни с сего возник плавающий глюк. Без оптимизиации все идеально. С оптимизацией начинается чехарда. ПРичем добавление куска мертвого кода (любого!!! и в любую часть программы) исправляет проблему. Самое непонятное в том, что, судя по JTAG проц ловит срыв стека. Причем именно на выходе из прерывания. Ладно бы на индексных переходах, я бы это понял, там я мог накосячить. А тут? За сохранение контекста отвечает комплиятор, тогда откуда кривой адрес возврата?

Хотя ОЗУ юзается на 5-10% не больше. Вот что за фигня? Как ЭТО ловить если оно то появляется то исчезает? Отладка в JTAG по исходному коду практически бесполезна, т.к. то что осталось после оптимизации к исходному коду имеет очень малое отношение %). В общем, продолжаю развлекаться.

Блин, а еще говорят что асм сложный язык. Ха! Зато однозначный и все косяки и подводные камни лежат на поверхности.

Это я портирую один свой ассемблерный проект на Си. Примечательно, что на асме на создание той проги у меня ушел день, а на отладку не более 20-30 минут.

Тут же я написал весь код за часа полтора, а в отладчике ковыряюсь уже второй день. Мне не достаточно избавиться от глюка — это просто, достаточно чуть изменить «форму» кода. Я хочу понять ОТКУДА он берется. Т.к. оставлять такую шнягу зарытой в своем огроде это зло.

Запись опубликована в рубрике Дневник с метками , , . Добавьте в закладки постоянную ссылку.

Добавить комментарий