caxapa.ru :: Всё так, только "перед самой записью в регистр указать разрядность" не надо, это лишнее.

SciFi (18.09.2020 15:27, просмотров: 383) ответил teap0t на Я, собственно, именно из-за пестроты кода полез со всем этим разбираться. В тексте постоянно встречаются директивы указания разрядности. Причём мне непонятно, зачем надо заводить 16-разрядную переменную и постоянно указывать разрядность операций. Можно же взять 32-разрядную, работать с ней и только перед самой записью в регистр указать разрядность. Но я же должен убедиться, что всё правильно понимаю? Поэтому задаю вопросы. Приятно осознавать, что таки да, правильно понимаю.

Всё так, только "перед самой записью в регистр указать разрядность" не надо, это лишнее.

ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้

Ответить

- Раскройте мысль. Я, конечно, понимаю, что в 16-разрядный регистр 32 разряда не поместятся, и записаны будут только младшие биты. Собственно, для того и берётся максимальный размер переменной, чтобы приведение шло исключительно с обрезанием старших разрядов. Но для компилятора это разве не имеет значения? Может будет неправильная ассемблерная команда передачи использоваться (пример условный)? - teap0t(18.09.2020 17:00)
  - На всякий случай скажу банальность: побитные логические операции на то и побитные, что разряды друг на друга не влияют. Сложение, вычитание и умножение порождают переносы, при которых младшие биты влияют на старшие, но никогда наоборот. Только деление и сдвиг вправо приводят к влиянию старших разрядов на младшие. Поэтому, если выражение не содержит деления и сдвига вправо, вычисления с "лишней" разрядностью в соответствии с правилами integer promotion не влияют на результат. йцyкeн(150 знак., 18.09.2020 18:33)
    - Мне хочется минимизировать неоднозначность операций и снизить вмешательство компилятора до минимально необходимого. (Пока не освоился со всем этим). - teap0t(18.09.2020 18:42)
      - Язык Си очень близок к ~~железу~~ кремнию, вмешательство компилятора минимально. Если писать на ассемблере, операции всё равно будут производиться над 32-битными регистрам, операции над половинками и четвертинками отсутствуют за исключением очень специальных команд. По крайней мере в Cortex-M3; у M4 и M7 есть SIMD инструкции. - йцyкeн(18.09.2020 19:43)
        
        Ну да, вмешательство компилятора минимально. А потом он всё оптимизирует, и погромист недоумевает "где мой код"? :-) - SciFi(18.09.2020 20:00)
        
        Язык Си - возможно, самый низкоуровневый из языков высокого уровня, но это таки язык высокого уровня. Это не баг, а фичер. И оптимизация - фичер. - йцyкeн(18.09.2020 21:50)
        
        Сижу в отладчике, ставлю останов, а он не ставится. Бля. Хорошо, я не совсем нуб. Убрал всю оптимизацию нафиг. И всё равно на части кода остановиться нельзя. В ассемблере-то я честно пишу, что надо что-то в Rn положить. Всё просто и однозначно. Эх. - teap0t(18.09.2020 20:25)
        
        Сделай переменную volatile. Тогда место кода, где с ней идёт работа, не будет выоптимизированно. Когда отладку завершишь, уберёшь. - Nikolay_Po(19.09.2020 14:05)
        
        В нормальных компиляторах на минимальном уровне оптимизации нет разницы между volatile и non-volatile. - SciFi(19.09.2020 14:14)
        
        Наверное, я всегда веду отладку с максимальной оптимизацией. Больше ошибок и предупреждений вылазит сразу. Уже не понимаю, зачем собирать код без оптимизации, даже для отладки. Просто прицеплю volatile-переменную к параметру, в который хочу заглянуть. Оптимизацию не выключаю. - Nikolay_Po(19.09.2020 14:19)
        
        gcc -Os -flto такое выдаёт, что отладчиком туда заглядывать бесполезно, можно сразу шарить в дизассемблере... - SciFi(19.09.2020 14:58)
        
        По-моему, после LTO, и в дизассемблере бесполезно. Заглянуть в душу оптимизатору может, пожалуй, только его разработчик. Отлаживаю проверяя осциллографом на отладочный выход, на вывод UART, на дисплей, если есть. Ну и само-собой, все предупреждения устраняю, так как жизнь научила, что предупреждение компилятора - латентный баг. - Nikolay_Po(23.09.2020 13:46)
      - Нет никакой неоднозначности операций. Правила вычислений строго изложены в стандарте. Вы можете пытаться структурировать выражения так, чтобы действовали правила, которые вы знаете, и не действовали те, которые вы не знаете. Но где гарантия, что вы не пропустите какое-нибудь из неизвестных правил? Выход один -- знать правила. - SciFi(18.09.2020 19:03)
  - Не волнуйтесь за компилятор, у него всё будет хорошо. Он сам применит оптимальные инструкции. Ваша забота -- написать код без ошибок в вычислениях. SciFi(110 знак., 18.09.2020 17:34, ссылка)

ARM, RISC-V контроллеры