Теперь я, кажется, осознал Ваш вопрос (не обратил внимание на слово формат в самом начале).
Дело в том, что если посмотрите на код, который я привожу — при сборе стектрейса мы вручную сохраняем состояние файбера, поэтому от используемой библиотеки фактически ничего не зависит.
В первом случае "rbp, rbx, r15, r14, r13, r12", во втором "rbp, rbx, r12, r13, r14, r15".
Так Вы вроде перечислили одинаковый набор регистров?
Для меня не так очевидно :)
Состояние файбера (исполняемого контекста) — это состояние машины, поэтому набор сохраняемых регистров всегда одинаковый при прочих равных (платформа, операционная система).
Не совсем понимаю, что Вы имели в виду под рантаймом, но от операционной системы и архитектуры действительно зависит. Вот, например, для Windows x86_64 всё по-другому (Tarantool под Windows не поддерживается):
@xhinhellhxвсё правильно написал. Проиллюстрирую на примере OP_Column: оборачиваем этот switch-case в функцию, добавляем её в бутстрап-модуль LLVM, загружаем её сигнатуру оттуда, и, наконец, генерируем вызовы к ней, когда JIT-компилируем OP_Column'ы.
Добавлю от себя ещё, что помимо сшития (избавления от интрукций перехода) машинного кода, который дает inlining, есть возможность использовать оптимизационные проходы LLVM — за счет динамической информации об аргументах callbaсk'ов (сейчас понял, что тут этот термин действительно немного не к месту здесь), помимо прочего, можно убирать целые ветки кода (читай: constexpr if statement). Причем при таком подходе результат получается автоматически.
Теперь я, кажется, осознал Ваш вопрос (не обратил внимание на слово формат в самом начале).
Дело в том, что если посмотрите на код, который я привожу — при сборе стектрейса мы вручную сохраняем состояние файбера, поэтому от используемой библиотеки фактически ничего не зависит.
Так Вы вроде перечислили одинаковый набор регистров?
Состояние файбера (исполняемого контекста) — это состояние машины, поэтому набор сохраняемых регистров всегда одинаковый при прочих равных (платформа, операционная система).
Отличный вопрос! Я как раз забыл об этом упомянуть и прикрепить соответствующие ссылки.
От используемой библиотеки, очевидно, не зависит. Вот например, для Linux x86_64:
https://github.com/boostorg/context/blob/f1adb9261ff0f3382132c497afa80d37e8604aa8/src/asm/jump_x86_64_sysv_elf_gas.S#L60-L65 — boost.context
https://github.com/tarantool/tarantool/blob/d187b14247d071b44f02a2f1adac7f1daac137bc/third_party/coro/coro.c#L231-L236 — libcoro
Не совсем понимаю, что Вы имели в виду под рантаймом, но от операционной системы и архитектуры действительно зависит. Вот, например, для Windows x86_64 всё по-другому (Tarantool под Windows не поддерживается):
https://github.com/boostorg/context/blob/f1adb9261ff0f3382132c497afa80d37e8604aa8/src/asm/jump_x86_64_ms_pe_gas.asm#L100-L140 — boost.context
Про Windows не могу ничего сказать: забыл повесить дисклеймер в начале статьи, что речь идет о Unix системах — Tarantool только на них поддерживается.
"Нити" скорее про потоки, и то я бы не сказал, что даже тут устоялось — по крайней мере, в моем окружении все говорят "треды".
Привет!
@xhinhellhxвсё правильно написал. Проиллюстрирую на примере OP_Column: оборачиваем этот switch-case в функцию, добавляем её в бутстрап-модуль LLVM, загружаем её сигнатуру оттуда, и, наконец, генерируем вызовы к ней, когда JIT-компилируем OP_Column'ы.
Добавлю от себя ещё, что помимо сшития (избавления от интрукций перехода) машинного кода, который дает inlining, есть возможность использовать оптимизационные проходы LLVM — за счет динамической информации об аргументах callbaсk'ов (сейчас понял, что тут этот термин действительно немного не к месту здесь), помимо прочего, можно убирать целые ветки кода (читай: constexpr if statement). Причем при таком подходе результат получается автоматически.