caxapa.ru :: Сущесвует ли в IAR макросы типа LSB() и MSB(), существующие в GCC для выцарапывания младшего и старшего байта из 16- или 32-битного числа? В смысле, чтобы не самоделкой было, а чем-то общепринятым/стандартизованным.

Ксения (28.04.2019 14:19, просмотров: 11002)

Сущесвует ли в IAR макросы типа LSB() и MSB(), существующие в GCC для выцарапывания младшего и старшего байта из 16- или 32-битного числа? В смысле, чтобы не самоделкой было, а чем-то общепринятым/стандартизованным.

Ответить

- А нельзя в ГЦЦ посмотреть на эти макросы (если это действительно макросы), и написать в ИАРе такие же? - йцукен(28.04.2019 16:54)
  - Кстати о птичках. А где в gcc lsb и msb? Не в man-е не поиском по инклюдам не находится. - kaf1(28.04.2019 17:21 - 17:23)
    - Это в Ардуиновом GCC :) эти два макроса определены в compiler.h так: Ксения(177 знак., 28.04.2019 17:49)
      - Когда-то подобные макросы (и не только для первого и второго байтов) применял в CodeVisionAVR, смотрел АСМ, всё было ОК. Попробовал такое в ИАР, там всё это превращается в кучу кода (может сейчас по другому). Думаю это из-за того, что в maleon(112 знак., 29.04.2019 13:59)
        
        Ну, прямо уж в кучу. Так, небольшая кучка. Макро с адресами оказываются несколько медленнее, чем с данными, но могут применяться слева от знака присваивания. йцукен(3088 знак., 29.04.2019 16:51)
        
        Я имел ввиду IAR AVR. Для него "куча АСМ-кода" побольше будет. - maleon(29.04.2019 20:30)
      - Извращение какое то. - kaf1(28.04.2019 17:57)
        
        Извращение вот: #define LOWBYTE(x) x%256 :) - Ксения(28.04.2019 19:19)
        
        Хорошо. Ксения назначается главным специалистом по извращениям. Если имелось ввиду (x%256), то компилятор просто возьмет младший байт. Иначе это хождение по граблям. - kaf1(28.04.2019 19:30 - 20:14)
        
        В x86-ассемблере MASM есть операторы (даже не макросы!): LOW, HIGH, LOWWORD, HIGHWORD, LOW32, HIGH32. Как же без этого? - Ксения(28.04.2019 18:58, ссылка)
        
        Под Windows оно тоже есть в windef.h, только называется иначе - LOBYTE() и HIBYTE(): Ксения(126 знак., 28.04.2019 18:49)
        
        DWORD_PTR - тоже извращение. Название намекает, что это указатель на uint32_t, но фактически это не так. - йцукен(28.04.2019 20:10)
        
        Если память не изменяет, это размер самого указателя. Вместе с сегментом. - Скрипач(28.04.2019 20:45)
        
        Здесь сделано нормально. Это будет работать на любой архитектуре и компиляторе. - kaf1(28.04.2019 18:52)
        
        Вся адурина сплошное извращение. - SciFi(28.04.2019 17:58)
        
        вау, адурина... спасибо, не слышал о таков варианте ) - Kilkennycat(28.04.2019 19:35)
- union - Evgeniy1294(28.04.2019 15:42)
  - Дык объединение позволяет выделить меньшие и бо́льшие адреса. А старшие и младшие - это другое. Там индейцы порылись. - SciFi(28.04.2019 15:46)
    - А если так? mse homjak(157 знак., 28.04.2019 20:40)
      - 8-ми битник адресовать такое не сможет. На arm union работает за счёт аппаратных команд. - Evgeniy1294(29.04.2019 10:22)
        
        Чего это вдруг? Загрузит её в R16:R19 и отадресует. Такая муйня должна адресоваться на любом процессоре. - mse homjak(29.04.2019 12:21)
    - Тогда интринсики, на 8-ми битниках обычно есть соответствующие команды. На armv7 вообще идеально, есть команды на чтение байтов, полуслова и слов + simd. - Evgeniy1294(28.04.2019 15:52)
      - Не нужно это всё, сдвиги решают, современные компиляторы нормально тут оптимизируют. - SciFi(28.04.2019 15:57)
        
        Дык Ксению они не устраивают. Хочет магии - пусть будет. - Evgeniy1294(28.04.2019 16:14)
- А чем сдвиг на 8 не люб? Скрипач(119 знак., 28.04.2019 14:28 - 14:31)
  - Не люб тем, что для MSB еще и на 8 бит вправо двигать надо, а мне противно в сотне мест писать "(b >> 8) & 0xFFu". А если я сама создам такой дефайн, то посторонним код будет непонятен. Вот и хотелось бы что-то такое общепринятое, а идеально, если Ксения(31 знак., 28.04.2019 14:54)
    - Пустая абстракция детектед. Скрипач(406 знак., 28.04.2019 15:06 - 20:43)
    - При сдвиге на 8(16/24) ничего никуда не двигается - просто берется нужный байт. Посмотрите выходной листинг. - kaf1(28.04.2019 15:53)
    - Если "посторонние" не могут понять такие простейшие вещи, то они вообще ничего не поймут. Я бы таких посторонних к коду не подпускал. - SciFi(28.04.2019 14:57)
  - +1. - SciFi(28.04.2019 14:30)
- Конечно есть lloyd(84 знак., 28.04.2019 14:28)
  - Пример из IAR AVR. Здесь все регистры однобайтные, как и доступ в память, а потому LSB и MSB существуют чисто физически - лежат в отдельных регистрах или ячейках памяти. Взять их оттуда - не проблема. Однако ваша формула потребует извлечь из Ксения(246 знак., 28.04.2019 15:11 - 15:13)
    - это Вы оптимизацию не включаете - VLLV(28.04.2019 17:48)
    - Я - заглядываю. Не делают этого компиляторы. Оптимизируют до единичного чтения. Скрипач(41 знак., 28.04.2019 15:17)
    - Я в асм смотреть умею, не надо тут. Вам нунжо было портабельное решение, я его вам выкатил, работать будет на любом компиляторе. А что до деталей - ну, знаете, PRU-ICSS умеет работать с отдельными байтами в регистровом файле, но вы действительно lloyd(36 знак., 28.04.2019 15:17)
  - А если "& 0xFFu" убрать, что-то может измениться? - s_h_e(28.04.2019 14:33)
    - Весьма правильное замечание с вашей стороны. - Ксения(28.04.2019 14:56)
    - Некоторые компиляторы выдают предупреждение "значение обрезается при приведении типа" или что-то в этом духе. - SciFi(28.04.2019 14:37)
      - Ну так оно полюбому обрезается. 0xFFu - это же unsigned long (long) int. - s_h_e(28.04.2019 14:41, ссылка)
        
        Не понял, к чему это. Однако, сам маску не накладываю, и мой компилятор (gcc) не ругается, потому и не парюсь. - SciFi(28.04.2019 14:47)
        
        Это правильно. - s_h_e(28.04.2019 14:49)

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