evgeniy1294 (06.11.2019 20:58, просмотров: 724) ответил VLLV на IAR ваш - Говно. Ни малейшего предупреждения.-
- Три строки выше проверка диапазона сдвига. - VLLV(06.11.2019 21:31)
- _status_bit[i] ВСЕГДА < 64, поэтому выхода за диапазон не будет. Этот код компилятор может выкинуть. - Costic(06.11.2019 21:18)
- Ещё вопрос: flash отмаплена в 0x00000000? - evgeniy1294(06.11.2019 21:00)
- похоже на то - 0men(06.11.2019 21:03)
- именно )) оптимизатор все это выкинул нах ) - 0men(06.11.2019 20:59)
- и правильно сделал :-) - Costic(06.11.2019 21:20)
- Когда-то, давным давно, было модно в AVR нулевой байт EEPROM не занимать. Для того, чтобы IAR не выкидывал переменную, которая никому не нужна, нужно было просто ему это указать: vpv.vpv(126 знак., 08.11.2019 09:12)
- В стандарте на язык Цэ нулевой указатель не может указывать ни на одну переменную в программе. Оказалось, что в яре для стм8 таки может. Или это был 8051 и кейл? В общем, бывают курьёзы. - SciFi(08.11.2019 18:09)
- дык вроде дело связано с тем что запись в еепром на avr идет через регистр-указатель в котором какой-то адрес всегда есть и в случае не преднамеренной установки битов в EECR запись случится) в связи с этим и рекомендации не использовать нулевой Aleksey_75(34 знак., 08.11.2019 18:29)
- У PIC микрочиповских, с EEPROM, то же самое было, даже вроде в документе каком-то проскакивало: паркуйте указатель записи в нулевую ячейку и не используйте её. - Nikolay_Po(08.11.2019 18:42)
- дык вроде дело связано с тем что запись в еепром на avr идет через регистр-указатель в котором какой-то адрес всегда есть и в случае не преднамеренной установки битов в EECR запись случится) в связи с этим и рекомендации не использовать нулевой Aleksey_75(34 знак., 08.11.2019 18:29)
- это было во времена AT90, у мег и тинь таких проблем, вроде, уже не было - 0men(08.11.2019 13:42)
- ХЗ, я теперь не тока на АВР "0" ячейку не трогаю. ;О) - mse homjak(08.11.2019 15:22)
- В стандарте на язык Цэ нулевой указатель не может указывать ни на одну переменную в программе. Оказалось, что в яре для стм8 таки может. Или это был 8051 и кейл? В общем, бывают курьёзы. - SciFi(08.11.2019 18:09)
- Когда-то, давным давно, было модно в AVR нулевой байт EEPROM не занимать. Для того, чтобы IAR не выкидывал переменную, которая никому не нужна, нужно было просто ему это указать: vpv.vpv(126 знак., 08.11.2019 09:12)
- В этом случае отладчику положено сообщать "нет такой переменной, ибо она ушла нах". - SciFi(06.11.2019 21:03)
- скомпилировал у себя, отладчик пишет unknown статусбит. Возможно, после игры с линкером, что то пошло не так - 0men(06.11.2019 21:09)
- Как бы ни игрались, имя есть имя. - VLLV(06.11.2019 21:32)
- Без маппинга тоже имя остается? Я так понимаю, вы знаете, что этот кусок кода оптимизатор выкинул правильно? - 0men(06.11.2019 21:37)
- Нет, в этом не разобрался. Собственно, с этого началось. - VLLV(06.11.2019 21:42)
- _status_bit[i] ВСЕГДА < 64, поэтому весь цикл не имеет смысла, компилятор (оптимизатор) его выкидывает - 0men(06.11.2019 21:45)
- Проверил, именно так. То есть против изврата программиста IAR бессилен. Ну что ж, логично. Еще раз спасибо! - VLLV(06.11.2019 21:59)
- Бля! Спасибо! Сравнение действительно не в ту сторону. Щаз проверю в симуляторе. - VLLV(06.11.2019 21:56)
- Я же как раз писал об этом))) - evgeniy1294(06.11.2019 23:43)
- Спасибо, но я читал зашоренными глазами )) Сначала хотел брейк применить, а потом "упростил" конструкцию, не поменяв условие. - VLLV(07.11.2019 06:39)
- Говорят, "test-driven development" в этих случаях помогает. Сделал рефакторинг, прогнал тесты, чувствуешь себя сухо и комфортно. Хотел попробовать, но с этими тестами столько геморроя (особенно симулировать железо), что забил. Плетём лапти по SciFi(10 знак., 07.11.2019 12:17)
- В реальной жизни не могу заниматься тестированием, да и программировать некогда :), просто нужно вычистить код. Разобравшись, какая функциональность наносит непоправимый ущерб системности, отстоять её снос. Тестирование могу отдать, а это - ну VLLV(7 знак., 07.11.2019 13:51)
- Железо нужно симулировать не на уровне битов и фронтов сигналов, а на уровне высокоуровневых операций (например, чтение-запись блоков данных в EEPROM делается через функцию HAL)... fk0(3835 знак., 07.11.2019 12:59)
- Значит, наш IAR не Говно? :) - Ксения(07.11.2019 11:02)
- Не, тут тема сисек раскрыта не до конца... один глюк так и не объяснен. При выкидывании оптимизатором кода (и переменной), отладчик должен написать, что она не известна. Тут же он ее показывает по вполне определенному адресу. Дело может быть в 0men(56 знак., 07.11.2019 12:12)
- Да, так бывает. Пожалуй, у каждого было, у меня в том числе: "Я нашёл баг компилятора"! Спокойно отношусь, с пониманием. - Nikolay_Po(07.11.2019 11:11)
- мой найденный косяк )) - 0men(07.11.2019 12:22, ссылка)
- Какой-то унылый косяк. У меня было неверное вычисление MD5 при включении оптимизации (и, возможно, иные, более скрытые баги). Найти, где именно, не представляется возможным, т.к. код MD5 - та ещё простыня, а при оптимизации на дизассемблер без SciFi(19 знак., 07.11.2019 12:31)
- Да конечно. Я писал свой MD5 для пиков, одним глазом подглядывая в официальный исходник. Получилось и компактней и быстрей (на 8 битах). И отлаживается эта "простыня" очень просто, можно после каждой итерации каждой одной из 4-х частей алгоритма fk0(54 знак., 07.11.2019 13:04)
- +1, отлаживался так же - 0men(07.11.2019 13:16)
- А потом окажется, что эти дампы (там же надо volatile добавить) спугнули баг. Или не окажется... - SciFi(07.11.2019 13:06)
- Зачем, что даст volatile? Ты дамп явно печатаешь, компилятор явно это видит, что ты его читаешь и сгенерирует код какой нужно. Ты ж его не параллельно отладчиком из регистров/памяти выдирать будешь? Про отладчик конечно компилятор не знает. fk0(436 знак., 07.11.2019 13:15 - 13:18)
- Да конечно. Я писал свой MD5 для пиков, одним глазом подглядывая в официальный исходник. Получилось и компактней и быстрей (на 8 битах). И отлаживается эта "простыня" очень просто, можно после каждой итерации каждой одной из 4-х частей алгоритма fk0(54 знак., 07.11.2019 13:04)
- Какой-то унылый косяк. У меня было неверное вычисление MD5 при включении оптимизации (и, возможно, иные, более скрытые баги). Найти, где именно, не представляется возможным, т.к. код MD5 - та ещё простыня, а при оптимизации на дизассемблер без SciFi(19 знак., 07.11.2019 12:31)
- мой найденный косяк )) - 0men(07.11.2019 12:22, ссылка)
- Да говно, говно, не переживайте! ;О) - mse homjak(07.11.2019 11:07)
- Говорят, "test-driven development" в этих случаях помогает. Сделал рефакторинг, прогнал тесты, чувствуешь себя сухо и комфортно. Хотел попробовать, но с этими тестами столько геморроя (особенно симулировать железо), что забил. Плетём лапти по SciFi(10 знак., 07.11.2019 12:17)
- Спасибо, но я читал зашоренными глазами )) Сначала хотел брейк применить, а потом "упростил" конструкцию, не поменяв условие. - VLLV(07.11.2019 06:39)
- Я же как раз писал об этом))) - evgeniy1294(06.11.2019 23:43)
- _status_bit[i] ВСЕГДА < 64, поэтому весь цикл не имеет смысла, компилятор (оптимизатор) его выкидывает - 0men(06.11.2019 21:45)
- Нет, в этом не разобрался. Собственно, с этого началось. - VLLV(06.11.2019 21:42)
- Без маппинга тоже имя остается? Я так понимаю, вы знаете, что этот кусок кода оптимизатор выкинул правильно? - 0men(06.11.2019 21:37)
- Как бы ни игрались, имя есть имя. - VLLV(06.11.2019 21:32)
- скомпилировал у себя, отладчик пишет unknown статусбит. Возможно, после игры с линкером, что то пошло не так - 0men(06.11.2019 21:09)
- и правильно сделал :-) - Costic(06.11.2019 21:20)