Ассемблер в Linux для программистов C

>Я имею ввиду GNU assembler..

Гну асемблер предназначен прежде всего для компилятора, а не для человека. А компиляторы умеют генерить только AT&T синтаксис. По крайней мере GCC. А чаще приходится не чисто ассемблерные тексты писать, а именно __asm вставки в С-код. Так что тут без выбора.

>Быдлоассемблер не нужен, нормальные перцы пишут на C#.

Спасибо, повеселил, то-то их столько на .Net развелось. Столько, что просто кошмар %)

>Быдлоассемблер не нужен, нормальные перцы пишут на C#.

ЗЫ Подсказка - они не перцы:P

Скоро все языки вымрут, останится только .NET и си-решетка. А процессоры будут напрямую исполнять .NET-байткод, и наступит долгожданный x86-капец.

клёво конечно, но хотелось бы и про работу с железом. Собственно, всё остальное и так известно. У Рудольфа Марека всё это прекрасно изложено. Хотя...пусть будет. Добавил в favourites.

>В книжке есть пример цикла! Кто первый скомпилет и выложит результаты (time)?

>Я прервусь на пробежку...

asm: 0.000066; c: 0.000021

Сорец: http://pastie.org/215384

Получившийся файлик: http://pastie.org/215386

Итого C в 3 раза быстрее (гыгыгы).

Компилятор воткнул туда cmovll, тем самым избежал ненужных jcc и в итоге получилось быстрее.

Хотя по мне сишный цикл выглядит дико.

>Компилятор воткнул туда cmov

Что тебе самому мешало его туда воткнуть. Кстати, CMOV не всеми процами поддерживается, прежде, чем ее заюзать надо проверять CPUID. gcc -mcpu=native именно это и делает.

> Что тебе самому мешало его туда воткнуть. Кстати, CMOV не всеми процами поддерживается, прежде, чем ее заюзать надо проверять CPUID. gcc -mcpu=native именно это и делает.

Я копировал код из книжки.

Компилятор знает об оптимизациях, а сидящий перед клавой может и не знать. Поэтому писать на асме в userspace зло

> Итого C в 3 раза быстрее (гыгыгы).

Вот, я то думал уже страниц пять холивара настрогали. Мда, так все и закончилось.

CMOV (Conditional Move) is an x86 instruction set released with the Intel Pentium Pro.

The Pentium Pro is a sixth-generation (P6 core) x86 architecture microprocessor produced by Intel in November 1995

$ date +%Y

2008

>_синтаксис_, а не программа. nasm как раз TASM-подобный.

У TASM'а два типа синтаксиса: MASM и IDEAL. У NASM'а как раз MASM'овский синтаксис.

>Хвостовая рекурсия в ассемблере это jmp

А ещё man gcc на счёт хвостовой рекурсии.

>The Pentium Pro is ...

у мну i486

>>The Pentium Pro is ...

>у мну i486

Хорошо, ты же пользуешься каким-нить отсталым дистром в котором всё с -farch=i486 скомпилино. И у тебя нет cmov'ов. А у всех кто за 13 лет купил новый комп, они есть … и все счастливы.

При условии что кто-нибудь не написал на асме говнокод который везде одинаков и не использует новые замечательные фичи.

Вобщем напишите автору этой статьи чтобы он большими красными буквами в начале написал: использование асма вредно для вашего здоровья.

AT&T не нужно. Есть FASM.

> использование асма вредно для вашего здоровья.

А его незнание - смертельно. )))

Я переместил книгу сюда: http://ru.wikibooks.org/wiki/Ассемблер_в_Linux_для_программистов_C Можно редактировать.

PS. Я -- автор.

Просто не писюках с досом детки учились, там только интеловский синтаксис и был. А кто постарше, те учились на серьёзных машинах и с at&t синтаксисом. Вот и вся разница.

IL не предназначен вообще для непосредственной интерпретации. Он изначально для JIT создан.

gcc тоже jump сделает.

> Сколько было уже новостей по этой теме, а внятно объяснить, чем же плох синтаксис TASM, так никто и не объяснил.

в ат&т обязательно указывается размерность операндов в самом опкоде. никаких word ptr и тп лабуды.

зы. капча - drivers

>Сколько было уже новостей по этой теме, а внятно объяснить, чем же плох синтаксис TASM, так никто и не объяснил.

Синтаксис intel полон неоднозначностей. Из обруливают всякими костылями типа "word ptr, byte ptr". В особых случаях (например включение защищённого режима), вообще приходится указывать напрямую код команды.

Макросредства с синтаксисом вообще никак не связаны, и для AT&T есть функциональные препроцессоры.

>gcc тоже jump сделает.

Естественно. А что, по твоему, вобще такое "оптимизация хвостовой рекурсии"? Это и есть "замена вызова функции на непосредственный переход в её начало":)

Щёлк: "Книга переехала сюда", щёлк: "БУУЕНВМЕТ Ч Linux ДМС РТПЗТБННЙУФПЧ C - В настоящий момент текст на данной странице отсутствует. Вы можете найти упоминание данного названия в других статьях или создать страницу с таким названием."

Охохохохо...

> Щёлк: "Книга переехала сюда", щёлк: "БУУЕНВМЕТ Ч Linux ДМС РТПЗТБННЙУФПЧ C - В настоящий момент текст на данной странице отсутствует. Вы можете найти упоминание данного названия в других статьях или создать страницу с таким названием."

Твой браузер неадекватен

C: gothers

>Я переместил книгу сюда: >http://ru.wikibooks.org/wiki/Ассемблер_в_Linux_для_программистов_C >Можно редактировать.

а как скачать теперь?

// shoook o_O

> Щёлк: "Книга переехала сюда", щёлк: "БУУЕНВМЕТ Ч Linux ДМС РТПЗТБННЙУФПЧ C

Держи ссылку: http://ru.wikibooks.org/wiki/%D0%90%D1%81%D1%81%D0%B5%D0%BC%D0%B1%D0%BB%D0%B5...

> а как скачать теперь?

Сохранить страницу из wiki. Да, раньше был docbook и можно было сделать и xhtml, и pdf и что угодно. Но я решил, что в формате wiki у книги больше будущего.

>Я переместил книгу сюда: http://ru.wikibooks.org/wiki/Ассемблер_в_Linux_для_программистов_C Можно редактировать.

>Так как Linux является полностью 32-битной операционной системой, то мы будем рассматривать только 32-битный режим.

Марш назад в 2003 год!!!

>int $0x80 /* вызываем прерывание 0x80 */

А как же SYSCALL и SYSENTER?

В остальном, кстати, много полезной инфы. Следует добавить про 64 бита и выше описанные инструкции (это недочеты, сразу бросающиеся в глаза). А также хотелось бы инфу о синтаксисе описания asm в C, его позиционных параметрах и ограничениях. Может, если будет время, сам попишу правки :)

Некоторые процессоры имеют отдельную инструкцию для stack slice + jump.

> Марш назад в 2003 год!!!

Написано ведь, архитектура -- IA-32 :)

> А как же SYSCALL и SYSENTER?

Они есть не на всех процессорах, а на некоторых процессорах есть, но глючные. Но об этом тоже стоит написать, согласен! :)

Про 64 бита было бы здорово. Но нужно чётко разграничить 32- и 64-битные абзацы. Ведь i386 ABI и x86_64 ABI имеют отличия.

> >Я имею ввиду GNU assembler..

> Гну асемблер предназначен прежде всего для компилятора, а не для человека. А компиляторы
> умеют генерить только AT&T синтаксис. По крайней мере GCC. А чаще приходится не чисто 
> ассемблерные тексты писать, а именно __asm вставки в С-код. Так что тут без выбора. 

По поводу генерить:
gcc -S -masm=intel

По поводу инлайнить:
int f() {
    asm(".intel_syntax noprefix");
    asm("nop");
    asm("mov eax, 0");
    return 0;
}
gcc -c -masm=intel $^

Также есть  .altmacro, включающая макросы GAS
почти как TASMовские (со склейками &).

Ну во-первых не TASM а intel синтаксис, а во-вторых не хуже, просто другой, исторически сложилось.

>gcc -c -masm=intel

Если это Интелёвый синтаксис, то я - древнееврейский быдлокодер. Процентики-то никуда не делись.

> Если это Интелёвый синтаксис, то я - древнееврейский быдлокодер. Процентики-то никуда не 
> делись. 

gcc-4.3.1:
int f() {
    return 0;
}
$ gcc -S -masm=intel a.c
$ cat a.s
        .file   "a.c"
        .intel_syntax noprefix
        .text
.globl f
        .type   f, @function
f:
        push    ebp
        mov     ebp, esp
        mov     eax, 0
        pop     ebp
        ret
        .size   f, .-f
        .ident  "GCC: (Gentoo 4.3.1 p1.0) 4.3.1"
        .section        .note.GNU-stack,"",@progbits

Не надо тут лажу пропихивать. Во первых при такой оптимизации (-O4) ф-ция на С на этапе компиляции обсчитывает константные выражения и готовый результат выдает
.file "test_c.c"
.text
.p2align 4,,15
.globl c_find
.type c_find, @function
c_find:
pushl %ebp
movl $151, %eax
movl %esp, %ebp
subl $32, %esp
leave
ret
.size c_find, .-c_find
.ident "GCC: (GNU) 4.2.4 (CRUX)"
.section .note.GNU-stack,"",@progbits

Во вторых если бы вы действительно пробовали скомпилировать пример с теми "сорцами" по ссылке http://pastie.org/215384 то ничего бы не получилось из-за разницы в объявлении ф-ции внутри main.c (asm_find) и внутри модуля asm (_asm_find)

>Asm мёртв, Линкус тоже!!! толсто

Asm скорей жив, чем мертв!!!

> Да, раньше был docbook и можно было сделать и xhtml, и pdf

А вернуть эту радость никак нельзя?

Для этого я привел результат компиляции.

Вот один test_c: http://pastie.org/215430

http://pastie.org/215433

>Во вторых если бы вы действительно пробовали скомпилировать пример с теми "сорцами" по ссылке http://pastie.org/215384 то ничего бы не получилось из-за разницы в объявлении ф-ции внутри main.c (asm_find) и внутри модуля asm (_asm_find)

Что за разница в объявлении?

asm_find должен стать _asm_find, ты про cdecl слышал?

> asm_find должен стать _asm_find, ты про cdecl слышал?

В Linux не должен.

> А вернуть эту радость никак нельзя?

Могу выложить исходник в формате docbook, но какой смысл это делать, если все правки будут делаться в wiki? (да и я уже во время переноса в wiki кое-что поправил, в docbook не перенёс).

>Для этого я привел результат компиляции.
Это результат компиляции не с оптимизацией -O4
>Что за разница в объявлении?
Попробуй скопипастить свой пример из ссылки и обнаружишь что ld не находит внешнюю ф-ию asm_find потому что внутри модуля test_asm.s она продекларирована как _asm_find
Приведи пример с оптимизацией где gcc не будет возвращать результат а будет считать чтото в своей внешней ф-ции - тогда и можно говорить а просто вернуть результат на асме можно еще быстрей :)

>gcc-4.3.1:

gcc-4.2.3:

int f() { return 0; }

$ gcc -S -masm=intel a.c $ cat a.s

.file "a.c" .intel_syntax .text .globl f .type f, @function f: .LFB2: push %rbp .LCFI0: mov %rbp, %rsp .LCFI1: mov %eax, 0 leave ret .LFE2: .size f, .-f .section .eh_frame,"a",@progbits .Lframe1: .long .LECIE1-.LSCIE1 .LSCIE1: .long 0x0 .byte 0x1 .string "zR" .uleb128 0x1 .sleb128 -8 .byte 0x10 .uleb128 0x1 .byte 0x3 .byte 0xc .uleb128 0x7 .uleb128 0x8 .byte 0x90 .uleb128 0x1 .align 8 .LECIE1: .LSFDE1: .long .LEFDE1-.LASFDE1 .LASFDE1: .long .LASFDE1-.Lframe1 .long .LFB2 .long .LFE2-.LFB2 .uleb128 0x0 .byte 0x4 .long .LCFI0-.LFB2 .byte 0xe .uleb128 0x10 .byte 0x86 .uleb128 0x2 .byte 0x4 .long .LCFI1-.LCFI0 .byte 0xd .uleb128 0x6 .align 8 .LEFDE1: .ident "GCC: (GNU) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)" .section .note.GNU-stack,"",@progbits

И где тут Интел-синтаксис? Что-то я не припомню процентиков в Интеловских томах.

>В Linux не должен.

У меня не Linux. И это ничего не меняет всё равно.

Видать gcc < 4.3 так не умеет.

Будем надеяться - у Вас когда-нибудь обновится компилятор, и вы сможете во всю силу использовать '%'less gcc-intel выхлоп (понятия не имею зачем он может понадобиться) :]

> Попробуй скопипастить свой пример из ссылки и обнаружишь что ld не находит внешнюю ф-ию asm_find потому что внутри модуля test_asm.s она продекларирована как _asm_find >Приведи пример с оптимизацией где gcc не будет возвращать результат а будет считать чтото в своей внешней ф-ции - тогда и можно говорить а просто вернуть результат на асме можно еще быстрей :)

Я привел рядом скомпилированное, грепни по test_c и увидишь что оно не возвращает значение, а именно считает в цикле.

C: syseday

Можно увидеть
#gcc -v
и действительное значеие оптимизации при получении того дизасма - просто хочется повторить пример.

>> В Linux не должен.

> У меня не Linux. И это ничего не меняет всё равно.

А что это должно было поменять?

> all C symbols (i.e., functions and global variables) have a underscore prefix appended to them by the C compiler. (This rule is specifically for DOS/Windows, the Linux C compiler does not prepend anything to C symbol names.)

из http://www.drpaulcarter.com/pcasm/

Т.е. тут код под венду =) - http://pastie.org/215384

Чтобы скомпилить под линухом, пришлось заменить _asm_find на просто asm_find.