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

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

предвосхищая крики о ненужности ассемблера:
* загрузчик без ассемблера не сделаешь
* есть ещё всякие мини-девайсы, куда линукс не запихнёшь

А почему основную статью в wikibooks не расширили? ЛИцензия всё-равно ведь та же.

ИМХО устаревшая статья. Сейчас было бы интересно почитать про оптимизацию с использованием simd, а не описание регистров i386.

> * загрузчик без ассемблера не сделаешь

openBoot на Forth'e

> * есть ещё всякие мини-девайсы, куда линукс не запихнёшь

Ну если туда _линукс не запихнёшь_, то форт тоже ОС в некотором смысле

неплохая статья, вспоминаю молодость и досовский ассемблер.

Автору респект и уважуха. Вроде все понятно написано, попробую дома разобраться.Статья оставила очень хорошее впечатление, хотя и листал по диагонали. Было бы здорово, если бы там был еще параграф про инлайн ассемблерного кода в си-шный. Manhunt (*) (25.03.2009 23:18:51)

Хорошее описание синтаксиса AT&T, который, к слову, намного лучше интелловского. Хотя бы потому, что в нем однозначно указывается размер операндов, а не применяются конструкции типа byte ptr и word ptr, что часто помогает избежать глупых ошибок.

P.S. Не понял только, где там Linux. В примерах используются только вызовы libc, никаких тебе int $0x80. Это скорее вообще под UNIX.

По первому взгляду очень понравилось.

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

> Сейчас было бы интересно почитать про оптимизацию с использованием simd, а не описание регистров i386.

Intel Optimization Reference Manual.

> Было бы здорово, если бы там был еще параграф про инлайн ассемблерного кода в си-шный

Действительно, сейчас просмотрел - все примеры на чистом асме. Хотя анонс звучит как "Используя Си и ассемблер вместе..." - нет там "вместе" или не сказано в каком месте. :)

Асм можно юзать в сугубо системных вещах, базовых библиотеках. Прикладникам эти знания ни к чему.

> Не понял только, где там Linux.

Ну как же!

[user@host:~]$ gcc hello.s -o hello
[user@host:~]$ ./hello

Где ещё найдёшь такие смешные строчки? :) (особенно смайлик после host)

Линух там есть уже в силу использования int $0x80

Но статья таки про асм, Линукс там только полубоком.

>Асм можно юзать в сугубо системных вещах, базовых библиотеках.

Асм можно юзать везде. Решение использовать или нет остается за конкретным программистом.

Хорошая статейка, приятная на чтение.

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

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

> Линух там есть уже в силу использования int $0x80

Ага, точно есть. А я чет сразу и не заметил :)

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

Абсолютно согласен. В абсолютном большинстве случаев ассемблер - это ассемблерные вставки в С, а не польностью на ассемблере message box в gui выкидывать.

А уже была такая нововсть, не?

Интересная книга, актуальная. Куплю в бумажном виде - будет настольной книгой, вместе с "PDP-11 для чайников".

Спасибо, давно искал

Даа, спасибо!!!!! Давно уже хотел разобраться с асмом, думаю, это мне очень поможет!!!

спасибо, полезно для таких нубов как я :)

> Линух там есть уже в силу использования int $0x80

Вы всё ещё кипятите? syscall рулит :)

По теме: ассемблер "в Linux" не нужен, максимум только в каталоге arch ядра. Для использования всяких SSE есть xmmintrin.h и другие.

Хотя знать ассемблер всё равно полезно, просто применять не нужно.

Баяну 50 лет в обед (%

> Вы всё ещё кипятите? syscall рулит :) syscall - это всего лишь обертка для int $80h реализованная в glibc.

> Линух там есть уже в силу использования int $0x80

Я как бы рискую огорчить всех до невозможности, но Linux давно (с ранних версий 2.6, по-моему) прогрессивен и вместо int 0x80 у него sysenter. Собственно, ядро в связке с glibc поддерживает оба варианта, но применяет прерывание только на старых процессорах (если не ошибаюсь, sysenter появился в Pentium или Pentium Pro). Ну и под некоторыми гипервизорами.

> syscall - это всего лишь обертка для int $80h реализованная в glibc.

ФигасЕ, а мужики-то не знают... Хотя, если к нему букву v спереди приписать, то в каком-то смысле да.

> Асм можно юзать в сугубо системных вещах, базовых библиотеках. Прикладникам эти знания ни к чему.

BLAS - Это пакет прикладных программ? Reference BLAS (написанный на Fortran) на некоторых архитектурах в 5 раз уступает оптимизированной ассемблерной версии.

Простой пример V[0:N-1] = 0.; На некоторых архитектурах ассемблерная версия даёт выигрыш в 3 раза.

Вот Вам и прикладник!

Кстати, кто нибудь знает, какого максимального размера в программе на C стек?

Управляется ли размер компилятором, или ОС? Меняется ли его размер? От чего зависит? Что происходит если в стеке насоздавать переменных и стек подойдёт к концу?

Меня беспокоит этот вопрос в всвязи с тем что я активно в программах стараюсь использовать стек а не кучу, так как стек работает очень быстро.

>syscall - это всего лишь обертка для int $80h реализованная в glibc

sysenter/sysexit - интелевский сисвызов syscall/sysret - амделовский

> Простой пример V[0:N-1] = 0.; На некоторых архитектурах ассемблерная версия даёт выигрыш в 3 раза.

Всего в три раза, а не в N раз и даже не в lnN раз. Окупят ли эти жалкие «три раза», то количество усилий которые потребуются на 1) написание более сложного кода на языке ассемблера, 2) устранение ошибок, 3)перенос на другие платформы, 4) сопровождение.

Итого: сложность увеличивается в N^4, а производительность только в 3.

> Окупят ли эти жалкие «три раза»

Окупят, не беспокойтесь. При условии, что BLAS и Sparse BLAS всех трех уровней на ассемблере под конкретное железо разрабатывает разработчик конкретного железа, а интерфейс одинаков всюду. man ACML и man IMKL. Самому BLAS писать - это примерно то же, что компилятор разрабатывать или паравоз угнать: сложно, достойно и практически бесполезно.

Хорошая книга, во время лабораторных по ассемблеру помогла.

> загрузчик без ассемблера не сделаешь
Загрузчик - это сраные 446 байт. Его можно и в машинных кодах написать.

> есть ещё всякие мини-девайсы, куда линукс не запихнёшь
Ключевое слово `еще'. Когда ты напишеше на ассемблере что-то полезное, они уже сгниют. Даже под AVR уже давно на C пишут.

Эх, даже аргументов не можете нормальных привести, а ассемблер действительно нужен, но только после реализации на ЯВУ, ибо сначала кроссплатформенность, а потом производительность.

Микродевайсы с хардварным ускорением java уже давно появились. Asm нужен разве что для программирования классики вроде Zilog Z80, но там уже давно ничего сложнее часов или музыкальной открытки не пишут.

> Абсолютно согласен. В абсолютном большинстве случаев ассемблер - это ассемблерные вставки в С, а не польностью на ассемблере message box в gui выкидывать

Согласен, не хватало ещё писать GUI проги на ассемблере

> Окупят ли эти жалкие «три раза», то количество усилий которые потребуются на [поскипано] Итого: сложность увеличивается в N^4, а производительность только в 3.

Какой занятный сферический конь в вакууме у вас получился...

А теперь представьте, что ваша программа работает на кластере из 1000 компьютеров, стоимостью 500 долларов каждый. Производительности не хватает. И перед вами выбор: прикупить еще 200-300 компьютеров, найти для них помещение, обеспечить администрирование, или же выгадать недостающие 20-30% процентов производительности за счет оптимизаций. Вопрос на 100 тыс долларов (стоимость 200 компов): окупят себя "эти жалкие три раза"?

Другая ситауция: ваша программа управляет автономной железкой. И не успевает вовремя реагировать на события внешнего мира. Выбор - ставить более быстрый процессор, который значительно быстрее посадит батарейки, или же заняться оптимизацией.

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

Гораздо раньше придется читать ассемблерные листинги, которые выдает компилятор. С тем, чтобы понять - справился он с оптимизацией, или нет? Если нет, переиначивать Си-шный код так, чтобы оптимизатору оказалось по зубам. А для адекватной оценки листингов желательна некоторая практика программирования на асм-е. Вернулись к тому, с чего начинали :)

> Ключевое слово `еще'. Когда ты напишеше на ассемблере что-то полезное, они уже сгниют. Даже под AVR уже давно на C пишут.

Пишут на Си. Затем обнаруживают, что в одной небольшой процедуре программа проводит 80% своего времени. Иногда бывает смысл переписать эту процедуру на асм-е.

> Всего в три раза, а не в N раз и даже не в lnN раз.

Вопросов больше не имею. Человек, который "ускоряет BLAS в N раз" видимо не очень знает, что это такое.

Вы собираетесь, скажем V = V + a W считать со скоростью 2 операций для любого N?

кто бы Си меня научил бы