caxapa.ru :: Как бы ни игрались, имя есть имя.

Ответы

- Без маппинга тоже имя остается? Я так понимаю, вы знаете, что этот кусок кода оптимизатор выкинул правильно? - 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)
        
        Неважно. Это было давно, скорее всего реальный баг яра, но исправлять его никто не стал бы (кому нужен яр для coldfire?). И это был неплохой повод перейти на gcc. SciFi(188 знаков, 07.11.2019 13:17)
        
        Ваш гцц кривая паделка финских студентов, он даже работает в страшном чорном досе, там нет никакого GUI. MicroC или CCS - выбор профессионала! fk0(48 знаков, 07.11.2019 13:21)
        
        Да говно, говно, не переживайте! ;О) - mse homjak(07.11.2019 11:07)

Средства и методы разработки