Pull to refresh

Comments 58

Обучение людей ассемблеру — поддерживаю, но… TASM и DosBox?

Желающим приобщиться к теме я бы лучше порекомендовал вооружиться NASM/SASM и либо книгой «Assembly Language Step-by-Step» для совсем начинающих, либо «Assembly Programming and Computer Architecture for Software Engineers» для тех, кто покрепче.
Как мне кажется, для обучения 16-битного x86 и DOS более чем достаточно. Оно ближе к железу (хоть и эмулируемому), что для обучения возможно даже лучше. На 32-битный и 64-битный x86 перейти потом очень легко, так как основные команды те же, с легко усваиваемыми изменениями и дополнениями. Я тоже начинал с 16-битного x86 где-то в 2007, и после устаревших уже на тот момент трюков с видеобуфером и написанием резидентных софтин, легко переключился на x86-32 для написания уже полезных патчей для любимых игр. Потом на досуге ещё освоил 6502 для программирования под NES/Famicom/Dendy родом из 1983, где нет даже команды умножения, и нет помощи от чего-то вроде BIOS (то есть общение с железом возможно только напрямую), и считаю это тоже интересным опытом, полезным для расширения кругозора в этой области.
В 16-битном ассемблере для DOS очень много мусора (на текущий момент). Сегментная модель памяти, ближняя/дальняя адресация, ограничения на использование регистров как индексных, да и сами вызовы DOS, в конце концов.

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

Всё зависит от цели изучения ассемблера. Использование ассемблера на практике, как правило, не ограничено одной архитектурой. Поэтому полезно и x86/x64 изучать, и ARM, и прочую экзотику.


А чтобы понять базовые принципы, то можно и с MSIL начать.

MSIL и java bytecode не очень подходят в силу того, что это ассемблеры для стековых виртуальных машин

Каким образом из второго следует первое?

Так, наоборот, с них проще начинать: нет регистров, флагов. И на практике легко применять. А уже потом можно более глубоко погрузиться в ассемблер.

Я бы голосовал за современный 64-битный ARM. Он банально проще.

Мдаа... Накосячили в статье знатно...

  1. DosBox нужен только для 64-разрядной винды. Если установлена например Win7 x32 то ДОС-программы запускаются там без эмулятора.

  2. d: это не реальный диск на вашем компьютере, а виртуальный - D: это просто сопоставленное имя указанному пути (виртуальный диск это обычно файл эмулирующий диск)

  3. Про CS,DS и SS - это просто песня... Назвать регистры местом в памяти... В русском языке это секция кода, секция данных и область стека.

  1. Вы имеете ввиду, что нужно уточнить в статье "не качайте DOSBox, если у вас Win7?

  2. Спасибо за замечание.

  3. Согласен, формулировка не корректная.

Начиная с XP виндовс выпускался в 32-битной и 64-битной версиях (это можно увидеть в свойствах системы). Но в 64-разрядой винде запуск 16-битного приложения дос вызывает ошибку, поэтому приходится извращаться ставя эмуляторы (DosBox) или запуская виртуальную 32-разрядную машину (например hyperv).

Поскольку 32-разрядные ОС имеют предел в 4ГБ, сейчас почти везде 64-разрядные системы. Но уж лучше на такой ОС пользоваться современным По. Та же Visual studio позволяет писать на ассемблере (а в виде вставок в код С++ это облегчает в несколько раз).

"Начиная с XP" может ввести в заблуждение: WinXP x64 вышла в 2005 -- через год после SP2 для 32-битной WinXP, и через четыре после оригинальной версии.

Начиная с XP виндовс выпускался в 32-битной и 64-битной версиях

Windows XP 64 bit edition — это не 64-битная версия Windows XP (NT 5.1), это адаптированная версия Windows Server 2003 (NT 5.2).


Поскольку 32-разрядные ОС имеют предел в 4ГБ

Нет. 32-битная Windows Server 2003 Enterprise вполне могла работать и с 64ГБ.

«Windows XP 64 bit edition» — это вообще для Itanium ;-) Версия для x64 называлась иначе.

Ну да. Windows XP Professional x64 Edition. Но не суть.

Обратите внимание, теперь мы не указываем расширение файла, который запускаем.


Turbo Debugger AFAIR если не указывать расширение ищет сначала файл с расширением .COM, если не находит, то с расширением .EXE. Соответственно если в директории будет и CODE.COM, и CODE.EXE (что в данном случае в принципе быть не может, просто на будущее говорю), то строчка «td code» загрузит в Turbo Debugger файл CODE.COM, а не CODE.EXE. Так что расширение всё же надо бы указывать, просто для аккуратности.
Очень верное замечание. Помню даже были вирусы использовавшие эту особенность. Набираешь допустим в командной строке win и жмешь Еnter. И вместо win.exe запускается некий win.com. И понеслась…
bat идет до com, поэтому можно было написать «вирус» win.bat

Нет. Сначала com, потом exe, потом bat.

Точно, я вспомнил, что я через PATH правил порядок запуска.
Эта статья пролежала в песочнице двадцать лет, что ли?
От ассемблера для DOS практический толк такой же, как для PDP-11.
От PDP-11 толк есть — её советские клоны Электроника-60 до сих пор тянут лямку на оборонных предприятиях и защищают Россию от врагов.

Согласен. Но вдруг пригодиться такая инструкция тем, кто изучает его в ВУЗе на DOS? Как например это было в моём...

Я потому и вспомнил PDP-11, что в моём институте ассемблер до сих пор учат на нём :)

С появлением Turbo C/Pascal/Debugger люди нередко писали на ассемблере прямо inline, в соответствующей Turbo среде (конечно, если не волновали сотня-другая байт, добавляемых компилятором + заголовок exe файла). Соответственно, всё было очень комфортно — по моим ощущениям не сильно хуже, чем в современных средах.
Вот до появления Turbo сред было неудобно. Отладчик типа AFD считался за счастье, а некоторые так вообще умудрялись что-то отлаживать в командной строке debug.com из стандартной поставки DOS.

А ещё и в Visual Studio можно было писать на C/C++ с ассемблерными вставками.
Правда, этот функционал потом порезали.

И сейчас можно. См. директиву __asm { }

Можно, но только для x86.
Для 64-битного кода этот функционал недоступен.


Впрочем, я познал дзен интринсиков, поэтому ассемблерные вставки мне более не интересны.

У меня друган Sokoban с 10 уровнями написал в debug'е ))) за ночь
Статья представляет собой разве что историческую и учебную ценность (лабораторку сдать). Автор лучше рассказал бы о том, как программировать на ASM'е под Windows (хотя бы как сделать окошко с кнопочкой). Это было бы гораздо актуальнее…
Ещё актуальнее — на чём-нибудь типа Pi Pico поморгать светодиодом: там ассемблер может пригодиться и для практических нужд, а не только для учебных примеров.
Автор лучше рассказал бы о том, как программировать на ASM'е под Windows (хотя бы как сделать окошко с кнопочкой). Это было бы гораздо актуальнее…
Помнится, некоторое время назад определённой популярностью пользовались уроки Iczelion'a
Ага, на васме лежит перевод, так и адаптированная версия под fasm, и отдельно вариант под Win x64 (но не думаю что его можно как самодостаточный вариант рассматривать)

А для тех, кто не хочет сидеть в досбоксе есть книжки Столярова "Программирование на языке ассемблера NASM для ОС Unix" и ее новая версия "Программирование: введение в профессию. II: низкоуровневое программирование".

Компилятор ассемблера это оксюморон. Ассемблер это набор мнемоник, однозначно указывающих на конкретные команды процессора, поэтому у него может быть только транслятор.
К примеру, в случае FASM это не так — он сам выбирает ближний или дальний переход. Не говоря уже про макросы)
Макрос — набор прямых команд процессору, которые подставляются в месте, где используется имя макроса. Поэтому, внутри макроса метки должны содержать префикс @, иначе они станут глобальными и при повторном применении макроса возникнет ошибка дублирующего имени метки. Что касается переходов, то всегда можно указать какой именно переход нужен. Но многие трансляторы позволяют использовать метамнемтонику и транслятор выберет переход по доступности адреса перехода сам, при этом не всегда в приоритете короткий переход. И это не прерогатива только FASMа. Ну и следует помнить, что ассемблер это не только про IA32/IA64.
IA64 — это Itanium; вряд ли вы его имели в виду.
Да, я промахнулся мимо x64 (не хотел писать банальное x86/x64), но даже для IA64 есть свой ассемблер.

Да и MASM, по-моему, так помогает. Это если про x86. В thumb/arm/arm64 вообще выходит три режима и общие мнемоники могут стать тремя разными опкодами в отдельных случаях.

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

И нет — существуют языки ассемблеров, которые не являются мнемониками команд: например, в Эльбрусах (не современные микропроцессоры, а серия советских суперкомпьютеров), имеющих разные архитектуры и разные системы команд, использовался единый высокоуровневый язык ассемблера. И он именно компилировался.
А транслятор ассемблера — тавтология.

Ждал этого комента. Всё так и есть. Assembler = сборщик. Что касается Эльбруса, то в статье, увы, не про него.

а еще TASM поддерживает ООП...

Спасибо за важное замечание.

Изучал ассемблер по книге Питер Абель. "Ассемблер и программирование для IBM PC", и на реальном железе, DX486, 16 Mb RAM. На момент появления у меня такого компьютера, он уже был устаревшим, софт требовал больших ресурсов. Мотивом изучать ассемблер как раз стало желание разрабатывать быстрое ПО, которое бы потянул мой компьютер.

Мда.. в свое время именно на TASM писал кряк с руссификатором шрифтов для PCAD 4.5 и руссификатор для PC с загрузкой шрифтов в shadow BIOS

Почему именно vk.com?

Чтобы подавляющее большинство хабровчан из Украины сразу забили, так как VK заблочен
Чтобы уважающие себя люди сразу забили качать исполняемые файлы из группы в VK
Ведь есть же sourceforge.net/projects/guitasm8086

И только теперь мы начинает запускать наш файл! Бедные программисты 20 века, как они только терпели всё это? Пропишем следующую команду:

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

Этот старинный интерфейс насквозь пропитан духом ушедшей эпохи старых операционных систем. Тем не менее…

Ну чем он кардинально отличается от современных hex-эдиторов с возможностью дизассемблирования?
Даже современные отладчики в общем-то похожи. Больше окошек и скалируемость? Но это не совсем про интерфейс.

Assembler – Урок 0: Установка компилятора и запуск первой программы через DOSBox

А где тут про ассемблер?
Скачать два архива, распаковать и установить DosBox — это же целая статья, да?

Если бы было написано ПОЧЕМУ именно этот тасм, почему именно так делать?
Я, например, могу привести пример. У меня с запыльных времен есть парочку исходников резидентов, а такой термин многие современные разработчики и не знают. И да, резиденты можно запускать в дос. Но в статье ни слова о таком неудобном выборе.

Ну сколько можно некрофилией заниматься? Да, TASM надо памятник поставить и цветы приносить, но закопайте его уже и не трогайте больше могилу!


И на FASM и на NASM пишется намного легче. И 32 битовое и 64 битовое программирование что для Windows, что для Linux намного легче чем под DOS. И что более важно – студенты смогут написать хоть какое-то, но современное приложение, реально работающее в современной ОС.


Кстати, именно поэтому и начали использовать TASM, когда он еще был живым!

Если сильно хочется погрузиться в эту тему, то лучше взять классиков. Например, почитать Олега Калашникова. Луче уже не написать.


PS при беглом взягляде на vc.com подумал, что будет раскрываться тема создания файового менеджера.

В интернете 100500 учебников по ассемблеру и автор решил сделать ещё один, в котором не рассказывает ничего нового.

Мог бы рассказать про ассемблер под ARM. Нет, он в очередной раз повторит 100500 раз сказанное до него про архитектуру, которой никто не пользуется уже 20 лет
Зря вы так. Этих машин еще как грязи. Причем сейчас можно купить очень добротное раритетное железо которое раньше стоило как хороший автомобиль. Да и на производствах встречаются контроллеры которые до сих пор спокойно работают. Рынок может быть и не массовый, но списывать его не стоит.
Господа, а особенно преподаватели. НИКОГДА не начинайте учить людей ассемлеру с х86. Возьмите контроллеры, да хоть бы AVR.
Самое главное это наглядность: в контроллере мы просто пишем out и значение регистра отправляется в порт — как есть, без преобразований и прочей магии. В процессоре мы вынуждены использовать библиотечную или BIOS'овую магию.
Во-вторых, ограничения архитектуры 8-битных контроллеров отлично иллюстрируют такие вещи, как стек, регистры флагов и т.п. Плюс прерывания, но это не из-за ограничений.
Ассемблер х86 для изучающего выглядит как просто еще один язык программирования с вырвиглазным синтаксисом. А для контроллеров — как прямые команды железу.
Only those users with full accounts are able to leave comments. Log in, please.