Здравствуйте. В проекте функция реализована как ассемблерная процедура. Состоит из одной инструкции и хотелось бы преобразовать её в макрос, чтобы не тратить такты на вход и выход.
Реализована в *.s файле в виде

Далее используется в *.c файлах как обычная функция b2 = MULSHIFT32(*cptr++, a1 - a2) << (s1);

Не зная тонкостей синтаксиса ассемблера IAR попробовал "в лоб" реализовать таким образом


Линкер ругается на неизвестное имя MULSHIFT32. Ключевые слова PUBLIC и EXTERN вызывают ошибку. Кто подскажет, как этот макрос правильно оформить, чтобы можно было использовать его вне *.s-файла?

Не занимайтесь ерундой. Умножать с нужной разрядностью - дело компилятора.



Дадут вам

VladislavS, спасибо за идею. Это не совсем то, что нужно, но получилось слегка ускорить алгоритм.
Создал обычный макрос

Всё-равно получается избыточно, если верить листингу.

Было до


Стало после


В моём случае объявить, как в Вашем примере 64-битную переменную и положить в неё результат 32х32 не получится.

Из любопытства попробовал на GCC вот такое:

Получилось вот что:

А если написать вот так

То получается АдЪ:

Если Вам нужны только старшие 32 бита (как следует из этого макроса), то всё просто:
#define MULSHIFT32(x, y) __SMMUL(x, y)

Во-первых, очень некрасиво не показывать типы используемых переменных и желаемого результата.
Во-вторых, разберитесь с размерностью вычислений. Написанный вами макрос делает совсем не то что вы хотите.
В-третьих, ваш mulshift32, судя по всему, это банальное

Поверьте, компилятор сделает всё лучше вас, особенно с оптимизацией. Только не мешайте ему.

В-четвёртых, вместо x и y можете ставить что угодно, только с соблюдением типов.

Вангую, что автор не сам ваяет, а пытается запустить/портировать готовое, где уже есть много MULSHIFT32()...

Дарю

Кстати, если в моём эксперименте с GCC сделать так

то код генерится вменяемый.
Очевидно, в первоначальном варианте макроса не хватает скобок вокруг аргументов. На первый взгляд, в данном случае неважно, но, возможно, я что-то не заметил.

jcxz, всё верно, чужие библиотеки. Портирую mp3-декодер Helix. В очередной раз)


Спасибо. Даже забыл, что в IAR есть intrinsic-ассемблер, как всё просто оказывается.

Спасибо за подарок.
Прогнал оба варианта на разных уровнях оптимизации. По оси ординат разница выполнения алгоритма в мс. Time( __SMMUL(x, y)) - Time((((int64_t)(int32_t)(arg1)*(int32_t)(arg2))>>32)). Без оптимизации паритет, на умеренной оптимизации использование интринсик-функции __SMMUL(x, y) оказывается более быстрым, в случае максимальной оптимизации по скорости выигрывает решение от VladislavS. Разница не существенная, в районе 1%.
Нажмите для просмотра прикрепленного файла

Дизассемблер для каждой из реализаций. Алгоритм раскладывается в одни и те же инструкции, но с использованием разных РОН.


И хотя первоначальный вопрос про синтаксис макросов остался открытым, но задача решена другими средствами. Спасибо за помощь!

Имеется в виду вот этот вопрос?

Тогда ответ такой: никак. Это макросы ассемблера, фактически текстовая подстановка в пределах ассемблерного файла. Ни разу не видел, чтобы такие вещи действовали в сишных файлах. И уж точно на уровне линкера ничего этого быть не может.

Ну вот я так и думал, что Helix
И макрос этот я запостил как раз из своего работающего проекта на Helix
Что ваяете, если не секрет?

Вот оно что. Спасибо. С ARM-ассемблером пару раз в жизни сталкивался, не знал про эти тонкости.
jcxz, в двух словах - интерактивная игрушка для детей, ничего серьёзного. Кодек этот давно ещё портировал на cortex M3 (не без помощи здешних форумчан). Теперь перевожу на cortex M4, ну и решил по-максимуму из него выжать и закрыть тему навсегда.

__SMMUL() может быть чуть-чуть лучше если нужно ещё и округление результата: __SMMULR().
Правда без возможности предварительного сдвига результата влево на 1 бит, это округление редко бывает полезным.
Не знаю почему в системе команд не предусмотрена опция сдвига влево результата на 1 бит.

Если есть возможность не уходить от чистого С/C++, то лучше от него не уходить. Чтобы не возникало потом таких тем как эта. Вот что заставило автора того кода ассемблерную функцию применить? Компилятор не знал команду smmul или программист не смог ему объяснить что он хочет? Я ставлю на второе.

"Не смог объяснить компилятору" - тоже неоднозначная вещь. Если семантика языка Си не даёт компилятору применить оптимальные инструкции, тогда согласен, лучше допилить исходный код. А если компилятор туповат, и для одинаковых по семантике исходников может генерить как более, так и менее оптимальный код, то ловить вариант, который ему более по душе, - сомнительное занятие.

Не надо ничего ловить. Надо правильно применять язык. Ну что далеко ходить, пример из этой темы. Надо было перемножить два 32-битных числа, получить 64 битный результат и взять старшие 32 бита. Автор тут же рождает макрос, который перемножает два 64-битных числа. Тут же его последователь на другом компиляторе получает "АдЪ". Хотя, компилятор сделал в точности то что его просили и вовсе он не туповат. Сомневаюсь, что сейчас можно найти туповатый компилятор для ARM. Не так уж много способов записать правильно требуемый алгоритм. Сделайте это, а с остальным компилятор разберётся.

ЗЫ: Я не отрицаю, что есть такие вещи, которые чистым С не описать. Но их ещё поискать надо и чаще всего можно интринсиками обойтись без применения ассемблера в чистом виде.

Искать далеко не надо. Попробуйте-ка к примеру определить номер самого старшего "1"-ного бита в переменной на чистом си. Каков будет размер кода? Сумеете объяснить компилятору на ARM, что можно обойтись одной CLZ?
А такая операция, мне например, частенько бывает нужна.

Аналогично - инструкции с "насыщением".

Могли бы показать пример кода, где вы CLZ применяете?
Правда, интересно глянуть.

А какой смысл? Вы считаете, что сможете вот так прям показать как обойтись без CLZ?
Видимо разработчики ARM-архитектуры всё-таки считают, что CLZ нужна раз ввели её.

Что-ж... Например в текущем проекте:
1. Во всех местах, где нужно преобразование IP-адреса и маски подсети из формата типа 192.168.1.x/255.255.255.0 в упакованный формат 192.168.1.x/24.


2. В местах, где нужно преобразовать битовую карту в список значений:


3. В распаковщике сжатого битового потока:


4. В API разных служб, которые принимают и фиксируют клиентские запросы (в битовой карте) и впоследствии их обрабатывают по мере освобождения службы и в порядке приоритета.

Итого - в десятке мест.
в хидерах:
#define CntLeadingZeros() __CLZ()
#define ReverseBitOrder() __RBIT()

В другом проекте есть например использование CLZ при распарсивании UTF-8 кодировки принимаемой с терминала:

Нет, мне реально интересно где и как вы используете CLZ. Спасибо за примеры.

И всё же, я считаю, что надо по максимуму использовать возможности языка для переносимости. Затем интринсики и в самых тяжёлых случаях асм.

UPD: В случае с CLZ с переносимостью как раз полный порядок. Она есть практически во всех процессорах, за исключением всяких 8-биток.

Но стандартными средствами языка си её как видимо не получить на современном уровне развития компиляторов.
Не настолько они ещё интеллектуальны, чтобы цикл, реализующий функционал CLZ, компилятор заменял на CLZ (хотя - может какие-то уже умеют? 8-)
Вот именно поэтому у меня и есть макрос CntLeadingZeros(), разворачивающийся на ARM в CLZ, на других CPU - в их соответствующие инструкции. Или в циклы, там где нет подобной инструкции.
А ещё недавно и конструкцию (long)((long long)(long)(x) * (long long)(long)(y) >> 32) IAR видимо не догадывался заменить одной командой.

Так у IAR теперь есть GCC inline assembler
так что можно и inline функции на асме писать.

IAR с GNU Compiler Collection?

Вы документацию смотрели на IAR?
там теперь можно



и такую функцию можно сделать inline

Да, но не GCC.

В доке на IAR теперь указано
"The syntax of an inline assembler statement is (similar to the one used by GNU gcc):"
Но и в самой документации, довольно неплохо описано как им пользоваться.