Spectator:
Это ветка соседней темы. Общая постановка вопроса: Насколько рационально сегодня знать / использовать ассемблер.
Плюс в теме имеет смысл задавать и обсуждать возникающие вопросы по ассемблеру, коли такие появятся.


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

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

Сейчас на работе у меня контроллеры все с ФАПЧ. Они тупо разгоняются. У ARM вобще 72 Мгц, куча каналов DMA, можно часть операций с памятью и периферией, как жесткую логику настроить. Все удовольствие стоит 100-200 р. Для действительно критичных ко времени выполнения операций, используется DSP ядро, преобразования Фурье, умножение с накоплением, все в железе сделано. Обращаюсь к этому через библиотечку на Сях, любезно предоставленную производителем. Ни грамма ассемблерного кода, при желании на другой контроллер переносится, переписыванием hal слоя.

Таково положение дел сегодня. Это не плохо и не хорошо. Просто надо принять это. Виртуальная машина, поверх процессора, на ней скриптовой движок и через все эти слои будем складывать a+b. [Ответ]

Сообщение от Pengvin:
Просто низкоуровневое программирование сейчас мало востребовано.

Всё верно написал, за исключением только одного момента - низкоуровневое программирование мало востребовано, это факт, и из-за причин, которые ты описал, и не в меньшей степени из-за многократно возросших объемах кода в современных программах, написать на чистом асме движок Half-Life - это лет десять бы заняло)
НО! Надо понимать ассемблерный код, и знать устройство процессора, под который ты программируешь. На случай неведомой фигни или возникновения диких тормозов там где они не предполагались. Чтобы можно было влезть с отладчиком / профайлером и разобраться - что пошло не так. Компилятор/оптимизатор перемудрил, или ты чуть-чуть не влез в критическом цикле в кэш первого / второго уровня и т.д. Для этого нужно понимать архитектуру процессора и знать ассемблер на уровне чтения (я лично его так и знаю, понять что в отладке происходит - спокойно, написать процедурку на чистом асме - с огромным скрипом и матюками с Зубковым в зубах). [Ответ]

Сообщение от Spectator:
НО! Надо понимать ассемблерный код, и знать устройство процессора, под который ты программируешь.

Надо отделить мух от котлет:
1) Устройство процессора - как часть computer science. Надо знать почти всем. Большинство современных архитектур похожи. Тем более надо знать хотя бы, что такое стек и как вызов метода происходит, даже если на .Net пишешь, чтобы не удивляться, когда при рекурсии получишь StackOverflowException.
2) ассемблер - как язык мнемоники. А нужен ли его действительно знать? Я например, имея весь скромный опыт работы и программерства, писал низкоуровневые программы под x86, 8051, AVR, PIC24, ARM (Cortex M3). И асм я знал только у первых двух архитектур (ибо похожи). Зачем мне знать весь зоопарк мнемоник и регистров состояния? Причем собственно функциональные блоки у всех процессоров похожи.
3) вот правда интересно в какой задаче, кроме спортивного программирования, понадобилось участок переписывать на асме? Или это было в бородатые годы, когда кеши были маленькие, а компьютеры большими?
Сейчас в большинстве случаев под x86 достаточно вынести тяжелые вычисления в отдельный поток и приделать прогресс бар. Или обрабатывать в несколько потоков. [Ответ]

Я с Вами обоими согласен! [Ответ]

Сообщение от Pengvin:
Надо отделить мух от котлет:
2) ассемблер - как язык мнемоники. А нужен ли его действительно знать? Я например, имея весь скромный опыт работы и программерства, писал низкоуровневые программы под x86, 8051, AVR, PIC24, ARM (Cortex M3). И асм я знал только у первых двух архитектур (ибо похожи). Зачем мне знать весь зоопарк мнемоник и регистров состояния? Причем собственно функциональные блоки у всех процессоров похожи.

В твоем случае надо знать мнемонику одного CISC процессора и одного RISC, этого будет достаточно. Если речь идет о среднестатистическом программисте под x86 то - мнемонику более-менее современного процессора + нужные расширения (MMX, SSE, SSE2 и т.д.). Причем, безусловно, не на уровне того чтобы в голой комнате без интернета и справочников под дулом пистолета налабать пару тройку экранов кода без ошибок, а так чтобы за каждой командой не лезть в справочник, а когда приходится лезть - не смотреть на написанное как баран на новые ворота.
Речь об этом.

Сообщение от Pengvin:
3) вот правда интересно в какой задаче, кроме спортивного программирования, понадобилось участок переписывать на асме? Или это было в бородатые годы, когда кеши были маленькие, а компьютеры большими?
Сейчас в большинстве случаев под x86 достаточно вынести тяжелые вычисления в отдельный поток и приделать прогресс бар. Или обрабатывать в несколько потоков.

Последний раз - генератор судоку.

Спартак, снести флуд в болталку? А то плавно но явно удалились от изначального вопроса. [Ответ]

Сообщение от Spectator:
Последний раз - генератор судоку.

интересно, виндовые саперы и пасьянсы тоже с асмом? [Ответ]

Сообщение от X0R:
интересно, виндовые саперы и пасьянсы тоже с асмом?

Сравнил задницу с пальцем.
Судоку гораздо сложнее чем саперы и пасьянсы.
http://lenta.ru/news/2012/01/09/sudoku/
Как следствие, перебор удалось свести к чуть менее чем 5,5 миллиарда вариантам (всего правильных вариантов заполнения судоку порядка 1021). Эти вычисления, которым предшествовало двухлетнее тестирование алгоритма, были проделаны на суперкомпьютере. В результате ученые установили, что 16 подсказок (или меньше) недостаточно для того, чтобы "убить" все плохие множества, поэтому придумать головоломку с таким количеством подсказок и однозначным решением невозможно.
Если непонятно - 1021 миллиард вариантов.
Прикладная задача, которую решал я - генерация судоку, она делается оптимизированным перебором, каждый вариант необходимо проверить на то что решение уникально. При определенных параметрах (количество изначально данных чисел и сложности), простейший, написанный в лоб алгоритм, будет работать сутками.
Казалось бы - при чем тут сапер?

Сообщение от Xenon:
Тему можно смело разделить на 3: ту, что задал автор; вычисление площади фигуры, ограниченной функцией и на рациональность применения ассемблера.

Асм сейчас точно выпилю в отдельную тему. Уже хотя бы потому что срачи возникают постоянно. [Ответ]

Сообщение от Pengvin:
3) вот правда интересно в какой задаче, кроме спортивного программирования, понадобилось участок переписывать на асме? Или это было в бородатые годы, когда кеши были маленькие, а компьютеры большими?
Сейчас в большинстве случаев под x86 достаточно вынести тяжелые вычисления в отдельный поток и приделать прогресс бар. Или обрабатывать в несколько потоков.

Например при вырезании некоторых функций из "чужых dll". Иногда даже Hex-Rays не всегда справляется удобоворимо, чтобы можно было вынести в свой проект и скомпилить. _asm{nop}; [Ответ]

одна сторона утверждает, что асм не нужен ввиду того, что уже есть достаточное количество библиотек; другая, напротив, утверждает его важность!!!
я за необходимость по следующим причинам:
1. это жёсткая алКоритмизация.
2. Отладка кода.
3. простота до нельзя!


внедрите опрос!!! [Ответ]

Сообщение от Dart_Sergius:
Например при вырезании некоторых функций из "чужых dll". Иногда даже Hex-Rays не всегда справляется удобоворимо, чтобы можно было вынести в свой проект и скомпилить. _asm{nop};

Подробней, пожалуйста. Я вас помню, люди, бросающиеся с ida на luajit всегда вызывают у меня некоторое подозрение.

Сообщение от Спартак21:
одна сторона утверждает, что асм не нужен ввиду того, что уже есть достаточное количество библиотек

Кто эта сторона? o_O [Ответ]

Сообщение от Спартак21:
внедрите опрос!!!

Зачем опрос? Для разных задач разные языки используются. Где-то асм рулит где-то на Яве пишут. Спорить об этом бесполезно. [Ответ]

Сообщение от silly:
Кто эта сторона? o_O

Имелось ввиду что мир программеров делится на 2 стороны)) [Ответ]

silly, а что вам именно интересно? [Ответ]

Как часто вам приходится заниматься подобным вырезанием? [Ответ]

silly, как бы сказать. Я новичёк который незнает в какую область податся, вот и занимается всякой хренью. Так ясно? Обычно не вырезаю, а делаю через dumpbin /exports и lib.exe статическую и потом офсетами, и char *... [Ответ]

Сообщение от Spectator:
Казалось бы - при чем тут сапер?

и какой был выигрыш от применения ассемблера? [Ответ]

Э… Как вот здесь http://sandsprite.com/CodeStuff/Usin..._as_a_dll.html? (Моя так не умеет, однако.) Нет, правда, где это на практике можно использовать? [Ответ]

Сообщение от X0R:
и какой был выигрыш от применения ассемблера?

В сотни раз быстрее стало. Пойми, дело не в использовании ассемблера как в таковом, а в низкоуровневой оптимизации, использовании особенностей процессора. Если у тебя внутри цикла используются только регистры и если у тебя внутри цикла постоянно дергают внешнюю к процессору память - разница будет коллосальная. Если не выходишь за рамки кэша инструкций (грубо говоря - если тело цикла без вызовов умещается в определенный объем памяти, и весьма небольшой) - это одно, если выходишь - совсем другое. Проконтролировать это на языке высокого уровня ПРОСТО НЕВОЗМОЖНО. Принципиально. [Ответ]

Насколько рационально сегодня знать asm?

Открываем hh.ru и смотрим статистику востребованности.
Некоторые пишут код бесплатно. Им рационально знать asm. Остальным - учите то, что востребовано. [Ответ]

Сообщение от Spectator:
В сотни раз быстрее стало.

прям фантастика.
А не пробовал пользоваться интеловскими компиляторами и там выбирать оптимизацию под конкретный процессор? [Ответ]

Сообщение от X0R:
прям фантастика.
А не пробовал пользоваться интеловскими компиляторами и там выбирать оптимизацию под конкретный процессор?

Ну нравится человеку на асме писать.
Пусть себе пишет, судоку генерирует.
Художника любой обидеть может) [Ответ]

>и там выбирать оптимизацию под конкретный процессор?

Что это значит? [Ответ]

Сообщение от Spectator:
В твоем случае надо знать мнемонику одного CISC процессора и одного RISC, этого будет достаточно

Не у сферических архитектур, а конкретно у AVR, PIC24, Cortex M3 (Thumb v2) отличаются мнемоники branch и data transfer, на мой взгляд неспециалиста, сильно отличаются. А компилятор в большинстве случаев "лажает" именно в этих местах. Хотя мне трудно представить, как "слажает" компилятор продуцируя код на RISC процессор, где все достаточно однозначно. с А чтобы реально понять, что он "слажал", нужно достаточно плотно погрузиться в документацию на ассемблер. А это время и денежки. А проблема может быть в другом месте. Возникали проблемы недостаточной скорости на контроллерах, проблема была не в компиляторе, а в кривых руках. Все оптимизировалось алгоритмически и получался хорошо структурированный и читабельный Си код. [Ответ]

Сообщение от asm0day:
Что это значит?

Скорее всего имелось ввиду это:
Рекомендуемые опции для конкретных процессоров [Ответ]

Сообщение от asm0day:
Что это значит?

Сообщение от Hopkroft:
Скорее всего имелось ввиду это:

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

[Ответ]

Сообщение от X0R:
прям фантастика.
А не пробовал пользоваться интеловскими компиляторами и там выбирать оптимизацию под конкретный процессор?

Предварительно я пробовал далеко не только это. И профилирование и прочее. Безусловно, начинать оптимизировать на ассемблере необходимо только тогда, когда на С++ алгоритм и код идеальны.

Сообщение от Pengvin:
Не у сферических архитектур, а конкретно у AVR, PIC24, Cortex M3 (Thumb v2) отличаются мнемоники branch и data transfer, на мой взгляд неспециалиста, сильно отличаются. А компилятор в большинстве случаев "лажает" именно в этих местах. Хотя мне трудно представить, как "слажает" компилятор продуцируя код на RISC процессор, где все достаточно однозначно. с А чтобы реально понять, что он "слажал", нужно достаточно плотно погрузиться в документацию на ассемблер. А это время и денежки. А проблема может быть в другом месте. Возникали проблемы недостаточной скорости на контроллерах, проблема была не в компиляторе, а в кривых руках. Все оптимизировалось алгоритмически и получался хорошо структурированный и читабелный Си код.

Вот. Верный подход, только КАК определить, где именно слажал компилятор и КАК убедиться что изменения в исходном Си коде позволили компилятору создать более качественный набор команд, так скажем, если ты даже поверхностно не можешь разобраться в ассемблерном листинге?
Я, допустим, в критических циклах всегда пытаюсь добиться чтобы по максимуму использовались регистры, вернее наоборот - по минимуму использовался стек. Чтобы понять что линейный (последовательный) обход массива всё же не стоит делать через индекс там, где нужна скорость, стоит посмотреть на то к каким командам это в результате приводит.
И в итоге там где можно я всегда избегаю ассемблерных вставок, поскольку отлаживать и править их - та еще "радость", где не выходит компилятор убедить чтобы он сделал по моему))), там приходится делать вставки. [Ответ]

ну так это соглашения вроде, т.е набор комманд новый в придачу к стандарту [Ответ]

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

Имеет смысл цитировать сообщения, на которые отвечаешь. Для этого используется кнопка "Цитата" под постом (сообщением), после чего оставляем необходимый минимум, чтобы было понятно на что отвечаешь и пишешь ответ. [Ответ]

В конечном счете знания АСМа в 21 веке нужны:

1) вирусы, реверс-инжиниринг

2) оптимизация тяжелой математики (веторные инструкции и прочее, что не потянул компилятор). Хотя можно кое-что и на видюхе посчитать, если решение не будет сильно тиражироваться.

3) спортивная оптимизация программ (доказывать, что человек умнее тупой машины). У меня i7 дома L1-64Kb,L2-1024Kb,L3-8192Kb. Че куда невлезет?

4) низкоуровневое программирование: драйвера, ядра ос и прочее. Хотя многое можно без асма и на Сях сделать [Ответ]

Сообщение от Pengvin:
В конечном счете знания АСМа в 21 веке нужны:

1) безусловно
2) Почему только математика? Переборные алгоритмы, шифрация/дешифрация, аудио-видео кодеки, игры и т.д.
3) Кэш - совсем не панацея. Его еще неплохо бы уметь правильно использовать для этого знание ассемблера тоже не помешает.
4) Совершенно верно, такие вещи обычно пишут на чистом C (не C++)

5) (от меня уже) Самое важное - знания АСМа нужны для того чтобы понимать как работает то что ты делаешь, и во что выльется твой код.
6) Для того чтобы эффективно оптимизировать программы как на языке высокого уровня так и непосредственно на ассемблере.
7) Исправление ошибок из ряда "это ДОЛЖНО работать, какого хрена?"

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

Я стал исследовать внутренности частовызываемых виндовых функций и с удивлением обнаружил что многие, даже очень небольшие, фунции являются заглушками (stub) для других, большая часть из которых недокументирована. В некоторых были предварительные проверки параметров, в некоторых нет. Я заменил вызовы на прямые, возможно некоторые из этих stub'были нужны для совместимости с прошыми / будущими версиями винды, но у меня проект изначально был жестко заточен на конкретную операционку.

После этого программа заработала заметно быстрее, в плане того что стала меньше грузить процессор, больше 1% не было даже на "самых крутых поворотах" (вполне реально, там даже окон не было, вся отрисовка на DirectDraw). Хотя собственно ассемблерных вставок там ЕМНИП и не было.

Таким образом добавляется еще один пункт, отдельный:

8) Реверсинжиниринг операционки с целью оптимизации программы [Ответ]