Актуален ли ассемблер на сегодняшний день?

Question

[Тимофей]

Актуален ли ассемблер на сегодняшний день? в каких областях он применим?

Answer 1

[mayton2019]

Ассемблер полезен при анализе прошивок на безопасность.
При изучении того как работает софт без исходного кода (обратный инжинеринг)
и при решении задач интеграции разных слоёв софта.

Ассемблер также очень близко стоит к разработке компилляторов. И если у вас нет
соотвествующих знаний то строить свой компиллятор вы не сможете. Или вам нужно
будет изучать готовые back-ends, virtual-machines.

Ассемблер помогает при анализе узких мест в коде. В частности например
векторизация вычислений ставит в первую очередь вопросы на которые ассемблер
отвечает а ЯВУ - нет.

Знания ассемблера помогают сделать бинарник компактнее. Это важно при разработке
встраиваемых систем.

Answer 2

[Steel_Balls]

Да, актуален.
Он применим во всех областях.
Почитай что такое ассемблер и вопросы отпадут сами собой

Answer 3

[rPman]

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

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

Области - реверсинженеринг, низкоуровневая оптимизация и низкоуровневая отладка unmanaged кода (т.е. к примеру c,c++). Все это можно встретить и в разработке для микроконтроллеров, и в оптимизации кода для gpu и поиске причины, почему простой цикл кратно работает медленнее из-за вот этой 'безобидной строчки'.

Но повторюсь, без ассемблера живется неплохо.

Comments

[WbICHA]

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

Имхо, сомнительное утверждение. Это что за проблемы могут быть, что нужно лезть настолько вниз? Да и куда вниз, если банально своего кода сотни строк, так ещё и библиотек куча.

[Василий Банников]

WbICHA, например если нарвался на баг компилятора.
Без знания ассемблера даже не поймёшь, что это именно баг

[WbICHA]

Василий Банников, ну хорошо, а насколько реально отследить такой баг в ассембли? И почему без его знания не поймёшь, что это баг?
Просто, честно говоря, слабо себе это представляю, т.к. серьёзно на компилируемых языках никогда не писал. Да и среди актуальных их, вроде, почти и нет (сходу только с/с++ скажу), джавоподобные и шарпоподобные, насколько помню в джава байткод и шарп байткод транспилируются, а уже он интерпритируется, то есть там знания ассембли тоже не особо актуально.
В чём я ошибаюсь?

[Сергей Горностаев]

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

[Дмитрий Беляев]

WbICHA, я Вас удивлю, но даже для JS можно из v8 выхлоп JIT достать, и это бывает крайне полезно в узких местах.

Да и среди актуальных их, вроде, почти и нет (сходу только с/с++ скажу)

Rust и Go очень даже актуальны

[jcmvbkbc]

Это что за проблемы могут быть, что нужно лезть настолько вниз?

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

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

Если задаться целью -- на 100% реально. Вот тут я рассказываю о своём just-for-fun проекте, частью которого была доработка тулчейна -- компилятора, ассемблера, линковщика и библиотеки C.

[Василий Банников]

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

И с этой информацией катаешь хороший баг-репорт.

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

А ведь иногда, хоть и совсем редко, проблема может быть в железе)

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

джавоподобные и шарпоподобные, насколько помню в джава байткод и шарп байткод транспилируются, а уже он интерпритируется, то есть там знания ассембли тоже не особо актуально.
В чём я ошибаюсь?

У них обоих есть jit и есть способы попросить его выдать листинг после всех оптимизаций.

[WbICHA]

Сергей Горностаев, да, но жит всё же не ассембли.) Но да, звучит логично.

Дмитрий Беляев,

я Вас удивлю, но даже для JS можно из v8 выхлоп JIT достать

Да нет, не удивите, я это ещё в универе делал.)

Rust и Go очень даже актуальны

Да, точно, забыл про них.

jcmvbkbc,

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

Так это разработчики компиляторов, то есть исключения.) Мы тут всё же о большей части разработчиков говорим.

В любом случае, всем спасибо за инфу.

[Сергей Горностаев]

WbICHA, самый натуральный

# {method} {0x000000000ac640f8} 'add' '(Ljava/lang/Object;)Z' in 'java/util/ArrayList'
  # this:     rdx:rdx   = 'java/util/ArrayList'
  # parm0:    r8:r8     = 'java/lang/Object'
  #           [sp+0x40]  (sp of caller)
  0x0000000002d2a760: mov    r10d,DWORD PTR [rdx+0x8]
  0x0000000002d2a764: shl    r10,0x3
  0x0000000002d2a768: cmp    rax,r10
  0x0000000002d2a76b: jne    0x0000000002cf5f60  ;   {runtime_call}
  0x0000000002d2a771: data32 xchg ax,ax
  0x0000000002d2a774: nop    DWORD PTR [rax+rax*1+0x0]
  0x0000000002d2a77c: data32 data32 xchg ax,ax
[Verified Entry Point]
  0x0000000002d2a780: mov    DWORD PTR [rsp-0x6000],eax
  0x0000000002d2a787: push   rbp
  0x0000000002d2a788: sub    rsp,0x30           ;*synchronization entry
                                                ; - java.util.ArrayList::add@-1 (line 458)

  0x0000000002d2a78c: mov    QWORD PTR [rsp+0x8],r8
  0x0000000002d2a791: mov    rbp,rdx
  0x0000000002d2a794: mov    r9d,DWORD PTR [rdx+0x10]  ;*getfield size
                                                ; - java.util.ArrayList::add@2 (line 458)

  0x0000000002d2a798: mov    r11d,DWORD PTR [rdx+0x14]
                                                ;*getfield elementData
                                                ; - java.util.ArrayList::ensureCapacityInternal@1 (line 223)
                                                ; - java.util.ArrayList::add@7 (line 458)

  0x0000000002d2a79c: mov    r8d,r9d
  0x0000000002d2a79f: inc    r8d                ;*iadd
                                                ; - java.util.ArrayList::add@6 (line 458)

  0x0000000002d2a7a2: cmp    r11d,0xd5d0e088    ;   {oop(a 'java/lang/Object'[0] )}
  0x0000000002d2a7a9: je     0x0000000002d2a861  ;*if_acmpne
                                                ; - java.util.ArrayList::ensureCapacityInternal@7 (line 223)
                                                ; - java.util.ArrayList::add@7 (line 458)

  0x0000000002d2a7af: inc    DWORD PTR [rdx+0xc]  ;*putfield modCount
                                                ; - java.util.ArrayList::ensureExplicitCapacity@7 (line 231)
                                                ; - java.util.ArrayList::ensureCapacityInternal@19 (line 227)
                                                ; - java.util.ArrayList::add@7 (line 458)

  0x0000000002d2a7b2: mov    r10d,DWORD PTR [r11+0xc]  ; implicit exception: dispatches to 0x0000000002d2a881
  0x0000000002d2a7b6: mov    ebx,r9d
  0x0000000002d2a7b9: sub    ebx,r10d
  0x0000000002d2a7bc: inc    ebx
  0x0000000002d2a7be: test   ebx,ebx
  0x0000000002d2a7c0: jg     0x0000000002d2a80e  ;*ifle
                                                ; - java.util.ArrayList::ensureExplicitCapacity@17 (line 234)
                                                ; - java.util.ArrayList::ensureCapacityInternal@19 (line 227)
                                                ; - java.util.ArrayList::add@7 (line 458)

  0x0000000002d2a7c2: mov    DWORD PTR [rdx+0x10],r8d  ;*return
                                                ; - java.util.ArrayList::ensureExplicitCapacity@25 (line 236)
                                                ; - java.util.ArrayList::ensureCapacityInternal@19 (line 227)
                                                ; - java.util.ArrayList::add@7 (line 458)

  0x0000000002d2a7c6: mov    r10d,DWORD PTR [r11+0xc]
  0x0000000002d2a7ca: cmp    r9d,r10d
  0x0000000002d2a7cd: jae    0x0000000002d2a839
  0x0000000002d2a7cf: mov    r10d,DWORD PTR [r11+0x8]
  0x0000000002d2a7d3: cmp    r10d,0x200022ee    ;   {metadata('java/lang/Object'[])}
  0x0000000002d2a7da: jne    0x0000000002d2a84d  ;*aastore
                                                ; - java.util.ArrayList::add@26 (line 459)

  0x0000000002d2a7dc: mov    r10,r11            ;*getfield elementData
                                                ; - java.util.ArrayList::add@11 (line 459)

  0x0000000002d2a7df: lea    r10,[r11+r9*4+0x10]
  0x0000000002d2a7e4: mov    r11,QWORD PTR [rsp+0x8]
  0x0000000002d2a7e9: mov    r8,r11
  0x0000000002d2a7ec: mov    DWORD PTR [r10],r8d
  0x0000000002d2a7ef: shr    r10,0x9
  0x0000000002d2a7f3: mov    eax,0x1
  0x0000000002d2a7f8: mov    r11d,0x5965000
  0x0000000002d2a7fe: mov    BYTE PTR [r11+r10*1],r12b
                                                ;*synchronization entry
                                                ; - java.util.ArrayList::add@-1 (line 458)

  0x0000000002d2a802: add    rsp,0x30
  0x0000000002d2a806: pop    rbp
  0x0000000002d2a807: test   DWORD PTR [rip+0xfffffffffe5857f3],eax        # 0x00000000012b0000
                                                ;   {poll_return}
  0x0000000002d2a80d: ret                       ;*synchronization entry
                                                ; - java.util.ArrayList::ensureExplicitCapacity@-1 (line 231)
                                                ; - java.util.ArrayList::ensureCapacityInternal@19 (line 227)
                                                ; - java.util.ArrayList::add@7 (line 458)

Answer 4

[PhpDesignGuru]

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

Области, навскидку, где можно использовать ассемблер:

• Системное программирование (драйверы и тп)
  
• Оптимизация производительности
  
• Разработка встроенных систем и микроконтроллеров
  
• Обратная инженерия и безопасность
  

Answer 5

[psiklop]

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

Answer 6

[Freeman]

Применим в KolibriOS.

Comments

[Denis]

Еще бы понять, где применима сама KolibriOS... Для embedded никто не станет брать x86 архитектуру, а на полноценных компьютерах с многоядерными процессорами и 8/16/32 GB памяти она не нужна пользователям. В Linux хотя бы есть видеодрайвера, тонны различного софта, а здесь какие фичи?

Answer 7

[Bublikroy]

Если коротко, то НЕТ - не актуален!
Область его применения крайне узка и специфична, а писать на нем очень трудозатратно.
Сейчас, как и всегда, "бизнесу" важны сжатые сроки ввода кода в эксплуатацию, что с ассемблером не достижимо, да и не нужно (исключения драйвера, встройка и т.д.).

Comments

[Denis]

Актуален, но для специального железа. На x86 и драйвера, и ядра массовых ОС пишутся на C/C++. Ассемблер там совершенно не нужен. Разве что пиратам для взлома лицензионного софта.

Answer 8

[Руслан .]

Недавно решали задачу, как пофиксить ошибку производительности в одном старом легаси без исходников. В итоге выяснилось, что менеджер памяти в одной dll иногда тормозит при выделении блоков. Пришлось патчить эту dll-ку, через установку хуков на вызовы внутреннего менеджера памяти, чтобы подменить его на другой более шустрый. Раскопать это все без хотя бы базового asm, врядли бы вышло.
А нужно это было бизнесу, т.к. переход на более свежую версию и перетестирование всего на регресс было сильно затратнее, чем локально пропатчить dll.

Answer 9

[Denis]

Ассемблер, конечно, актуален. Есть микроконтроллеры, на которых нельзя использовать C (и тем более C++) из-за слабого железа. Ассемблер для x86 (16-битный реальный режим DOS и 32-битный защищенный Windows) - НЕТ, неактуален. Авторы, пишущие статьи по нему (точнее, копипастящие Iczelion'а и Зубкова) - занимаются спамом, а их читатели - бесполезной тратой времени. Вот, к примеру, такое - полный маразм и шизофрения сродне TempleOS.