Изучение ассемблера: суть и с чего начать?

Спасибо!

А на кой мне консоль? Есть же гуй.

Просто хочу ковырять это. Есть устройства, на которых нет ОС и мне интересно попробовать их заставить что-то делать, даже, просто вывести заезженное приветствие.

гуй

Конфиги — только через консольку. Так кошерно.

Эк тебя мотает от полюса к полюсу.

Ассемблер - тупая и в целом бесполезная штука. Я бы хотел время, потраченное на него, переинвестировать в основы CS/SE, это реально мозги ставит.

Ближе к сабжу - полезно почитать «Архитектуру компьютера» Таненбаума, достаточно вторую половину. Это и есть низкоуровневый фундамент, который полезно иметь. Там и про ассемблер в общих чертах есть.

Вы, наверное, и умножаете на 2 битовыми сдвигами?

Я так понимаю, что текст программы на ассемблере необходимо компилировать, да?

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

Есть какие-то общие правила написания программ?

В общем виде большая часть кода выглядит примерно так:

operation [arg1, [arg2, [arg3]]]

Еще есть метки для переходов (функции реализуются через них же), а так же директивы DWARF (в простейшем случае они тебе не понадобятся)

Что это за WASM или TASM?

Диалекты/реализации ассеблера одной платформы. Устаревшее Г мамонта, под никсами в основном используют gas (и аналоги) и nasm(yasm)

Сборка программы на ассемблере возможна не на устройстве, для которого пишется программа?

Да, как существует кросс-компиляция, так же возможно и кросс-ассемблирование. Ассеблер из LLVM позволяет ассемблировать под все платформы, с которыми собран LLVM, gas из GNU binutils только под одну целевую (придется собирать отдельно под каждую)

Я так понимаю, что для «переменных» необходимо жестко указывать ячейку памяти процессора и ОЗУ, да?

Регистры надо указывать (изучи ABI твоей платформы, чтобы узнать, в каких регистра что можно делать). В качестве памяти можно использовать стэк, или выделять ее malloc'ом

Необходимо для старта читать кучу материала о страницах памяти и т.д.?

Это проблемы ядра, а не прикладухи

В общем, кто что посоветует, с чего начать, где эти основы брать?

Пиши код на С, компилируй gcc -S, разбирай что получилось в асме.

Или попробуй отреверсить какую-нибудь простую программу.

Лучше возьми какую-нибудь живую архитектуру, MIPS, ARM или PPC например.

это я к тому, что xor там таки не нужен

Как раз таки нужен. Под парностью-непарностью понимается не четность-нечетность, а то, два или один раз встречается некое число

Изучение ассемблера: суть и с чего начать? (комментарий)

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

да, а есть еще и вторая? =)

Да мне не особо интересны всякие хаскелы, если честно. И С не особо радует пока. Я хочу изучать нутро железок и ассебмлер вместе. Я знаю некоторые физические законы и знаю о наборе инструкций. И вот, мне хотелось бы оперировать ими ради интереса, так, для души. Читай мои предидущие комменты.

P.S. Сори за грамматику, если что - пьян я уже немного.

Почему?

Для начала нужно ответить на вопрос: а зачем?

Для зарабатывания денег - однозначно смысла нет, больше времени потратишь.

Чтобы не казаться самому себе быдлокодером? Дык на ассемблере быдлокодить ооочень и очень просто.

Интерсено. То есть предлагаешь для лучшего понимания ассемблера заниматься передачей данных из ассемблера в С и обратно? Я расчитывал на вакуум на вроде Z80 и MC6800.

Спасибо. А почему MIPS? Я пару лет назад пытался разобраться в разнице MIPS, RISC и т.д., но походу без ассемблер из этого ничего не выйдет. Зато запомнил, что огромное количество супер компьютеров построено на MIPS.

P.S. Это же в MIPS отсутствует умножение и деление? Или это во всех архитектурах?

Я понимаю что сказал, тот же tcc можно линковать как либу и именно это я и имел ввиду, тянуть с собой gcc как рантайм.

Для переноса кода в исходниках с одной ноды на другую и дальнейшего исполнения. Код как данные:) Объекты переносятся целиком, и подтягивают зависимости. Только не надо тут про безопасность, эта тема мне известна.

Забей, тебе это не нужно. Да и вообще редко кому нужно.

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

ObjectiveС запилили из других соображений, скорее из смолтолковских:)

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

Да, не раз я слышал такое, но у меня в планах начать с ассемблера, а потом вернуться к C и Lua. Может еще Commodore прикуплю для Basic. Хочу начать с самых низов.

В подтверждени моей паранои или чего там хочу сказать, что пока я не прочитал пару книг за 30-е года я не мог понять почему U*1.42 часто выходит с погрешностями.

Да, это хорошо позволяет понять как всё работает, достаточно быстро на практических задачах. Теория хорошо, но практическая работа с указателями, когда на входе получаешь С структуру, внутри которой указатели на другие структуры и массивы структур, а участки памяти для этих структур выравнены(привет winapi) - это прекрасно чтобы разобраться с чтением и записью памяти в асм. Ещё это хороший теоретический материал как строить с помощью самого асм сложные структуры. Может конечно не стоит как С делать, но будет над чем подумать.

Также при вызове stdcall, fastcall ты прекрасно разрберёшься как работать со стеком, с регистрами и тд.

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

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

Уже прочел :) . Спасибо. В любом случае я планирую вернуться к изучению С. Но хочу начать пониже с простых процессоров и ассемблера для них, чтобы потом не городить хрень на С. Может, после первых костылей на ассемблере перейду на С, чтобы праллельно их изкучать :) .

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

Ну, у него несколько книг, если я правильно понял. Или то тупые переиздания?

Себе могу ответить уже, наверное, в сотый раз. Я к таким вещам не подхожу как бутылка и тупая идея. Хотя последнее спорно, глядя на kde.

Я не собираюсь на этом зарабатывать. Где-то на второй странице есть коммент мой, где я описываю детское «вау». Оно мне не дает покоя.

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

Потому что MIPS простой - это RISC - Reduced Instruction Set Cfoiapocxs. Там команд процессора можно по пальцам пересчитать. Создание своего MIPS процессора - это обычное домашнее задание учебных заведений микроэлектроники.

А вот x86, x86_64 - это CISC - там дофига инструкций/флагов/странных регистров и т.д.

Суперкомпьютеры на MIPS были давно. Сейчас, если только, в оборонной промышленности и ещё пару не очень популярных областей.

PS. В MIPS есть умножение/деление как целых, так и вещественных чисел, но в каких-то реализациях может и не быть. Это касается всех архитектур.

Это мне напоминает моего хорошего друга. Я ему о xmlhttprequest, а он мне о ng-app. Ну, мой период с более низкими языками, чем ecmascript достаточно быстро пролетел и я не ощутил всего кайфа. Можно сказать, что я ничего не понял, хоть в свое время баловался с blitz3d и s60.

Спасибо! Еще один пункт чего почитать :) .

Лучше почитай про fpga и verilog, прежде чем засорять голову историческим фгм процессорных архитектур.

Я хочу изучать нутро железок и ассебмлер вместе.

Поверь, это весьма безблагодатное занятие. Всё чего ты хочешь получить «для души», можно получить и на хаскеле: чистая алгоритмизация, решение задач в условиях ограничений. Причём, как в смысле работы с «верхним» околоматематическим уровнем, так и в смысле эффективного взаимодействия с весьма и весьма сложным языковым рантаймом.

Как я писал в прошлом своём посте, ассемблер для прикладника в современных условиях не имеет никакой ценности. Для системщика, по сути дела тоже: посмотри, например, исходники линукса. Там на ассемблере написаны весьма тупые куски кода, для которых компилятор ЯВУ слишком умён.

Справедливости ради стоит отметить что есть область где ассемблер востребован. Это DBT/DBI системы: Qemu, Valgrind, PIN, DynamoRIO, Paradyn/Dyninst и многие другие. Область бурно развивается. Например, исследование малвари уже невозможно без DBI. На подходе полноценные поведенческие анализаторы, как малвари так и белого софта, не требующие для своей работы вмешательства в низкоуровневые структуры ОС. Или анализ исполняемой среды в целом: от самых потрохов ядра до самых верхов прикладных программ.

Возможен разумный компромисс. Хочется низкоуровневости? Дык, направь свой взор на LLVM.

По крайней мере, вышеперечисленные направления монетизируются, в отличие от сферического ассемблера в вакууме.

Зачем тебе ассемблер? Что ускорять собрался??? Вот серьезно, на этом этапе, на таком вот уровне когда спрашиваешь даже какой компилятор брать...

Всё чего ты хочешь получить «для души», можно получить и на хаскеле

кто о чем а... хехе

Задавали соискателям задачку. Есть 4 млрд + 1 число, из которых 4 млрд - парные и 1 непарное. Надо найти это самое единственное непарное число. Решается на низком уровне просто элементарно, если знаешь как работает машина. Было интересно послушать какие конструкции лепили соискатели. Ппц, чего они лепили... Сортировки, хеши, таблицы. Мрак.

То есть по-твоему правильный ответ это перебрать 4 миллиарда чисел и к каждой паре применить xor?!!!!!

Процент ассемблера сильно зависит от специфики проекта. Нельзя ядро считать одним проектом, даже административно это не так. Не зря же они git сделали, чтобы чисто казалось что это один проект:)

Так вот, в проектах типа ffmpeg, различных драйверах и конечно в коде для микроконтроллеров как минимум дофига асм вставок, куда больше 1%, а как максимум целые модули на асм.

Это я не апонирую, не подумайте, вы и так всё это знаете, просто дополняю:)

Ну есть ещё цела отрасль программирования как управления разными физическими процессами(контроллерами). По сути там программирование чисто прикладное. Да, туда конечно тоже приходит всякие распбери, но только туда где предсказуемость не сильно важна. Да и всё равно, работать с портами из того же nodejs обычный жабаскриптнег не сможет без знания того как оно работает внизу.

По сути там программирование чисто прикладное.

По сути, там программирование чисто системное. Есть только ты и аппаратура. Ну, может быть несколько библиотек.

Всё больше и больше смещается в сторону C. В смарт-картах (пусть и не во всех) вообще используется ява.

Вон тут намедни писали что в эппловской зарядке стоит МК, сравнимый (быстрее в числодробилке, медленнее в I/O) с ЦП первого «Макинтоша».

Новым витком в развитии ассемблера будет массовый вывод на рынок компьютеров, сохраняющих своё состояние (оперативка, регистры) и при выключении питания. На первых порах они будут тормозить, а некоторые и *будут* тормозить. Например, МК питается от солнечного света и ме-е-е-е-дленно (с частотой около сотни раз в секунду, а если энергии мало то вообще десятки) обрабатывает показания с какого-нибудь датчика. Но это дела будущего.

Если брать Raspberry, то с ним всё просто. Прикладная программа — буде даже на ассемблере — не сможет «сама» подёргать, например, GPIO. Она может только попросить через определённый интерфейс соответствующий модуль ядра.

неправильный ответ

Ну так напиши правильный! Ты же сам писал в качестве ответа:

targitaj ★ (27.12.2015 4:56:16)
исключающее или

Ты предлагаешь пройтись по всему объему данных и к каждым двум элементам применить xor. Если тебя поняли неправильно, объясни.

Первое со вторым, результат с третьим, результат с четвертым и так до конца. В общем-то, на порядок применения вообще пофиг. В результате останется одно непарное число. А ты провалил тест.

ты провалил тест

Я свой вариант не предлагал, фантазер.

Ты смешон, «программист».

Нет, правильный ответ:

int result = number[0]
for (i = 1;...)
   result ^= number[i]

Фишка, в том, что xor анигилирует 1 ^ 1, поэтому в комп. графике его применяют, чтобы отсекать фон спрайта или фон какого-нибудь слоя, при накладывании на бекграунд.

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

http://www.dbnet.ece.ntua.gr/~george/sed/OLD/sed-microcode.html

В первую очередь вопрос где эти знания применить собираетесь? Или «А смысл?».

Если это контроллер PIC10,12..., то там 33 инструкции или типа того, специфичная RISC архитектура, описание конкретного чипа на страниц 100, где все понятно. И для какой-нибудь задачки типа снять с ADC значение и отправить его по I2C вполне подойдет. Там только ассемблером и можно пользоваться в памяти на 1024 инструкции.

Если это контроллер посложнее, SoC, например LPCxxxx c ARM-ядром. То там надо разбираться не с ассемблером - на нем обычно пишут лишь стартапный код (2% от силы) для инициализации периферии, прерываний, SDRAM и т.д., входы в обработчики прерываний. А дальше в основной код, писанный на C. Тут надо знать сам SoC; правила передачи параметров в C-код. И собственно язык C.

И писать на ассемблере все задуманное на такой платформе а) очень трудоемко; б) решения получаются непереносимыми на другие платформы.

В Linux тоже очень мало ассемблерного кода, по тем же причинам. И ту же инициализацию PCI шины например (видел только что) делают на C c использованием inp_b() и т.п.

Для каждого проца своя система команд + разные регистры конфигурации в приложение к ядру. У каждой платформы своя обвязка, описание которой может доходить до 2000 страниц как у Samsung S5PV210. Описание ядра ARM 926 примерно того же объема. Описание Intel-овского чипсета например 950 страниц. Заниматься этим «по-приколу» очень странно. Тут нужна серьезная причина.

По платформам и архитектурам. Z80, MC6800 ...Commodore, ZX ... Зачем заниматься некрофилией? Есть современные интересные контроллеры, платы, которые можно сейчас купить в магазе или заказать. А если идея вдруг «выстрелит», то сделать серию девайсов.

По компиляторам. Для x86 - MASM умер в 98-м, TASM - в 200x. NASM вроде бы поддерживается и есть на Linux и оффтопике. С синтаксиса GAS и того что выдает GDB меня лично воротит. Для других архитектур есть свои тулчейны.

Для x86 - MASM умер в 98-м,

masm32 воскресс

Для других архитектур есть свои тулчейны.

если все просто то $arch_gnu_abi -o elf_abi file_source.c

а так это интересный квест, квк же СПО закрыли под приетарщину, ой писать про возможности СПО много, былиб мозги, всё сказано

Сходи к врачу

Есть 4 млрд + 1 число, из которых 4 млрд - парные и 1 непарное. Надо найти это самое единственное непарное число. Решается на низком уровне просто элементарно, если знаешь как работает машина.

А как тут знание работы машины помогает? Нужно знать операцию исключающего или(побитового). Она и в Java есть.