ERRATA к книге Зубкова С.В.
"Assembler для DOS, Windows и UNIX"
ДМК, издание второе, Москва, 2000


стр. 36
DIV источник

цитата:
"Выполняет целочисленное деление без знака AL,AX или EAX на источник и помещает результат в AL,AX или EAX..."

Следует читать:
"Выполняет целочиселнное деление без знака AX, DX:AX или EDX:EAX..."
...
IDIV источник
та же лажа (см. выше)

--------------------------------------------------------------------

стр. 49
JA CF=0 и ZF=0
JBE
вместо "JBE" следует читать "JNBE"

--------------------------------------------------------------------

стр. 61
В описании нулевой функции инструкции CPUID везде упоминается, что строка-производитель возвращается в EBX:ECX:EDX. На самом деле порядок регистров перепутан и должен быть таким: EBX:EDX:ECX.

--------------------------------------------------------------------

стр. 183
AL = режим доступа
бит 0: открыть для чтения
бит 1: открыть для записи

следует читать:
AL = режим доступа
бит 0: открыть для записи
бит 1: открыть для чтения/записи
(если оба сброшены - то для чтения)

--------------------------------------------------------------------

стр. 186
Функция DOS 42h:
...
вместо "CX:DX = новое значение указателя в байтах"
следует читать "DX:AX = новое значение указателя в байтах"
...
вместо "и в CX:DX будет возвращена длина файла в байтах"
следует читать "в DX:AX будет возвращена длина файла в байтах"

--------------------------------------------------------------------

стр. 256
INT 27h: Оставить программу резидентной
Вход: "AH = 27h" - совершенно ни к чему

--------------------------------------------------------------------

стр. 265
INT 2Dh AL=0Xh
...
следует читать
AL = 03h

--------------------------------------------------------------------

стр. 335
mov al,0Dh ; Младший байт делителя частоты

следует читать "mov al,D0h"

--------------------------------------------------------------------

стр. 336
бит 6: собственно индекс

следует читать "бит 6-0" собственно индекс

--------------------------------------------------------------------

стр. 383
lodsb ; AL = следующий символ из буфера в ES:SI

следует читать "следующий символ из буфера DS:SI"

--------------------------------------------------------------------

стр. 390
Цитата:
"Бит направления роста сегмента (E)... В сегментах с этим битом, сброшенным в ноль, разрешены абсолютно все смещения от 0 до лимита, а если этот бит 1, то допустимы все смещения, кроме от 0 до лимита."

следует читать "...разрешены все смещения от значения в поле "База" до значения в поле "База+Лимит"

--------------------------------------------------------------------

стр. 503
INT 0Ah-0Fh (IRQ2-IRQ8)

следует читать "INT 0Ah-0Fh (IRQ2-IRQ7)"

--------------------------------------------------------------------

стр. 518
цитата:
"при дальних JMP, CALL,RET на неподчиненный сегмент кода должно выполняться условие: DPL=CPL (RPL игнорируется)"

на самом деле RPL принимает самое горячее участие, а игнорируется только при дальних JMP, CALL, RET (кстати, и SYSENTER и SYSEXIT) на ПОДЧИНЕННЫЙ (!) сегмент кода.

--------------------------------------------------------------------

стр. 565
Скан код клавиши C - 2Eh (а не 3Eh)

--------------------------------------------------------------------

Если на стр. 390 автор под "смещением" имел в виду Effective address, то почему он не прав? Ведь при Exp Down=0 можно 0<=offs<=lim, при Exp Down=1
Max >= offs >lim. А базу (в арифметике с переполнением!) можно описывать в разделе о вычислении вирт. адреса.

Если здесь можно писать и замечания (это лично мои):

1) В главу 2 внесен раздел 2.3 "Основные непривилегированные команды", он по сути является справочным (хотя в нем и есть небольшое количество примеров это сути не меняет, их кстати (примеры) можно было бы собрать в отдельный раздел, скажем - "Специфика применения команд" или т.п.), также как и раздел главы 10 "Системные и привелигированные комманды". Эти оба раздела органично составляют единое целое и хорошо бы их вынести в отдельное приложение (как например Приложение 2 "Команды Intel 80x86")

2) Глава 3 "Директивы и операторы ассемблера" занимает не заслуженно мало места (отсутствует описание специфичных для ассемблеров разных фирм констант и т.п.), все примеры приведенные в этой главе явно куцые.

3) Приводятся примеры для Watcom'овского компилятора, но сейчас по уровню распространения он занимает едва ли не последнее место (лучше было бы привести примеры работы с fasm и nasm).

4) Раздел главы 7 "Драйверы устройств" смотриться явно неказисто и оставляет гораздо больше вопросов чем ответов. И такое ощущение что он был включен для того чтобы показать широту охвата книги.

5) Порядок глав в книги совершенно непонятен (после главы о Windows идут главы о совместной работе с ЯВУ, оптимизации и защищенном режиме).

P.S. Однако я считаю эту книгу одной из лучших книг по практическому Ассемблеру (не для новичков).

Valery
Совершенно точное замечание.
Видимо Broken Sword воспринял под смещением линейный адрес. Который как раз получится как база + смещение :)
Ещё отметим и то, что при проверки адресации процессору вовсе нет дела до проверки базы - она отсутсвуют в команде - там только смещение. Если переопределения сегмента по умолчанию нет - достаточно сверить поля предела в теневом регистре со смещением.
В сегментах данных адресный диапозон простирается от базового адреса до базового адреса + предел, т.е. смещения варьируются от 0 до предела. Смещения, которые больше предела, вызывают особый случай защиты. В сегментах стека с ED=1 ситуация оказывается противоположной в том смысле, что поле предела определяет неадресуемую область сегмента. Здесь все смещения должны быть строго больше
предела, а если смещение меньше или равно пределу, фиксируется особый случай нарушения стека.[/b][b][b][/b]

Если здесь можно писать и замечания
Обязательно. Нужно :)

Broken Sword
Нужно не забывать, что у Зубкова 2 версии книги. И в двоих куча ошибок.

Вы пишите в каком издании 1 или 2?

Edmond

Там вроде в самом верху написано ДМК, издание второе, Москва, 2000

стр.94 (комманда MOVSS)

"Копирует младшие 64 бита..."

следует читать:

"Копирует младшие 32 бита..."

У меня первое издание Зубкова. Оно все в исправлениях. На приводимые ошибки я уже не обращаю внимание. Уже выработалась привычка все перепроверять. Интереснее ошибки концептуальные. Скажем в примере по применению IDT, стек посажен прямо в таблицу IDT. Самое забавное, что пример работает. Но это случайность. Просто стеком почти не пользуемся и затертые строки в IDT не используем.

У меня первое издание Зубкова. Оно все в исправлениях.
Дело добровольное конечно.
Но, думаю, лучше опубликовать-поделится исправлениями,
чем просто сообщать, что они есть.
Для читающих лучше, разумеется.
Я, как простой обыватель, могу про себя сказать -
какие ты сделал исправления - мне очень интересно.
А просто сообщение, что они у тебя есть, имеет для меня информационную ценность близкую к нулю.
Без обид,
просто честное объяснение - за что такой незначительный человечек как я сказал бы спасибо, а что просто пропустил бы при чтении.

стр. 46 описание работы BSR,BSF
Цитата:

Т.е. если источник равен 0000 0000 0000 0010b
то BSF возвратит 1, а BSR - 14

Ошибка:
И BSR и BSF в этом случае вернут 1.
Нет никакой разницы в порядке индексирования одних и тех же битов между BSR и BSF, а также любой другой команде из группы битовых инструкции.
Биты операнда индексируются с 0 начиная с младшего и индексы представляют собой двоичный логарифм степени двойки которую представляет найденный бит.
Разница между этими командами лишь в том, что одна находит самый младший а другая самый старший бит. На этом разница исчерпывается

Broken Sword,
по поводу твоих слов:
------------- Цитата ----------
на самом деле RPL принимает самое горячее участие, а игнорируется только при дальних JMP, CALL, RET (кстати, и SYSENTER и SYSEXIT) на ПОДЧИНЕННЫЙ (!) сегмент кода.
--------------конец цитаты-----

Эхххх.
Тут нужно сказать несколько слов.
С одной стороны ты прав, что RPL учавствует, с другой стороны Зубков сказал так странно а ты так кратко, что в общем неискушённый читатель может вообще понять по третьему :)
Если коротко то при значении RPL=0 он будет действительно игнорироваться, а поставить RPL в 0 может даже программа 3го кольца. Это DPL или CPL она фиг изменит а RPL - пожалуйста.
Но так тоже непонятно может показаться, поэтому чуть больше слов:
Передачи управления в другой сегмент осуществляют межсегментные (типа FAR) команды безусловного перехода JMP, вызова процедур CALL и возврата из процедур
RET. Адрес передачи управления задаётся с помощью 48и битного указателя селектор:смещение, который содержится либо в самой команде (прямая передача управления), либо берётся из памяти (косвенная передача управления). При
выполнении таких команд изменяются регистры cs и eip, поэтому с точки зрения процессора контроль межсегментной передачи управления заключается в проверки
достоверности селектора, загружаемого в регистр CS.
При загрузке селектора в регистр CS процессор предпринимает следующие проверки. Прежде всего проверяется, что целевой дескриптор (дескриптор сегмента
которому передаётся управление) определяет сегмент кода, т.е. имеет атрибут исполняемого сегмента. Разрешение на считывание для этого сегмента не требуется. Затем процессор контролирует, что значение DPL целевого дескриптора точно равно значению CPL. Конечно, для ослабления действия CPL можно воспользоваться полем RPL селектора, но при этом гарантируется возникновение
особого случая защиты. В таких ситуациях поле RPL должно быть меньше или равно полю CPL. В сомнительных случаях следует устанавливать поле RPL=0 и тогда это поле не действует. Наконец, целевой сегмент кода должен быть отмечен присутсвующим (бит P=1 в дескрипторе), а новое значение для EIP должно находится в пределах нового сегмента кода. Только при условии прохождения всех
этих проверок процессор продолжает выполнение по указанному адресу передачи управления. Когда какая-либо проверка даёт отрицательный результат, формируется
нарушение общей защиты (прерывание 13) или нарушение неприсутствия.

стр. 15. конец статьи 1.2.1

Чтобы отличить двоичные чиcла от десятичных,
в ассемблерных программах в конце каждого двоичного
числа ставят букву b


Примечание:
Стоило упомянуть о возможнсти вместо b использовать y.
b совпадает с символом для шестнадцатиричной одинадцать.
И часто имеет резон заменить b на y чтобы не путала :)
Т.е. ошибочна небыла принята глазом анализирующего за цифру.
Правда я не уверен что такая замена возможна во всех ассемблерах.
Как там в FASM, NASM и прочих?

The Svin
В fasm и tasm для объявления двоичных чисел используется только суффикс b. Для объявления восьмеричных чисел в tasm'е, в отличие от fasm'а, кроме суффикса o можно использовать суффикс q или начинать число с нуля как в си. Для шестнадцатиричных чисел кроме префикса 0x и суффикса h в fasm'е, в отличие от tasm'а, можно еще использовать префикс $ как в паскале.

Black_mirror
Спасибо за справку.
стр. 15. Статья 1.2.2
Цитата:

Биты в байте нумеруются справо налево, от нуля до семи...

Нет в памяти или байте в памяти, права - лева, зада - переда, бока-низа.
Есть только числа - значения. Разрядность, адрес, состояние.
Биты нумеруются согласно позиционной системе от 0 от младшего к старшему
а не правого - левого.
Их индексы (номера) соответсвуют показателю степени двойки которую они
представляют. Это мы пишем их справа налево, писали бы слева направо,
что изменилось бы в байте индексация? Ничего бы не изменилось. Компьютору начхать
как мы что пишем, в порядке возрастания как арабы или в порядке убывания
как европейцы благодоря глупости Фибоначи.
Фразы типа Касперского "байты в двойном слове распологаются в обратном порядке"
просто в тихое бешенство начинают приводить своим профонаторством.
Обратном чему?! Это в Hiew или другой дизасм тулзе мы их видим в обратном
порядке чем мы же их видим например в ассемблерном исходнике и то если
мы их там не записали тоже байтами. Это имеет отношение только к человеческим правилам
написания и не имеет дело к компьютеру.
Адреса байтов в двойном слове распологаются соответственно повышению значения разрядов
которые они представляют, чем выше разряд - тем старше адрес.
Ни с права на лево ни слева направо, а чем выше тем старше.
Никакого тут прямого, обратного или косого порядка нет, есть соотношения адресов
и значения разрядов, величин позиций к величинам адресов.
То что мы криво пишем позиционные числа так что в байтах
в дебагере мы видим сначала цифру разряды от 4-7 потом от 0-3 потом почему-то сразу
12-15 и в обратно от 8-11 - просто следствие изначально принятой противоестественной
записи, перенятой напрямую у арабов которые числа пишут так же как мы, только
европейцы не учли что пишут они их так потому-что читают справа налево.
Теперь нашу кривую запись (в которой при написании байтами мы пытаемся совместить
два диаметрально разных направления роста позиций - группы по 8 позиций распологаются
по росту значений слева направо, а цифры полубайты в этих группах справа налево)
мы пытаемся как то спроэцировать на некий мифический
лево - право порядок в компьютере.
Нет никаких лево - право там, есть старшие и младшие разряды, адреса байтов, состояние
битов. Всё!