Assembler. С чего начать?

maisvendoo	# 8 лет, 7 месяцев назад
Темы: 68 Сообщения: 1142 Участник с: 10 октября 2012	RAMZAY с++ Плюсы не стал бы причислять к атрибутам хакеров - классический C ближе, имхо, вместе в юниксвей и K&R ) Да пребудет с нами Сила...! CPU Intel Core i9 10900-KF/RAM DDR4 128 Gb/NVidia GForce GTX 1080 Ti Turbo 11Gb/SSD M2 512 Gb/HDD Seagate SATA3 2 Tb/HDD Toshiba 3Tb/HDD Toshiba 6Tb http://rusrailsim.org

# 8 лет, 7 месяцев назад

Сообщения: 1142

Участник с: 10 октября 2012

RAMZAY
с++

Плюсы не стал бы причислять к атрибутам хакеров - классический C ближе, имхо, вместе в юниксвей и K&R )

Да пребудет с нами Сила...!
CPU Intel Core i9 10900-KF/RAM DDR4 128 Gb/NVidia GForce GTX 1080 Ti Turbo 11Gb/SSD M2 512 Gb/HDD Seagate SATA3 2 Tb/HDD Toshiba 3Tb/HDD Toshiba 6Tb
http://rusrailsim.org

RAMZAY	# 8 лет, 7 месяцев назад
Темы: 43 Сообщения: 448 Участник с: 21 мая 2011	Не пинайте сильно,решил настроить IDE для nasm'а . Друг посоветовал geany(ибо он сам в ней писал на nasm'е) Дефолтный белый вид почти без подсветки очень плохо вписывался в мои чёрные кеды. Вообще мне нравится подсветка в nano,начал думать,гуглить,ничего толкового не нагуглил,но нагуглил на блог lampslave'а c его настройкой темы для веб разработки , откуда понял,что надо брать дело в свои руки. Выбрал тёмную тему oblivion 2(темы любезно идут с geany вместе,лежат в /usr/share/geany/colorschemes/),далее решил разобраться с подсветкой синтаксиса,всё было очень просто: в файле /usr/share/geany/filetypes.asm не были указаны инструкции , регистры и директивы для подсветки,дописал,всё стало красиво. Вот скриншот: filetypes.asm oblivion2.conf

RAMZAY

# 8 лет, 7 месяцев назад

Темы: 43

Сообщения: 448

Участник с: 21 мая 2011

Не пинайте сильно,решил настроить IDE для nasm'а . Друг посоветовал geany(ибо он сам в ней писал на nasm'е) Дефолтный белый вид почти без подсветки очень плохо вписывался в мои чёрные кеды. Вообще мне нравится подсветка в nano,начал думать,гуглить,ничего толкового не нагуглил,но нагуглил на блог lampslave'а c его настройкой темы для веб разработки , откуда понял,что надо брать дело в свои руки. Выбрал тёмную тему oblivion 2(темы любезно идут с geany вместе,лежат в /usr/share/geany/colorschemes/),далее решил разобраться с подсветкой синтаксиса,всё было очень просто: в файле /usr/share/geany/filetypes.asm не были указаны инструкции , регистры и директивы для подсветки,дописал,всё стало красиво. Вот скриншот:

filetypes.asm
oblivion2.conf

Aivar	# 8 лет, 7 месяцев назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	Я бы в цикле убрал лишнее сравнение: LD A,5 AGAIN ; любимые_сердцу_макросы DEC A JR NZ, AGAIN Или еще проще: LD B,5 AGAIN ; BLA_BLA_BLA DJNZ, AGAIN )

RAMZAY	# 8 лет, 7 месяцев назад
Темы: 43 Сообщения: 448 Участник с: 21 мая 2011	Aivar Я бы в цикле убрал лишнее сравнение: LD A,5 AGAIN ; любимые_сердцу_макросы DEC A JR NZ, AGAIN Или еще проще: LD B,5 AGAIN ; BLA_BLA_BLA DJNZ, AGAIN ) яж по книге учу,это пример от туда =)

akorop	# 8 лет, 7 месяцев назад
Темы: 111 Сообщения: 1755 Участник с: 29 февраля 2012	Natrio akorop, вы настолько упорны в отстаивании ваших радикальных убеждений вида "Ассемблер – ЗЛО", что хватаетесь за самые сомнительные доводы вместо доказательств, при этом требуете доказательств от оппонентов :) На что вы рассчитывали утверждая, что LAME без использования MMX/SSE догоняет сам себя с MMX/SSE? Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора? Я провёл измерение, сообщил его методику и результаты. Если это не доказательство, то что тогда доказательство? И при чём тут вера? - проверьте! Natrio Когда я несколько лет назад устанавливал дистрибутивы, где LAME был собран БЕЗ ассемблера, а потом пересобирал его с ассемблером, производительность кодека на тогдашних процессорах возрастала примерно в два раза. С тех пор LAME не сильно изменился, он вообще довольно старинный кодек, как и формат MP3. Неужели вы верите, что столько ассемблерного кода в нём было написано для красоты, когда в нём уже был обычный код не хуже? Ваш пример показывает только то, что при выключенном ассемблере (кстати, его выключение в LAME не требует пересборки), была использована внешняя математика, в которой со времён создания LAME ТОЖЕ появились ассемблерные процедуры, задействующие векторные инструкции процессора. Одно из положений, который я высказывал, - что полезность ассемблера неуклонно уменьшается. Возможно, на давних процессорах и давних компиляторах ассемблер давал в lame ощутимую пользу. Сегодня - не даёт. Более того, когда я пересобрал lame без ассесмблера, но с оптимизацией под свой процессор (Athlon II), он стал работать быстрее, чем с ассемблерными подпрограммами. Только пожалуйста, не надо про веру, мы ж не теологи. Natrio А теперь отложим в сторону старый добрый LAME, и возьмём куда более современный x264. Вы ведь его не тестили, да? .... Итого, ассемблерные вставки в x264 дают, оказывается, при кодировании данного ролика с данными параметрами на данном процессоре ускорение в три раза. (Я думал, будет меньше:) Проверил, подтверждаю. У меня разница ещё больше. И оптмизация под процессор ничего ощутимого не даёт. Это хороший пример целесообразности ассемблерных подпрограмм. Но очень специфический. Вполне определённый класс вычислений плюс команды процессора, заточенные именно под этот класс. Да, такое бывает. Но очень редко. Среднестатистическому программисту за оставшуюся жизнь может и не встретиться. Теперь о зле. Ассемблер - зло для работодателя, поскольку ассемблерная программа обходится радикально дороже, чем аналогичная на ЯВУ. Особенно с учётом сопровождения. Это очевидно. Иногда с этим злом приходится мириться, но это каждый раз нуждается в серьёзном обосновании. Но ассемблер - зло ещё и для начинающего программиста, что менее очевидно. Освоение ассемблера ничего не даёт, кроме освоения ассемблера, не востребованного сегодняшней практикой. Лучше бы начинающий написал по паре программ средней сложности на Лиспе, Форте и Питоне - это принесёт пользу для развития программистского мышления, даже если потом он всю жизнь будет кодить на Си. А освоение ассемблера - зря потраченное время.

akorop

# 8 лет, 7 месяцев назад

Темы: 111

Сообщения: 1755

Участник с: 29 февраля 2012

Natrio
akorop, вы настолько упорны в отстаивании ваших радикальных убеждений вида "Ассемблер – ЗЛО", что хватаетесь за самые сомнительные доводы вместо доказательств, при этом требуете доказательств от оппонентов :)
На что вы рассчитывали утверждая, что LAME без использования MMX/SSE догоняет сам себя с MMX/SSE? Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора?

Я провёл измерение, сообщил его методику и результаты. Если это не доказательство, то что тогда доказательство? И при чём тут вера? - проверьте!

Natrio
Когда я несколько лет назад устанавливал дистрибутивы, где LAME был собран БЕЗ ассемблера, а потом пересобирал его с ассемблером, производительность кодека на тогдашних процессорах возрастала примерно в два раза. С тех пор LAME не сильно изменился, он вообще довольно старинный кодек, как и формат MP3. Неужели вы верите, что столько ассемблерного кода в нём было написано для красоты, когда в нём уже был обычный код не хуже? Ваш пример показывает только то, что при выключенном ассемблере (кстати, его выключение в LAME не требует пересборки), была использована внешняя математика, в которой со времён создания LAME ТОЖЕ появились ассемблерные процедуры, задействующие векторные инструкции процессора.

Одно из положений, который я высказывал, - что полезность ассемблера неуклонно уменьшается. Возможно, на давних процессорах и давних компиляторах ассемблер давал в lame ощутимую пользу. Сегодня - не даёт. Более того, когда я пересобрал lame без ассесмблера, но с оптимизацией под свой процессор (Athlon II), он стал работать быстрее, чем с ассемблерными подпрограммами. Только пожалуйста, не надо про веру, мы ж не теологи.

Natrio
А теперь отложим в сторону старый добрый LAME, и возьмём куда более современный x264. Вы ведь его не тестили, да?
....
Итого, ассемблерные вставки в x264 дают, оказывается, при кодировании данного ролика с данными параметрами на данном процессоре ускорение в три раза. (Я думал, будет меньше:)

Проверил, подтверждаю. У меня разница ещё больше. И оптмизация под процессор ничего ощутимого не даёт. Это хороший пример целесообразности ассемблерных подпрограмм. Но очень специфический. Вполне определённый класс вычислений плюс команды процессора, заточенные именно под этот класс. Да, такое бывает. Но очень редко. Среднестатистическому программисту за оставшуюся жизнь может и не встретиться.

Теперь о зле.
Ассемблер - зло для работодателя, поскольку ассемблерная программа обходится радикально дороже, чем аналогичная на ЯВУ. Особенно с учётом сопровождения. Это очевидно. Иногда с этим злом приходится мириться, но это каждый раз нуждается в серьёзном обосновании.
Но ассемблер - зло ещё и для начинающего программиста, что менее очевидно. Освоение ассемблера ничего не даёт, кроме освоения ассемблера, не востребованного сегодняшней практикой. Лучше бы начинающий написал по паре программ средней сложности на Лиспе, Форте и Питоне - это принесёт пользу для развития программистского мышления, даже если потом он всю жизнь будет кодить на Си. А освоение ассемблера - зря потраченное время.

Aivar	# 8 лет, 7 месяцев назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	RAMZAY яж по книге учу,это пример от туда Тогда понятно. Но в случае с ассемблером, впрочем, как и с любым другим языком программирования, теория без практики ничего не стоит. Я просто привел простейший пример оптимизации кода. Грубо говоря, по сравнению вашей книгой, в первом случае я сэкономил в цикле 2 байта и 7 тактов процессора, во втором - 3 байта и 10 тактов процессора. Грубо говоря, потому что это касается системы команд Z80. Но важен сам принцип. )

Aivar

# 8 лет, 7 месяцев назад

Темы: 4

Сообщения: 6897

Участник с: 17 февраля 2011

RAMZAY
яж по книге учу,это пример от туда

Тогда понятно. Но в случае с ассемблером, впрочем, как и с любым другим языком программирования, теория без практики ничего не стоит. Я просто привел простейший пример оптимизации кода. Грубо говоря, по сравнению вашей книгой, в первом случае я сэкономил в цикле 2 байта и 7 тактов процессора, во втором - 3 байта и 10 тактов процессора. Грубо говоря, потому что это касается системы команд Z80. Но важен сам принцип. )

Aivar	# 8 лет, 7 месяцев назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	akorop, ну чего вы так уперлись? Если человек хочет знать Ассемблер, значит ему это нужно? akorop Освоение ассемблера ничего не даёт, кроме освоения ассемблера Где-то я уже это слышал, только там было "освоение Линукса ничего не дает, кроме знания Линукса". akorop Лучше бы начинающий написал по паре программ средней сложности на Лиспе, Форте и Питоне - это принесёт пользу для развития программистского мышления, даже если потом он всю жизнь будет кодить на Си. А освоение ассемблера - зря потраченное время. Не соглашусь в корне. Пару раз начинал почитывать what is it Си - не мое, не лезет в голову. В Ассемблере в некотором смысле проще: требуется знать внутреннюю архитектуру и систему команд микропроцессора, железо с портами ввода-вывода, адресным пространством, системой прерываний... В результате - полная свобода действий и никакой зависимости от прихотей разработчика языка высокого уровня, а если речь не идет о системном программировании, то и от системы. Где-то не сложилось у вас с Ассемблером.

Aivar

# 8 лет, 7 месяцев назад

Темы: 4

Сообщения: 6897

Участник с: 17 февраля 2011

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

akorop
Освоение ассемблера ничего не даёт, кроме освоения ассемблера

Где-то я уже это слышал, только там было "освоение Линукса ничего не дает, кроме знания Линукса".

akorop
Лучше бы начинающий написал по паре программ средней сложности на Лиспе, Форте и Питоне - это принесёт пользу для развития программистского мышления, даже если потом он всю жизнь будет кодить на Си. А освоение ассемблера - зря потраченное время.

Не соглашусь в корне. Пару раз начинал почитывать what is it Си - не мое, не лезет в голову. В Ассемблере в некотором смысле проще: требуется знать внутреннюю архитектуру и систему команд микропроцессора, железо с портами ввода-вывода, адресным пространством, системой прерываний... В результате - полная свобода действий и никакой зависимости от прихотей разработчика языка высокого уровня, а если речь не идет о системном программировании, то и от системы.
Где-то не сложилось у вас с Ассемблером.

akorop	# 8 лет, 7 месяцев назад
Темы: 111 Сообщения: 1755 Участник с: 29 февраля 2012	Aivar Пару раз начинал почитывать what is it Си - не мое, не лезет в голову. В Ассемблере в некотором смысле проще: требуется знать внутреннюю архитектуру и систему команд микропроцессора, железо с портами ввода-вывода, адресным пространством, системой прерываний... В результате - полная свобода действий и никакой зависимости от прихотей разработчика языка высокого уровня, а если речь не идет о системном программировании, то и от системы. Если программирование - это хобби, то я рад за Вас. А если работа, то я восхищён Вашим умением развести заказчика на деньги. (К слову. Если хочется настоящей свободы - для этого есть Форт.) Aivar Где-то не сложилось у вас с Ассемблером. Угу. Я немало программ на нём написал и сопровождал (в том числе, чужих). И пару безосновательно и скверно написанных ассемблерных программ переписал на Си - так быстрее, чем разгребать дерьмо, которое там было наваляно. В общем, знаком с ассемблером достаточно, чтобы избавиться от иллюзий.

akorop

# 8 лет, 7 месяцев назад

Темы: 111

Сообщения: 1755

Участник с: 29 февраля 2012

Aivar
Пару раз начинал почитывать what is it Си - не мое, не лезет в голову. В Ассемблере в некотором смысле проще: требуется знать внутреннюю архитектуру и систему команд микропроцессора, железо с портами ввода-вывода, адресным пространством, системой прерываний... В результате - полная свобода действий и никакой зависимости от прихотей разработчика языка высокого уровня, а если речь не идет о системном программировании, то и от системы.

Если программирование - это хобби, то я рад за Вас. А если работа, то я восхищён Вашим умением развести заказчика на деньги. (К слову. Если хочется настоящей свободы - для этого есть Форт.)

Aivar
Где-то не сложилось у вас с Ассемблером.

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

Natrio	# 8 лет, 7 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	akorop, это всё лишь примеры, а НЕ доказательства. Пример, сам по себе, НИЧЕГО не доказывает. Это элементарная логика. Чтобы найти ДОКАЗАТЕЛЬСТВА вашего утверждения даже в конкретном примере LAME MP3, нужно либо проанализировать его вычислительный код в варианте на Си, найти все использованные в нём внешние функции, и убедиться в том, что в них нет ассемблера, либо оттрассировать кодек в процессе работы, с проверкой на использование векторных инструкций. Что же касается ваших убеждений в том, что "ассемблер - зло", то они явно эмоциональны, в них больше злости, чем логики. Более того, они слишком радикальны, чтобы быть правдой. Радикальные суждения вообще очень легко опровергаются именно в силу своей радикальности. Вы наверняка знаете о том, что языки Си и Си++ являются небезопасными при адресации памяти. Это значит, что для безопасного программирования на этих языках, требуется знать, во что превращается код после трансляции, и как он должен работать, чтобы не создать огромную дыру в безопасности. Я видел код, написанный людьми, не понимающими, как работает процессор - это было очень забавное и поучительное зрелище. Я общался с товарищем, который пытался программировать вычислительные операции над числами повышенной разрядности в строковом(!) десятичном(!) представлении. Пришлось объяснить, как на самом деле считает процессор, что такое перенос и переполнение. И вы мне хотите доказать, что начинающему программисту совсем не нужно знакомиться с процессорами, что ему совсем незачем знать, что такое стэк, и что он может переполниться, а то не дай бог, "перейдёт на тёмную сторону силы"? :)) Ну и наконец, вы сами упомянули контроллеры, которые бывают разной степени сложности, и для многих из которых программировать иначе чем на ассемблере не получится, просто в силу ограниченности встроенных ресурсов. Надеюсь, вы не будете утверждать, что программирование ПЛИСов совсем нет спроса?

Natrio

# 8 лет, 7 месяцев назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

akorop, это всё лишь примеры, а НЕ доказательства. Пример, сам по себе, НИЧЕГО не доказывает. Это элементарная логика.

Чтобы найти ДОКАЗАТЕЛЬСТВА вашего утверждения даже в конкретном примере LAME MP3, нужно либо проанализировать его вычислительный код в варианте на Си, найти все использованные в нём внешние функции, и убедиться в том, что в них нет ассемблера, либо оттрассировать кодек в процессе работы, с проверкой на использование векторных инструкций.

Что же касается ваших убеждений в том, что "ассемблер - зло", то они явно эмоциональны, в них больше злости, чем логики.
Более того, они слишком радикальны, чтобы быть правдой. Радикальные суждения вообще очень легко опровергаются именно в силу своей радикальности.

Вы наверняка знаете о том, что языки Си и Си++ являются небезопасными при адресации памяти. Это значит, что для безопасного программирования на этих языках, требуется знать, во что превращается код после трансляции, и как он должен работать, чтобы не создать огромную дыру в безопасности.

Я видел код, написанный людьми, не понимающими, как работает процессор - это было очень забавное и поучительное зрелище.
Я общался с товарищем, который пытался программировать вычислительные операции над числами повышенной разрядности в строковом(!) десятичном(!) представлении. Пришлось объяснить, как на самом деле считает процессор, что такое перенос и переполнение.

И вы мне хотите доказать, что начинающему программисту совсем не нужно знакомиться с процессорами, что ему совсем незачем знать, что такое стэк, и что он может переполниться, а то не дай бог, "перейдёт на тёмную сторону силы"? :))

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

Natrio	# 8 лет, 7 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	P.S. На счёт оптимизации. Никакая оптимизация не может сгенерировать векторные инструкции, поэтому реальная альтернатива прямому включению в код этих инструкций с помощью ассемблера - не оптимизация, которая сводится к упрощению машинного кода на выходе, а вынос ассемблерного кода с этими инструкциями в библиотеки, если эти вычисления достаточно сандартны. По-видимому, именно это и произошло в случае с LAME, который писался много лет назад, когда такие библиотеки (а вовсе не оптимизаторы) были ещё недоступны.

Natrio

# 8 лет, 7 месяцев назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

P.S.
На счёт оптимизации.

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

По-видимому, именно это и произошло в случае с LAME, который писался много лет назад, когда такие библиотеки (а вовсе не оптимизаторы) были ещё недоступны.