Ассемблерные вставки в программы на С++

https://ru.wikipedia.org/wiki/GCC_Inline_Assembly

http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#s4

Хеллоуворлд на С из ассемблерных вставок там я хелловорлд на ассемблерных вставках делал, в качестве примера вполне подойдет

там я хелловорлд на ассемблерных вставках делал, в качестве примера вполне подойдет

А почему там такой синтаксис страшный, что каждую строку с ассемблером в кавычки пихать?

А ещё syscall — почему не int 80h?

Кстати, а что лучше, gas или fasm по-твоему?

Тут, вероятно, больше вопрос синтаксиса - AT&T vs Intel. Я, например, не перевариваю AT&T. И да, у fasm на порядок круче язык макросов.

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

Какой смысл ассемблерных вставок, интересно мне. Напиши отдельно функцию на ассемблере и дёргай её там где тебе нужна вставка. По-моему пролог не сложно и ручками написать.

А почему там такой синтаксис страшный, что каждую строку с ассемблером в кавычки пихать?

Потому что так устроены ассемблерные вставки в GCC

Кстати, а что лучше, gas или fasm по-твоему?

GAS поддерживает больше, им можно под ARM, MIPS и под кучу других архитектур программировать, FASM же умеет только в x86 и x86-64, насколько я знаю. С этой точки зрения, GAS предпочтительней. Насчет макросов, я FASM не использовал и насчет его макроязыка ничего сказать не могу. В любом случае, встраивать куски, написанные на FASM непосредственно в код C/C++ для GCC не выйдет, там только GAS можно. Но можно написать библиотеку на FASM и линковать ее

В fasm его даже может написать за тебя макрос. Причём с поддержкой локальных переменных, аргументов и выбором соглашения вызова.

Напиши отдельно функцию на ассемблере и дёргай её там где тебе нужна вставка

Это тогда будет уже вызов функции, непосредственного встраивания в код так сделать не получится.

Какой смысл ассемблерных вставок, интересно мне.

Потому что можно сделать static inline. Потому что можно использовать переменные на стеке без плясок с бубном. Потому что компилятор может оптимизировать использование регистров.

Прикольно... тогда тем более.

что лучше, gas или fasm

Под x86 лучше fasm. Но gas дефолтнее и линуксовее. Еще yasm ничего.

А ещё syscall — почему не int 80h?

потому что syscall быстрее, и это стандартный способ использования системных вызовов. Посмотри на выхлоп gcc.

Тут, вероятно, больше вопрос синтаксиса - AT&T vs Intel. Я, например, не перевариваю AT&T. И да, у fasm на порядок круче язык макросов.

gas умеет сишные макросы.

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

Intelовские процессоры не поддерживают инструкцию syscall в 32-битном режиме.

Какой смысл ассемблерных вставок, интересно мне. Напиши отдельно функцию на ассемблере и дёргай её там где тебе нужна вставка.

И огреби проблем с раскруткой стека.

Intelовские процессоры не поддерживают инструкцию syscall в 32-битном режиме.

схренабы, если syscall появился задолго до amd64?

Intelовские процессоры не поддерживают инструкцию syscall в 32-битном режиме.

схренабы

смануала

смануала

пруф.

смануала

пруф.

Так и быть, у меня сегодня толерантное настроение. Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 2, SYSCALL—Fast System Call:

Operation
IF (CS.L ≠ 1) or (IA32_EFER.LMA ≠ 1) or (IA32_EFER.SCE ≠ 1)
(* Not in 64-Bit Mode or SYSCALL/SYSRET not enabled in IA32_EFER *)
    THEN #UD;
FI;

ну так SCE в EFER выставь-то.

См. syscall_init() в ядре, она инициализирует MSRы для поддержки syscall. Всё это делается только в 64-битном ядре (под CONFIG_X86_64).

ну так SCE в EFER выставь-то

Об том и речь. Если выставить IA32_EFER.LMA, то это уже не 32-битный режим процессора.

Не надо делать вставки. Надо делать отдельные файлы *.S

gas умеет сишные макросы.

4.2

*.S принято прогонять через CPP. gcc делает это.

Если выставить IA32_EFER.LMA, то это уже не 32-битный режим процессора.

во время выполнения 32-битных бинарников LMA==0, так что это 32-битный режим.

P.S. EFER и syscall были запилены вместе с K6, и для использования syscall нужно было тот самый бит SCE в EFER выставить. Это можно делать и в 32-битном режиме.

Под x86 лучше fasm. Но gas дефолтнее и линуксовее. Еще yasm ничего.

Есть fasm же и для ARM

А Yasm — это какая-то мутная попытка переписать NASM вроде... лучше бы их слили...

А что такое syscall, новая инструкция? А в каком процессоре она появилась? Я думал, это макрос, подставляющий int 80h. Какой у него опкод, не CD80?

http://download.intel.com/products/processor/manual/325462.pdf

SYSCALL invokes an OS system-call handler at privilege level 0. It does so by loading RIP from the IA32_LSTAR MSR (after saving the address of the instruction following SYSCALL into RCX). (The WRMSR instruction ensures that the IA32_LSTAR MSR always contain a canonical address.) SYSCALL also saves RFLAGS into R11 and then masks RFLAGS using the IA32_FMASK MSR (MSR address C0000084H); specifically, the processor clears in RFLAGS every bit corresponding to a bit that is set in the IA32_FMASK MSR.

SYSCALL loads the CS and SS selectors with values derived from bits 47:32 of the IA32_STAR MSR. However, the CS and SS descriptor caches are not loaded from the descriptors (in GDT or LDT) referenced by those selectors. Instead, the descriptor caches are loaded with fixed values. See the Operation section for details. It is the respon- sibility of OS software to ensure that the descriptors (in GDT or LDT) referenced by those selector values corre- spond to the fixed values loaded into the descriptor caches; the SYSCALL instruction does not ensure this correspondence.

The SYSCALL instruction does not save the stack pointer (RSP). If the OS system-call handler will change the stack pointer, it is the responsibility of software to save the previous value of the stack pointer. This might be done prior to executing SYSCALL, with software restoring the stack pointer with the instruction following SYSCALL (which will be executed after SYSRET). Alternatively, the OS system-call handler may save the stack pointer and restore it before executing SYSRET.

во время выполнения 32-битных бинарников LMA==0, так что это 32-битный режим

Нет.

EFER и syscall были запилены вместе с K6, и для использования syscall нужно было тот самый бит SCE в EFER выставить. Это можно делать и в 32-битном режиме.

Это да. Но речь была про Intel.

с разморозкой, блин. Это отдельная инструкция, появилась в 1997 году.

http://en.wikipedia.org/wiki/X86_instruction_listings

Это да. Но речь была про Intel.

ты хочешь сказать, что интел криво реализует чужие спеки больше одного раза? (/me вспомнил дыру sysret). В любом случае похер, и никто не мешает юзать sysenter вместо syscall, из юзерспейса разницы нет, разве что регистры самому надо сохранить.

спасибо

Нефиг падать