Ассемблер для начинающих

В любом деле главное — начать. Или вот еще хорошая поговорка: «Начало — половина дела». Но иногда даже не знаешь как подступиться к интересующему вопросу. В связи с тем, что воспоминания мои еще свежи, спешу поделиться своими соображениями с интересующимися.

image

Скажу сразу, что лично я ассемблирую не под PC, а под микроконтроллеры. Но это не имеет большого значения, ибо (в отличие от микроконтроллеров AVR) система команд данных микроконтроллеров с PC крайне схожа. Да и, собственно говоря, ассемблер он и в Африке ассемблер.

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

Для начала успокою любознательных новобранцев: ассемблер — это совсем не сложно, вопреки стереотипному мнению. Просто он ближе к «земле», то бишь к архитектуре. На самом деле, он очень прост, если ухватить основную идею. В отличие от языков высокого уровня и разнообразных специализированных платформ для программирования (под всем перечисленным я понимаю всякое вроде C++, MatLAB и прочих подобных штук, где требуются программерские навыки), команд тут раз-два и обчелся. По началу даже, когда мне нужно было посчитать двойной интеграл, эта задача вызывала лишь недоумение: как при помощи такого скудного количества операций можно совершить подобную процедуру? Ведь образно говоря, на ассемблере можно разве что складывать, вычитать и сдвигать числа. Но с помощью ассемблера можно совершать сколь угодно сложные операции, а код будет выходить крайне лёгкий. Вот даже для примера, нужно вам зажечь светодиод, который подключен, например, к нулевому контакту порта номер 2, вы просто пишете:
bset P2.0
И, как говорится, никаких проблем. Нужно включить сразу штуки четыре, подключенных последовательно? Да запросто:
mov P2, #000fh
Да, тут я подразумеваю, что начинающий боец уже знаком хотя бы со системами счисления. Ну хотя бы с десятичной. ;)

Итак, для достижения успеха в деле ассемблирования, следует разбираться в архитектуре (в моем случае) микроконтроллера. Это раз.

Кстати, одно из больных мест в познании архитектуры — это организация памяти. Тут на Хабре я видела соответствующую статью: habrahabr.ru/blogs/programming/128991. Еще могу упомянуть ключевые болевые точки: прерывания. Штука не сложная, но по началу (почему-то) тяжелая для восприятия.

Если перед вами стоит сложная задача и вы даже не знаете как по началу к ней подступиться, лучше всего написать алгоритм. Это воистину спасает. А по началу, даже если программа совершенно не сложная, лучше всё же начать с алгоритма, ибо этот процесс помогает разложить всё в голове по местам. Возвращаясь к примеру с вычислением двойного интеграла по экспериментальным данным, обдумывала алгоритм я весь день, но зато потом программку по нему написала всего за 20 минут. Плюс алгоритм будет полезен при дальнейшей модернизации и/или эксплуатации программы, а то ассемблерный код, временами, если и будет понятен построчно, то чтобы разобраться в чем же общая идея, придется немало потрудиться.

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

Собственно, хотелось бы как Фандорин написать: «Это т-т-три»… Но, боюсь, на этом пока можно остановиться. Хотя хотелось бы добавить еще несколько рекомендаций и пряников.

Подводя итог моему несколько сумбурному монологу, ключевые моменты в программировании на ассемблере — это знание архитектуры и связное построение мыслей. Конечно, не обязательно сразу с головой кидаться в штудировании литературы с описанием внутренностей того же PC, но общее представление (повторюсь, хотя бы для начала) будет очень нужно.

А теперь обещанные пряники! Вот я тут распинаюсь о каком-то непонятном ассемблере, а что же в нем, собственно говоря, хорошего? Да много всего! Во-первых, конечно, не нужно запоминать много команд, используемых библиотек и прочей сопутствующей дребедени. Всего парочка команд и, считайте, вы во всеоружии. Во-вторых, в связи с крайней близостью к машинным кодам, вы можете делать практически всё, что душе угодно (в отличие от тех же языков высокого уровня)! В-третьих, ассемблерный код, по причине максимальной лаконичности в формулировках, выполняется крайне быстро.

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

Комментарии 66

    +6
    Меня всегда интересовал вопрос. Неужели всякие там GCC генерируют нечто настолько неэффективное, что проще всю прошивку написать на чистом ассемблере, а не ограничиться вставками там, где надо работать с аппаратными ресурсами?
    • НЛО прилетело и опубликовало эту надпись здесь
        0
        Это ж решается банальными вставками, возможно даже в функцию без сгенерированных компилятором пролога/эпилога, нет? Я всегда считал, что такие штуки должны выделяться в HAL, а основная логика лежать парой уровней выше.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Эм. А зачем вам механизмы для логического разграничения полномочий-то?
            • НЛО прилетело и опубликовало эту надпись здесь
            +3
            Зачастую вставки не помогают, потому процедура выносится в отдельный .S-файл. Тем не менее, логика всё равно пишется на C. По крайней мере, я так делаю. А ассемблер приходится использовать часто — порою пара тактов решает всё.
          +1
          Вопрос, конечно, интересный. И я могу лишь высказать свое мнение на этот счет, но ни в коем случае не претендую на звание истины в последней инстанции.
          Так вот… Как по мне, так хороший компилятор и правильное место произрастания рук самого программиста может в совокупности составить замечательный код. Но компилятор ведь, в любом случае, добавит некоторой «отсебятины» в конечный файл. Вот самый характерный пример — системы реального времени. Там, где требуется быстродействие и присутствует ограниченность в ресурсах памяти, ассемблер (по моему глубокому убеждению) просто незаменим. При допустимо одинаковой оптимальности логического построения программы, код на ассемблере будет исполняться быстрее. А ежели вы программируете какого-нибудь военного робота, то скорость его реакции на изменяющуюся среду — это, надо отметить, не самое последнее дело.
            +4
            А как же распространённое мнение о том, что генерируемый С-компилятором код зачастую оптимальнее за счёт учёта таких штук как выравнивание команд в памяти, особенностей работы конвеера, etc? Да и С — по сути, кроссплатформенный ассемблер, предоставляющий набор человекочитаемых абстракций над базовыми примитивами кода.
              +2
              Как говорится, распространенное мнение не всегда самое верное.
              По моему мнению, компилятор — это все-таки не идеальное творение рук человеческих. Иногда случаются ошибки и в компиляторах, так что на первый взгляд правильно написанный код будет исполняться некорректно, а в таком случае, кроме как изучая во что код скомпилировался, не разберешься. А тут, собственно говоря, ассемблер и поможет.
                +3
                Оно-то верное, но проблема в том, что компилятор не может читать мысли программиста. И там, где я могу написать in sreg_save, IO(SREG), потому как я знаю, что этот регистр гарантированно здесь использоваться не будет, компилятор может, простите, нафигячить что-то вроде
                    push __zero_reg__
                    push r0
                    in r0, IO(SREG)
                    push r0
                    clr __zero_reg__
                

                Хотя далее нужды в нуле в __zero_reg__ большой может и не быть.
                  0
                  Ещё бывает, что аналогов ассемблерной команде в языке просто нет. Как пример в статье с установкой бита. На ассемблере это одна инструкция. А на C придётся считывать в переменную (а если без переменной, то всё равно будет задействован целый байтовый регистр), накладывать маску, переключать бит и записывать полученное в ячейку памяти. Типа данных «bit» и удобных операций для работы с битами в языках высокого уровня, как правило, нет.
                    +1
                    Компилятор не дурак и, как правило, видя такое применяет нужную инструкцию.
              +7
              Как по мне, ассемблер сейчас нужен не столько для того чтобы писать, сколько для того чтобы читать то что уже написали, но по какому-то странному недоразумению забыли приложить исходные коды.
              • НЛО прилетело и опубликовало эту надпись здесь
              • НЛО прилетело и опубликовало эту надпись здесь
                  +1
                  Конечно, всё так. Но в вашем комментарии упоминается лишь характеристика «качества» кода. Все-таки код, на мой взгляд, это не вино, так что кроме «качества», опять же на мой взгляд, ключевыми параметрами сравнения кода от программиста и от компилятора будут, как минимум, еще и «быстродействие», «вес». Код, с эстетической точки зрения, может быть безумно красив и понятен, но с других позиций будет уступать по каким-то иным (например, перечисленным мною выше) характеристикам. В свою очередь, программист может быть не столь утончен в «формулировках», но все-таки оптимизировать код под конкретную задачу. Тут я, конечно же, сужу с позиции ассемблирования под микроконтроллеры.
                  Стоит также отметить, что компилятор — это не дар богов, а плоды труда все тех же программистов. Тут возникает дилемма курицы и яйца. Собственно, мне кажется, что не стоит всегда перекладывать всю работу на компилятор, ибо это лишь рукотворный инструмент, который, безусловно, может быть большим подспорьем в программировании.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      +1
                      Не, как я уже говорила, всё так, конечно. Собственно, я не противоречу вашей мысли, просто хочу дополнить, так сказать, пространство событий. Моя мысль заключается в том, что, во-первых, и в компиляторе присутствуют косяки, во-вторых… Как бы это лучше выразиться. Скажем так, компилятор реализуется не на основе хотя бы даже искусственных нейронных сетей… Иными словами, широта мышления отсутствует у него. Как вы правильно отметили, если программист очень хорошего уровня, то он уже знает во что будет компилироваться его код (при условии багов в компиляторе, конечно) и, грубо говоря, может прекрасно и сам написать соответствующий ассемблерный код. Другой вопрос, что благодаря тому, что он «знает», он может «не париться» на этот счет и автоматизировать процесс составления конечной программы. А вот если программист не очень хорошо шарит во всем этом деле, то и при наличии глюков не сможет толком разобраться в чем дело, ежели что-то пойдет не так.

                      В общем, что я хочу сказать. Увольте, я не призываю народ стереть тот же Visual Studio и писать программы в машинных кодах. Программирование высокого уровня (особенно под тот же Виндовс) чрезвычайно дельная штука. Я лишь говорю о том, что во всем могут быть недостатки (как в компиляторе, так и в программисте), а знать как и что происходит, когда человек пишет программу на языке высокого уровня будет более чем полезно. Особенно при написании больших/важных/сложных программ. А большое количество программистов пренебрегают этим полезным знанием.

                      Кстати да, обращаю внимание, что статья в общем ориентирована именно на начинающих людей в этом деле.
                        0
                        Я бы от части согласился с вами, от части — нет. Всё зависит от архитектуры. Применительно к программированию МК хороший программист должен знать все её особенности, и на ассемблере в любом случае будет более оптимальный код.
                        Время — да больше, трудозатраты — так же, но и качество выше. И чем проще МК, тем сильнее этот разрыв в качестве.
                        Например на восьмибитках никогда компилятор не даст лучше кода, чем будет изначально продуманный программистом ассемблерный.
                          +3
                          Я знаю в совершенстве особенности и тонкости архитектуры. Я в состоянии на текущем этапе своего развития запомнить и активно применять мануал по процессору. Что я делаю не так? :)
                          • НЛО прилетело и опубликовало эту надпись здесь
                            +1
                            >> Он не знает в совершенстве особенностей и тонкостей архитектуры.
                            С чего бы? Значит плохой программист. Для того же х86 есть мануалы Фога, масса статей по внутренностям CPU. Авторы компиляторов работают с этими же данными.

                            >> Он не в состоянии на текущем этапе своего развития запомнить и активно применять мануал по процессору на тысячи страниц 6 кеглем шрифта.
                            Обоснуйте. Типа люди стали сейчас настолько тупые, что не могут применять мануал по процессору?
                            Я вот помню растактовки и латентности большинства инструкций и особенности пайпланов у процов с которыми плотно работал. Для этого даже не нужно писать на асме. Когда в голове есть картина какие инструкции и в какой части конвеера выполняются — это не сложно.
                            Также часто получается довольно точно определить время работы некоего кода даже ДО ТОГО как я приступил к его написанию.

                            >> Он не умеет в уме решать задачи на перебор миллионов и миллиардов вариантов.
                            Извините, но это редкостный бред. Человек — не машина. Человеку не нужно перебирать варианты. Он сразу или с нескольких попыток выберет эффективный.

                            >> У него наверняка нет таких знаний «по науке» как у целой группы разработчиков компилятора.
                            Почти вся наука уходит на то, чтобы заставить тупую машину делать ПРИМИТИВНЫЕ вещи.
                              0
                              С DSP или микроконтроллерами устоявшихся архитектур такое может быть и возможно. Но возьмем, например, x86. Вы помните наизусть особенности укладки в пайплайны всех его инструкций на всем многообразии линеек от Atom и до Core i7 и Athlon-ов? При том, что для инструкций типа умножения или квадратного корня там зачастую и в подробных мануалах от Intel/AMD не найдешь нужных сведений. Или возьмем какой-нибудь Itanium. Может ли нормальный человек удержать в голове все возможные укладки инструкций в bundles? Там даже сами ассемблеры хорошие умеют заниматься такой оптимизацией за программиста, так как считается, что даже ассемблерный программист не может все это удержать в голове. А помнит ли даже отличный программист структуру конвейеров всех существующих линеек Power[PC] процессоров от IBM и Motorola? Может быть, есть отдельные люди на всей Земле с такой феноменальной памятью и умением быстро перебирать в голове варианты. Но их действительно единицы на всей планете (единицы в прямом смысле). Остальных же программистов компилятор обгонит в 99% случаев при достаточно объемной программе. Если речь не идет о вручную проработанном внутреннем счетном цикле из 5-10 инструкций.
                                +2
                                Нельзя обьять необьятное.
                                Люди, которые пишут на асме какие-то оптимизированные вещи, разрабатывают под _конкретное устройство или семейство CPU_.
                                И нормальный компилятор тоже делает тоже самое.
                                Можно просто писать на среднем_по_больнице_асме, как в MenuetOs, например. Но это не имеет практической пользы.

                                >> Вы помните наизусть особенности укладки в пайплайны всех его инструкций на всем многообразии линеек от Atom и до Core i7 и Athlon-ов

                                В старых ООО х86 нужно было лишь правильно положить инструкции в памяти по простым правилам. В современных ещё проще. От P6 до Sandy Bridge (кроме P4) схема OoO практически одинаковыя. С той разницей что сейчас делается предекодирование, а-ля трейскеш P4.
                                Правила они не с потолка берутся — это конкретная железка, которая делает fetch-decode. Поэтому нужно примерно представлять её блок-схему.

                                >> для инструкций типа умножения или квадратного корня там зачастую и в подробных мануалах от Intel/AMD не найдешь нужных сведений
                                А что там нет такого, что хотелось бы знать?

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

                                Авто-распределение регистров и авто-скЕдулер штука очень удобная для архитектур с большими латентностями (например мой любимый SPU) У компилятора же проблемы больше с генерацией, чем с «размазыванием» инструкций по «дыркам».

                                >>А помнит ли даже отличный программист структуру конвейеров всех существующих линеек
                                Концептуально они не слишком отличаются. Просмотр схемы конвеера позволяет получить бОльшую информации. Запоминать нужно не всё, а важные и отличающиеся вещи. Если что-то не помнишь, не будет зазорным подсмотреть.

                                >>Может быть, есть отдельные люди на всей Земле с такой феноменальной памятью и умением быстро перебирать в голове варианты

                                Реально не понимаю что вы хотите доказать. Что тупой последовательный алгоритм написанный человеком «умнее» человека?
                                Человеческому мозгу НЕ НУЖНО ПЕРЕБИРАТЬ ВАРИАНТЫ.
                                Это сравни сочинению симфонии путём перебора случайных нот или написанию книги рандомными символами.

                                >>Остальных же программистов компилятор обгонит в 99% случаев при достаточно объемной программе
                                Каждый день убеждаюсь в обратном. Смотришь в результат работы GCC и плакать хочется
                                Но на асм переписывать времени нет. Тут бы тупо на SIMD перевести успеть.
                                  0
                                  Посмотрите на объемы md-файлов в проекте GCC. Например, для того же x86. Или md-файлы для любого другого семейства современных процессоров общего назначения, типа Itanium, PowerPC, MIPS или даже для более простой линейки ARM. Сами объемы говорят за себя, не говоря уже о сотнях тонкостей в описании пайплайнов, байпассов и юнитов. Посмотрите на объемы кода в самом компиляторе, который занимается scheduling-ом инструкций при генерации по этим md-файлам. Огромные объемы разных тонкостей, уловок и так далее, комбинаторики и эвристик – чтобы решить как оптимально распихать команды по конвейерам. Я убежден, что обычный человек не может все это уместить в своей голове. Есть только единичные люди, которые интуитивно чувствуют, как нужно писать, чтобы реально обгонять компиляторы (на высоких уровнях оптимизации).

                                  Если говорить именно о процессорах общего назначения – обычно код не пишется под конкретную железку. Даже если он внутреннего пользования. Ведь железо меняется каждый год, компания переходит на новые серверы и так далее. Я уж не говорю о коде для пользовательских машин. Поэтому писать большие объемы кода на ассемблере сейчас просто бессмысленно. Если нужно, чтобы этот код был лучше сгенерированного компилятором — потребуются самые лучшие программисты страны/мира, с соответствующими офигенными зарплатами. А через год их код станет неактуален из-за входа новой линейки процессоров.

                                  Поэтому сейчас ассемблер на процессорах общего назначения нужен только для вставки особых команд и оптимизации самых внутренних циклов в самых критичных ко времени приложениях на последней стадии доводки проекта, когда в целом все уже работает. Как самостоятельный язык программирования он давно утратил смысл.
                                    +1
                                    >> Посмотрите на объемы md-файлов в проекте GCC.
                                    Смотрел. Даже баги правил в кодгене под Sparc (в коде)
                                    Все эти объёмы не мешают ему генерить говнокод =) Скорее даже помогают.

                                    Например на in-order процессорах, тупым перемещением строк внутри цикла легко добится как ускорения, так и замедления (при достаточном размере цикла).
                                    На конкретном 400-тактовом внутренним цикле (на SPU) я получал +-20% перемещая небольшой блок кода. Весь цикл — чисто функциональный SSA-style код.

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

                                    >>Если говорить именно о процессорах общего назначения – обычно код не пишется под конкретную железку
                                    На PC и встройку пишут под конкретное семейство CPU (о чём я сказал). А вот на консолях пишут под конкретный проц. С практической целью, естественно.
                                    Писать на ассемблере _ради ассемблера_ сейчас не имеет практической пользы, разве что если не знаешь других языков =) «С» я изучил в ~99г. До этого 100% асм.

                                    >> Я убежден, что обычный человек не может все это уместить в своей голове
                                    Обычные российские граждане не знают языка Суахили, например.
                                    То что вы работаете на Роботов, я уже понял, но мозг может запомнить столько книг, сколько не прочитаешь и за всю жизнь. И уж запомнить инфу из нескольких TRM это вообще ничто.
                                    Это как учить иностранный язык. Вначале со словарём, а потом он вам уже так часто не нужен будет. Ну может быть подсмотреть пару слов.
                                    Да тот же английский куда сложнее чем асм =)
                                    Вобщем вы выдумываете какие-то проблемы, которых нет.

                                    >> Поэтому писать большие объемы кода на ассемблере сейчас просто бессмысленно
                                    А где я утверждаю обратное? Я это подчеркивал как раз.

                                    >> А через год их код станет неактуален из-за входа новой линейки процессоров.
                                    На встройке как были всякие 8051 PIC AVR и ARM7, так и остались.
                                    Уж за 15-20лет то можно научится писать под проц, где и конвеера-то 3 стадии в лучшем случае. И где ничего не поменялось за этот срок.

                                    Опять же, на консолях пишут сравнительно много ассемблерного кода, который актуален в течении всего 10-летнего жизненного срока, а то и больше — если СPU не сменят на несовместимый.

                                    Да даже на PC в самых свежих интеловских процах всё что есть это небольшое развитие архитектуры 15 летней давности.
                        +2
                        Бывает варианты когда на Си в принципе нельзя писать. Например когда ОЗУ нет вообще :)

                        Ну и в целом можно и нужно писать на Си, но знание ассемблера помогает ПРАВИЛЬНО писать на Си, чтобы компилятор там не рожал монстров.

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

                        Опять же зная асм можно понять как на Си написать ту или иную вещь, часто бывает это совсем неочевидно. Ведь среди МК разброд и шатания в плане архитектуры. Куча разных видов адресных пространств. Например, на AVR в GCC для того, чтобы строку разместить во флеше недостаточно просто обьявить ее как PROGMEM, она должна быть еще вне main иначе работать будет, но помимо того что она будет во флеше, так она еще и в ОЗУ запихается в самом начале проги и ляжет там балластом. А потом бедные программисты сидят и гадают, а чего это у них ОЗУ так резко кончилось. Все летит кувырком и сплошные срывы стека. Кстати, о срывах стека — ассемблерщики это чуют жопой с рождения, те кто всю жизнь писал на Си (да под ПК) может и не догадываться о такой милой вещи :)
                        0
                        Это пожалуй единственная не прочитаная даьше первых глав книга на моей полке.
                          +2
                          Я начинал под Z80 (92 год где-то) причём до этого почти не был знаком с программированием, только базовые знания бейсика на уровне школоты…

                          Главное это удобный отладчик, и само собой хорошая литература.
                          (У меня отдладка была вся ручкой в тетрадке, по этому познавал ASM я в 10 раз дольше чем те кто учился с нормальными отладчиками)
                            0
                            +1. У меня не было ассемблера даже в те времена, а ещё не было нормального мануала по Z80, была только тонкая книжка «Учимся программировать КР580ВМ80А» или что-то в этом духе, в конце которой была приведена табличка соответствия мнемоник и восьмеричных кодов команд.

                            А когда я начал под ×86 писать, аналогичная книжка меня уже не спасла, т.к. в ней не было опкодов. Вскоре, правда, нашлась Большая Чёрная Книга на тыщу страниц, в которой описывалось всё, включая опкоды, функции BIOS, а также распиновки 80286 и 80386, а также debug.com и двухпроходный метод написания программ с его использованием — вначале набить программу со всеми джампами на текущий адрес, а потом вторым проходом перебить адреса на настоящие.

                            Вот так вот.
                              +2
                              Наш чувак! У меня до сих пор хранятся эти тетрадочки в клеточку с командами Z80 (а после 8051) в столбик.
                                0
                                Таких много на самом деле, до сих пор многие под спеки пишут. Правда теперь увы только для развлечения, и чаще всего на эмуляторах. Но факт остаётся фактом.

                                Я как то на zx.pk.ru попал, чуть со стула не упал, думал все уже забыли что бывают компы меньше чем гигагерц, а нет, пишут, и сегодня…
                                  0
                                  Да я в курсе. У меня на WE:EE такой чел есть. Маньяки, они ужо через спек в инет ходят. Пол схемы на мощной плисине собрано.
                                0
                                Такая же фигня. Отладчик был, но проще было переписать в тетрадку, там же написать комментарии, нарисовать в той же тетрадке диаграммы или блоксхемы.
                                +15
                                Э… А о чём, собственно, статья? Очередной мотиватор? Надеялся на большее. Полезной информации — ноль. А в комментах вечный холивар — Assembler vs C. Хотите поговорить об этом? (и не только)
                                  +2
                                  Пофиг на ассемблер, футболку где взять??!
                                    0
                                    Растолкуйте нубу, пожалуйста, что там написано. Я только понял, что это как-то связано с процедурами.
                                      0
                                      Восстановили регистр из стека и вышли из подпрограммы, только и всего.
                                        0
                                        Это-то прочитать и я могу. Но в каком-нибудь STDCALL это наверняка значит что-то ещё.
                                          0
                                          Ну еще это at&t синтаксис, так что линуксоиды детектед.
                                            0
                                            Да про синтаксис всё понятно. Смысл непонятен.
                                      0
                                      Например, здесь: www.getdigital.de/products/Assembler/lng/en
                                      0
                                      Как раз интересуюсь асмом, посоветуйте хороший учебник
                                        +2
                                        Мне понравился «Зубков С.В. Ассемблер для DOS, Windows и Unix», но это ИМХО
                                          +1
                                          Супер книга! По ней реально можно весьма быстро писать на х86
                                            0
                                            Она хорошо структурирована и там упущена «лирика», она концентрирует внимание на главном, и главное она последовательна. Она одновременно и учебник и справочник. Редко такое можно встретить.
                                              0
                                              Именно. А еще подробно рассказывается как все это барахло скомпилировать и запустить таки. Ну и ляпов и опечаток я в ней не заметил. В Отличии от желтой такой. Юрьев чтоль автор.
                                                0
                                                Может, В. Юров «Assembler: Практикум»?
                                                Сам не читал, не знаю. Учился по Зубкову.
                                                  0
                                                  Он ога. Там есть практикум, а есть теория. Двухтомник. В целом неплохой, но вот багов и глюков там ужос.
                                          0
                                          Криса Касперски почитайте — как книги, так и статьи.
                                            0
                                            Справочник по инструкциям, отладчик, дизассемблер, интересные приложения
                                              0
                                              Если речь про x86 архитектуру, то начинайте с «Кип Р. Ирвин — Язык ассемблера для процессоров Intel» — не пожалеете, тут все пальцах показано и грамотно выстроен порядок изложения материала, автор отличный педагог. Потом уже классики жанра — Абель и Юров. Зубков тоже неплох, но многие необходимые базовые моменты изложены вскользь. Удачи.
                                                0
                                                У Ирвина одна вода в книге. Да и устарела немного, впрочем как и книга Абеля. Но тем не менее — классика…
                                              –1
                                              Статью написала Светлана?
                                              Интересно как выглядит девица, которая кодит на асме
                                                –1
                                                Как показывает практика, примерно так же как и все остальные обременённые интеллектом.
                                                  0
                                                  Не факт. Знаю нескольких весьма красивых девушек. Одна лет 7 назад работала вирусным аналитиком у Касперского, другая сейчас где то в Яндексе. Обе очень неплохо знают ассемблер.
                                                    –1
                                                    Покажите мне то место, где я писал, что обременённая интеллектом = некрасивая.
                                                  +2
                                                  Как, как? Как огурчик! Зеленая и в пупырышку.
                                                  А фото можно глянуть по ссылке в профайле.
                                                    0
                                                    Светлана, приезжай к нам в Кишинев)))

                                                    В нашей области за то реальные личности и человечные люди
                                                    А комерсатнки и менеджеры золотистые блонды, на красных мафынках и мечтами о миллионах
                                                    Согласны?
                                                      0
                                                      Не, я на государство работаю, так что за границу не пустят.)
                                                    +1
                                                    Примерно так
                                                      0
                                                      >> Интересно как выглядит девица, которая кодит на асме
                                                      Например так
                                                      web.mac.com/christinacoffin/iWeb/Site/Main%20Page.html
                                                      Christina Coffin, Platform Specialist @ DICE
                                                        0
                                                        Ты тоже выбрал у нее наград больше чем у Брежнева))
                                                        Not bad for a beginner
                                                      0
                                                      Знать ассемблер, конечно, хорошо и полезно для общего развития, но вот писать на нём, по моему скромному мнению, нет смысла с тех пор, когда изобрели branch predictor, т.е. примерно с начала 80-х годов 20 века.
                                                        0
                                                        Э… А о чём, собственно, статья? Очередной мотиватор? Надеялся на большее. Полезной информации — ноль. А в комментах вечный холивар — Assembler vs C. Хотите поговорить об этом? (и не только)

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

                                                        Самое читаемое