Abnormal programming
Programming
C++
Assembler
Comments 29
0
Но чтобы эти данные как-то изменить, их в начале необходимо загрузить в регистры.
Вообще говоря это неверно для архитектуры x86. Есть команды (методы адресации) которые делают RMW или W напрямую с памятью. К примеру INC mem или MOV/ADD mem, imm
0
Ага, изменил формулировку. Я имел ввиду, что обычно нельзя изменить данные вообще не используя регистры. Тот же ADD не работает для двух memory операндов.
+1
Да я, это, собсно, так, побуквоедствовать.
В доисторической рускоязычной литературе для обозначения регистров часто использовалась аббревиатура СОЗУ (сверхоперативное ЗУ). По сути регистры — это специального вида память, которая адресуется именами регистров (во многих современных архитектурах не мудрствуют и просто называют их r0, r1,… rN). Можно, для накала, рассматривать регистры как кэш управляемый вручную.
На x86 можно написать аналог любой программы, которая использует регистры без использования оных (а вот на load-store архитектуре — не выйдет). Да, ценой быстродействия. Собстно регистровая адресация это всего-лишь способ устранения ботлнека с памятью и ничего более.
Это я к тому, что данные загружаются в регистры не «так или иначе», а для устранения проблем быстродействия связанных с доступом к памяти (как и прозрачные кэши любого уровня).
0
А как передаются параметры в функцию с переменным числом аргументов?
Ну или точнее, как она их ожидает получить? Через стек?

ideone.com/uSmc8Y
0
Смотрю в main вызовы обеих функций абсолютно идентичны. Что, в общем-то, не удивительно: они вызываются через один и тот же указатель.
Однако функция с переменным числом параметров похоже тоже забирает что-то из регистров.
А что происходит дальше — навскидку пока непонятно.
godbolt.org/g/HkqX5r
0
На 20 странице pdf описываются особенности при переменном числе аргументов. Суть в том, что в регистре `al` передаётся число используемых xmm регистров. Остальное то же самое. Внутри метода абсолютно все регистры, в которых могут быть аргументы, копируются на стек, после чего читаются из него по смещению.

Кстати, ` reinterpret_cast(accumulateFunction);` является UB:

The effect of calling a function through a pointer to a function type that is not the same as the type used in the definition of the function is undefined.


Если посмотреть на ассемблер, то видно, что регистр `al` не очищается при вызове через указатель, то приводит, собственно, к UB.
+1
Интересно, а какой смысл передавать параметры через регистры, а потом кидать их в стек и использовать уже оттуда?
0

Иначе не получится в цикле считывать неизвестное количество аргументов. Если они все на стеке, то можно просто читать [rsp, rsp+sizeof(arg)).

0

Та функция, которая с фиксированным набором параметров мне кажется то же самое делает.

0

Если скомпилировать с оптимизацией (хотя бы -O1), то не делает:


accumulate3Function(int, int, int):
  add edi, esi
  lea eax, [rdi+rdx]
  ret

GCC, кстати, хитрый. Если в функции не вызывается va_arg(args, double);, то он даже не проверяет регистр al.

0

Судя по всему, когда xmm регистров ещё не было, или в других ABI, va_arg функции были совместимы с обычными. То есть, можно было их вызывать через указатель на обычную функцию, или делать объявления с фиксированным количеством аргументов. Потом появился SSE и это стало UB.

-1

Вот если бы статья была озаглавлена "особенности вызова функций в clang (или даже llvm)" — я бы понял. А вы тут просто в одну кучу свалили всё — С++, ассемблер (кстати, зачем какие-то левые сайты, есть же директива -S у фронтенда, чтоб сразу получить ассемблер, как в gcc, не? У вас получилась статья на тему llvm abi для архитектуры x86_64. Думаю, к С++ или другому языку она имеет весьма опосредованное отношение (и не удивлюсь, если какой-нибудь скрипт js/lua после jit (если таковой есть через llvm) не будет ничем отличаться).


В целом выглядит эпично, но мне кажется такие вещи было бы гораздо познавательнее выразить через анализ ОТКРЫТЫХ исходников того же clang, чем через reverse-engineering скомпилированного кода (опять же, в свете того, что даже этот шаг можно было бы сразу вывести в формате asm, минуя ненужный дизассемблинг; ещё бы пиратскую IDA тут заюзали для наглядности...). Что подсказывает, что в этих самых исходниках ещё и камменты есть на тему что и почему...

0
Да, возможно надо было более явно указать для какой конфигурации проводился обзор. С другой стороны, для других x86_64 компиляторов выводы будут примерно такие же. ABI и стандарт С++ накладывают ограничения.
0
Меня настолько удивил результат clang для St foo(St s1, St s2) { // Просто суммируем s1 и s2., что я полез и таки посмотрел, что делает gcc. В общем, у gcc как-то там получше всё: вот.

Интересно, почему.
0
Ага, добавил про gcc. Clang, как я заметил, испытывает некоторые трудности с оптимизацией хитрых манипуляций с регистрами.
+4
А где вы тут видите дизассемблинг? Насколько я знаю, используемый автором godbolt.org как раз ключ -S и использует. Кстати, почему вы называете его «левым сайтом»?
0

Лично я не знаю, что там использует какой-то сайт (да, честно говоря, и знать это особо незачем, видя результат). И "левый" он как раз по причине, что он тут совершенно лишнее звено. ОСОБЕННО если, как вы говорите, он всего лишь запускает где-то там у себя gcc/clang с ключиком -S.

0

Все, нужные лично мне для работы. Нынче во время время докеров и быстрого интернета это минутная задача.

+4
То есть вы вместо официальных репозиториев используете какие-то левые софтины и непонятное хранилище образов? :-)
0

А gcc/clang это уже левые софтины? Ну здрассть…
Сборки под centos/rhel6/7, под long-term debian/ubuntu есть, плюс макось — а остальное неинтересно.

+1
Нет, «левой софтиной» я в шутку назвал докер. По крайней мере, два года назад он точно попадал в эту категорию.
+1
Спасибо за интересную статью, но один момент очень режет глаза. Скажите пожалуйста, в чём смысл делать оглавление и названия разделов на английском? Тут, конечно, большинство его понимает, но от этого возникает ощущение неряшливого перевода, брошенного почти в конце.
+1
Изначально была идея сохранить терминологию. Хотя сейчас, после множества изменений текста, она уже не особенно актуальна.
0
Спасибо за статью, полезно посмотреть что и как, у самого руки не так часто доходят:) В дополнение к статье добавлю свеженькое видео от Jason Turner на схожую тему — Negative Cost Structs
Only those users with full accounts are able to leave comments., please.