[LORрозыск] ассемблерные сайты для Linux

ну тот же wasm, там можешь спрашивать.

а так не надо ведь.

А, собственно, зачем в *NIX нужен этот ваш ассемблер?

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

В наших краях asm не особо котируется, ибо не кроссплатформенно же!

>Ну как бы ядро без него не особо пляшет

сплоиты никто не отменял

О_о *NIX !=ASM *NIX=C . Все пишется на С, все дыры закрываются на С.

то то парни из glibc всё на асме переписывают! они явно что-то не знают. а программистам под микроконтроллеры тоже на С писать? зажрались, товарищи!

>то то парни из glibc всё на асме переписывают

Пруф?

в обсуждении обновления проскакивало. когда ещё у всех на х86_64 флеш и мп3 воспроизводились с щелчками. тогда ещё сам торвальдс написал патч, временно устраняющий проблему

>то то парни из glibc всё на асме переписывают!
прям под все архитектуры?

>а программистам под микроконтроллеры тоже на С писать?

и много микроконтроллеров на которых линукс работает?

А что конкретно вам надо?

Вот с http://asm.sourceforge.net/ берите список сисколов. Дальше gas/nasm/yasm и все как обычно - команды процессора-то не поменяются.

>а программистам под микроконтроллеры тоже на С писать?

9000 лет уже весь мир на Си микроконтроллеры прогает

не пиши такого больше, я подумал что сайты на ассемблере...

9000 лет уже весь мир на Си микроконтроллеры прогает

+100500

И в программах пользователя ассемблер не нужен. Ассемблерные вставки нужны лишь в ядре (для определения всяких аппаратно-зависимых частей) и в gcc (для оптимизации под конкретный процессор - те же SSE и т.п.).

А почему бы и нет? На С сайт можно сделать. Значит, можно и на ассемблере :)

А почему бы не вылить себе трусы из чистого алюминия? И крепко и надежно

Он вообще-то смайлик поставил ;)

> И в программах пользователя ассемблер не нужен. Ассемблерные вставки нужны лишь в ядре (для определения всяких аппаратно-зависимых частей) и в gcc (для оптимизации под конкретный процессор - те же SSE и т.п.).

Не всё так просто.

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

Тем не менее, лажу компиляторы тоже бывают гонят ерунду и даже ошибки.

SSE и вообще всякие векторные SIMD инструкции оптимизируются плохо, собственно, автоматически из сишного кода они, мне кажется, вообще очень редко генерируются. Тут надо ручками прописывать.

Например, в коде ffmpeg есть ассемблерные вставки и в заметном количестве. А это отнюдь не ядро и не gcc.

Иногда трудно понять, что происходит с программой, не спустившись при отладке до ассемблера.

т.к. по-твоему в софте сии вставки не нужны?
а мужики-то не знают...

Какбэ, использовать SSE на C спокойно можно и без ассемблера (<xmmintrin.h>). Правда мне завести удалось только на icc.

>прям под все архитектуры?

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

> и в gcc

Может он компилятор пишет, кто знает.

Этого сайта и там еще одного вполне хватит, все спасибо

Лучше изучайте язык Ada. Для микроконтроллеров самое то.

Меня интересуют отнюдь не микроконтроллеры, компиляторы, ядро и прочие вещи в том же духе

Не нужны.
Сильви, помню, проводила тестирование mplayer-а (?) с и без вставок. Тот, что без вставок работал быстрее.

пруф?
ты уверен что SIMD на сях будет быстрей чем на асме?
а мужики-то не знают...

ух ты ) а я и не помню )
с mplayer я точно такое не вытворяла, с asm 386 могла сравнить векторизацию компилятором (SSE) по сравнению с ручным написанием кода на asm 386, без SSE, а в mplayer там mmx, sse используют, тут компилятору далеко.

если по теме, ориентироваться нужно не на ОС, код по возможности должен быть написан портабельно на другие платформы, т.е. это Си или С++ или что-то другое возможно,
на ассемблере стоит писать (в случае кода общего назначения, а не там где каждый байт на счету) только в том случае, если нужно оптимизировать какой-то очень нагруженный алгоритм, желательно использовать cpuid и mmx,sse/avx , все остальное желательно писать на языке более высокого уровня, так и переносимость кода на другие платформы лучше будет и возможность ( для свободных программ ) внесения изменений тоже.

в случае же железки, если пишете для x86 / x86_64 , то вполне можно пользоваться и сайтами и литературой для windows, обработчик кадра видео вполне может быть одинаковым и для windows и для любого Unix )

кстати а CGI модули на ассемблере можно писать?
и насколько бы это было оправдано на очень загруженых веб серверах?

PS: Классная аватарка, я бы вдул =)

Вобщем ошибка твоя ТС в «ориентацией на UNIX», ассемблер ориентируется на процессор. Для начала поищи Абеля «Ассемблер для и программирование для IBM PC» и П.Нортон «Ассемблер <чего-то там>». Накати qemu и поставь туда MSDOS - это тебе будет среда для работы с упражнениями. Зачем? Программирование на ассемблере как прикладная задача сформировалась именно в то время и большинство годных советов и приёмов будет работать именно там. Как освоишься, обязательно собери литературу по RISC архитектуре и замени qemu c dos, на qemu-PowerPC или qemu-SPARC с NetBSD или каким нибудь другим легковесным унихом и тут уже тебе книги не понадобятся, только тех.документация.

Вот собственно и всё. По поводу «нужен - не нужен», человеку, если взять в корень, нужно только «жрать срать спать» всё остальное он решает сам.

Возможно перепутал, да. Но такое кто-то делал. Сейчас постараюсь поискать.

я могла сравнить asm вставку в gzip с gzip без этой вставки, и сборкой с векторизацией, но уж точно не mplayer :)

в gzip - asm386, т.е. в принципе можно попробовать сравнить ручную оптимизацию для i386 с оптимизацией gcc уровня SSE2 и выше )

> Какбэ, использовать SSE на C спокойно можно и без ассемблера (<xmmintrin.h>). Правда мне завести удалось только на icc.

Зачем левой ногой чесать правое ухо? Тем более, если для XMM видимо написали сишную обертку, которая ещё и не завелась на gcc, как я понял, гораздо проще напрямую воспользоваться ассемблером. Тем более, если нужно SSE2 и т.п.

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

А так, неприятие ассемблера непонятно, можно подумать, что это ужасно сложно.

Крупных сайтов по ассемблированию в никсах ИМХО нет, зато есть хорошая литература по NASM например, от а до я так сказать, на английском языке. Ищите книги, а не сайты.

и уж если о правилах хорошего тона,
вынесенный в отдельные файлы код, теперь принято собирать с помощью yasm , ранее использовался nasm, вариант с as (GNU assembler / gas / binutils ) обычно все же не применяют

Так я просто почему сайты искал потому, что например на том же васике именно книжки собраны и прочие кашерные книжечки, ладненько пойдем по пути указанным iBlis

Лучше тогда из урана.)))

Выдроченная оптимизация.

В ведре есть код на ассемблере.

> вынесенный в отдельные файлы код, теперь принято собирать с помощью yasm , ранее использовался nasm, вариант с as (GNU assembler / gas / binutils ) обычно все же не применяют

Очень странное утверждение, можете его подкрепить фактами?

Насколько я знаю, nasm все же популярнее yasm (а еще он лучше задокументирован и фичастее). И оба поддерживают только x86(-64) так что и gas часто применяют.

вынесенный в отдельные файлы код, теперь принято собирать с помощью yasm , ранее использовался nasm, вариант с as (GNU assembler / gas / binutils ) обычно все же не применяют

в ядре например, обычно кроме ас-а ничего и не используют

это лишь моя точка зрения, в плане фич, yasm уже вполне себе ничего, документацию не сравнивала, популярность у него скорее... ну что уж накопилось, я смотрю на проекты типа ffmpeg, там ушли от nasm

@iivvaann в ядре раньше использовали bin86 (as86) , но к счастью ушли, ядро достаточно специфично, поэтому они могут позволить себе писать для gas , в то время как кроссплатформенные проекты используют yasm (ffmpeg (и соответственно mplayer)) или nasm (lame)

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

Интересно, есть ли какие-нибудь программы для конвертации ассемблерного листинга между ARM, x86, спарк и прочими? С оптимизациями. Чтобы написанная на ассемблере программа была кроссплатформенна.

> в ядре например, обычно кроме ас-а ничего и не используют

У них просто нет альтернатив. Ядро поддерживает множество архитектур, не только x86. И только GAS поддерживает архитектуры отличные от x86(-64).

> я смотрю на проекты типа ffmpeg, там ушли от nasm

AFAIK из-за того, что тогда у nasm'а были проблемы с 64-битами, а у yasm'а нет. Не знаете как у nasm с этим сейчас?

нет, не в курсе

>Интересно, есть ли какие-нибудь программы для конвертации ассемблерного листинга между ARM, x86, спарк и прочими? С оптимизациями. Чтобы написанная на ассемблере программа была кроссплатформенна.

Нет.

> у nasm'а были проблемы с 64-битами, а у yasm'а нет. Не знаете как у nasm с этим сейчас?

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