caxapa.ru :: Как правильно сдвигать в uint64

Yft (14.01.2020 16:52, просмотров: 7729)

Как правильно сдвигать в uint64_t ? Понадобилось тут на STM32 в IARе написать прогу, в ней в частности потребовалось динамически генерировать маску, в зависимости от длины слова данных, пока я не выходил за пределы 32бит конструкция типа w_mask = (1 << word_size) - 1; работала адекватно, но, начиная с word_size >= 32 полная фигня, сплошные FFы везде, что я не так делаю?

Ответить

- (1ULL << word_size) - 1 -- ибо вычисления всегда выполняются в пространстве типов операндов, переход к типу с большей разрядностью автоматически, если не влезает, невозможен. Вообще если word_size -- константа (а в нормальной программе если fk0(464 знак., 15.01.2020 01:01 - 01:04)
- Варианты: il-2(95 знак., 14.01.2020 17:46)
  - Да, спасибо, осознал, что константы тоже бывает надо приводить. - Yft(14.01.2020 17:51)
    - Неплохо было бы расшИрить и углУбить, а именно почитать на тему integer promotion в языке Си. - SciFi(14.01.2020 19:28)
- Может, 1ULL? - йцукен(14.01.2020 17:04)
  - Да, помогло, спасибо! - Yft(14.01.2020 17:50)
- Хех, коллега VLLV недавно мучился, пока мы общими усилиями не нашли косяк: - SciFi(14.01.2020 17:00, ссылка)
  - Дискуссия была напрасной и в самый ответственный момент наступила катастрофа. В результате например 64-битная маска определяется вот так: VLLV(272 знак., 14.01.2020 17:52)
    - uint64_t Mask(uint8_t x) { return 1ull << x; } Эта функция не может не работать. - il-2(15.01.2020 16:23)
      - В умелых руках всё сломается... - SciFi(15.01.2020 16:25)
    - И гемор с ендианностью на ровном месте. - fk0(15.01.2020 01:05)
      - Одним местом больше, одним меньше. Мне трудно представить, что можно все написать без привязки к ендианности. Понатыкано обращения к уникальной периферии, и тут ррраз - давай свободу от ендианности? - VLLV(17.01.2020 13:22)
      - Это не ендианность виновата, а то свойство языка C/C++, что результат выражения не бывает длиннее самого длинного из операндов. Ксения(241 знак., 15.01.2020 17:33)
        
        Ну почему, вместо того чтобы писать такое вранье, люди не могут осилить несколько абзацев из стандарта про integer promotion rules, прямые ссылки на которые неоднократно тут давал SciFi. - il-2(17.01.2020 12:10)
        
        Почему же враньё? Я так понимаю: "int8_t a, b; int16_t c = (int16_t)a * b;" вполне себе нормально работает. Если компилятор не подставил туда инструкцию типа 8x8=16 - это дурной компилятор, язык Си тут ни при чём. - SciFi(17.01.2020 12:43)
        
        "результат выражения не бывает длиннее самого длинного из операндов". Твой пример можно написать и без приведения к int16_t: il-2(40 знак., 17.01.2020 12:50)
        
        Можно. Тогда у произведения в старшем байте будет ноль (или 0xFF - размноженный бит знака). Но зачем? - SciFi(17.01.2020 13:10 - 13:20)
        
        Семен Семеныч!!! От тебя я даже не ожидал такой прорухи :-) Проверь!!! - il-2(17.01.2020 13:51)
        
        А, ну да, int же. - SciFi(17.01.2020 13:52)
        
        Строго говоря, в C++ это верно только для встроенных типов, определённый пользователем operator* не обязан возвращать тот же тип, что его операнды. - йцукен(15.01.2020 19:18)
    - Надо было организовать дискуссию 2.0, чтобы найти косяк 2.0. - SciFi(14.01.2020 19:24)
      - Иногда нужно прибить ржавыми гвоздями и идти дальше. - VLLV(14.01.2020 19:29)
        
        А поговорить? Ржавые гвозди можете оставить, но код-то предъявите, а то ведь сон потеряем. Опять же мало ли что, будет катастрофа 3.0, коль скоро урок так и не усвоен. - SciFi(14.01.2020 19:34)
        
        У меня осталось мало активных лет, пока травой не стал, поэтому катастроф не боюсь. "А поговорить" ... вот несколько требований к коду у заказчика :) VLLV(14.01.2020 19:54)
        
        Требуйте удвоенную оплату :-) - SciFi(14.01.2020 20:03)
        
        В принципе если перейти на C++ -- то терпимо. - fk0(15.01.2020 01:08)
        
        и программировать в функциональном стиле - =AlexD=(15.01.2020 07:03)

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