Программирование на языке assembler'а в Debian

[vladimirse]

Доброго времени суток, уважаемые!
Хочу заняться изучением языка assembler, но во всех книгах ориентация идет на Dos и Windows.
В принципе, как я понял nasm чем то похож на masm и tasm, т.е. вполне можно разобраться.
Может посоветуете литературу по данной теме, для совсем зеленых и отладчик на подобие ollydbg, есть вроде edb но его нет в репах Debian.

[Olej]

Хочу заняться изучением языка assembler, но во всех книгах ориентация идет на Dos и Windows.
В принципе, как я понял nasm чем то похож на masm и tasm, т.е. вполне можно разобраться.
Может посоветуете литературу по данной теме, для совсем зеленых и отладчик на подобие ollydbg, есть вроде edb но его нет в репах Debian.

1. нет ничего проще...

2. только нужно очень сильно разобраться: нужно ли вам это (я думаю, что в подавляющем большинстве случаев - не нужно )
ответьте себе на вопрос: "зачем мне ассемблер?" - ведь С и есть такой же ассемблер, но в более читаемой записи.

3. не заморачивайте себе голову с nasm, masm, tasm etc. - в Linux реально практикуется единственный ассемблер: AT&T - GCC, все остальные - это для экзотики и ... для понтов 

4. см. сюда :
Ассемблер в Linux
Разработка модулей ядра Linux: Часть 15. Ассемблерные возможности компилятора GCC
inline assembler gcc
Инструменты Linux для Windows-программистов
возможно это позволит вам внести какую-то ясность и составить себе представление.

5. Есть книга, достаточно приличная для начального въезжания в предмет:

[vladimirse]

Именно эта книга у меня есть)))
Ассемблер мне нужен не для понтов, а что бы лучше понимать устройство цифрового мира. Я не собираюсь его применять, для решения моих задач вполне достаточна perl'а.
Большое спасибо за ответ!

[Olej]

Ассемблер мне нужен не для понтов, а что бы лучше понимать устройство цифрового мира.

Лучше - не будет 

[vladimirse]

Почему?

[Olej]

Почему?

Потому что классический С, на котором написан Linux - это и есть ассемблер ... но с более понятным синтаксисом + независимым от платформы.
А совсем уж аппартно-зависимые вещи дописываются на инлайн ассемблерных вставках, синтаксис которых существенно отличается от AT&T (не говоря уж про синтаксис Intel, который вообще к Linux слабо применим).

[vladimirse]

Спасибо за разъяснения!

[Vvasel]

gcc умеет компилировать ассемблер (на убунте точно). А язык С - сильно сомневаюсь, что, как выразился уважаемый Olej, "С - это и есть ассемблер". Попробуйте написать любую прогу на С и на ассемблер. Как минимум, эти проги будут сильно отличаться по размеру (на С проги гораздо тяжелее), и по скорости (ассемблерные проги работают с такой скоростью, насколько это возможно при данных условиях). Знать ассемблер нужно, хотябы затем, чтобы потом понимать выхлоп дизассемблера, вот основное применение знаний ассемблера. А какие вещи можно творить, хорошо зная ассемблер - уму не постижимо =) И вообще,

классический С, на котором написан Linux - это и есть ассемблер ... но с более понятным синтаксисом + независимым от платформы.

Что за ересь? Кто сказал, что ассемблер как-то зависит от платформы? Если кто не знал, на нём можно писать, вообще не привязывая ни к какой платформе (разве что аппаратной).
И напоследок, Ассемблер - наше всё! Знаешь ассемблер - ты крут, чувак! =)

[corner]

(разве что аппаратной).

Вот здесь собака и порылась! 
Вы про разные платформы говорите (Операционная система и архитектура процессора).
Да, и ассемблер для разных платформ(архитектур процессора) разный. Система команд и регистров разная...

[smallNix]

Всем доброго вечера. Очень удивлён, что никто не сказал главного: прежде чем искать книгу по ассемблеру - определись под какой процессор ты собираешься писать программу. После этого изучай архитектуру процессора. Под Интел - очень хорошая книга "Микропроцессоры Intel Архитектура, программирование и интерфейсы" (Барри Брей) В ней примеры под DOS, но это совершенно не важно, потому что ты поймёшь как программируют на асме, что это такое и как связано непосредственно с архитектурой. Потом тебе будет не сложно переехать на другой инструментарий. Если выберешь процессор PDP-11 или VAX - тут совсем другая песня (но не советую их брать - они несколько устарели), может тебе будет более интересен асм для микроконтроллеров - тогда посмотри в сторону Atmel - по крайней мере сможешь сляпать простейшего робота. И, наконец, самое вкусное - асм для ARM - но эта тема очень обширна (не полная документация на процессор может составлять около 8000 листов в pdf - придётся покарпеть )
Теперь по поводу тождественности Си и Асма. Это ересь. Полная. Конечно, все программы компилируются в бинарный код, но языки разные. Си - язык, независимый от платформы (в первую очередь от аппаратной), для того и создавался, а асм - язык полностью зависящий от архитектуры - у каждого семейства процессоров он свой. Писать на ассемблере труднее и дольше, но зато, при правильном использовании программа получается меньше и быстрее. С другой стороны, на Си (и С++, конечно) можно написать очень мощное приложение, гораздо быстрее чем на асме. Поэтому, на последнем, как правило, пишут критические (по производительности или памяти) секции кода. Или когда код должен быть завязан на выполнение какой-нибудь аппаратной функции (например надо после переключения порта ввода-вывода подождать пять циклов процессора) - тут уж без асма придётся стоять на голове

[Febian]

Знания ассемблера априори не могут быть бесполезными.

[sunny_side]

Как пример целесообразного применения ассемблера можно рассмотреть статью Ульриха Дреппера:
http://www.akkadia.org/drepper/summit09-stream.pdf
Она на английском, но его там немного - больше примеров кода с техническими подробностями.

Если просмотреть блог и домашнюю страницу автора, можно сложить впечатление о том, зачем и на каком уровне используется низкоуровневое программирование в Линуксе.
http://www.akkadia.org/drepper/
http://udrepper.livejournal.com/

Сам автор фигура в Линукс-Сообществе протеворечивая, конечно , но многие вещи освещал неплохо.

[yura_n]

Потому что классический С, на котором написан Linux - это и есть ассемблер ... но с более понятным синтаксисом + независимым от платформы.

Я думаю, что вы не совсем правы. Например, в том-же СИ, человеку с программированием незнакомому, от попыток понять как работают указатели может крышу сорвать. А человеку, который программировал на каком-нибудь ассемблере, это понять достаточно несложно, так как прямое обращение к ячейкам памяти для него не абстракция. Несмотря на большую гибкость СИ, ассемблер все-же ближе к "железу" и дает его лучшее понимание.

[seisros]

Понты.. . Нужно или не нужно. Лично я на windows изучал TASM, пробуя в linux NASM и C++ понял что разница очень большая по сравнению с ms windows.
Во первых пути везде разные что меня бесило и заставляло переходить на freebsd. Не ну как так можно? 12 разных вариантов линковок и ещё более путей где лежат эти самые библиотеки и заголовки. Для каждого дистрибутива по разному. И главное, ни где автор дистра не выкладывает где там у него это всё спрятанно. Вот зайдёш в сообщество дистра, пару лет по наблюдаеш за сообществом. Тогда всё станет ясно. А так чтобы сразу, накачал учебников и всё понял. такое по моему не реально.

[Olej]

Потому что классический С, на котором написан Linux - это и есть ассемблер ... но с более понятным синтаксисом + независимым от платформы.

Я думаю, что вы не совсем правы. Например, в том-же СИ, человеку с программированием незнакомому, от попыток понять как работают указатели может крышу сорвать. А человеку, который программировал на каком-нибудь ассемблере, это понять достаточно несложно, так как прямое обращение к ячейкам памяти для него не абстракция. Несмотря на большую гибкость СИ, ассемблер все-же ближе к "железу" и дает его лучшее понимание.

1. для ассемблера (там где он уж крайне необходим) в Linux есть такое расширение GCC как инлайновые ассемблерные вставки (они же есть и в новом компиляторе Clang, который идёт на замену GCC).

2. если посмотрите код ядра Linux, то подавляющее большинство ассемблерных фрагментов там (99.9% написаны как ассемблерные вставки ... и только 1 или 2 очень коротких файла оформлены как отдельно компилируемые файлы.

3. а на прикладном уровне в Linux с ассемблером делать нечего, и даже потраченное на его разбирательство время не пойдёт программисту в пользу...

4. за исключением случаев работы в области embedded применений и специальных процессорных архитектур (малых зачастую) ... но это очень редкий случай.