> стр. 178.
> В схемке для кода xor ax,bx
> дана бинарная раскладка (в прямоугольниках на рисунке) как:
> 33 С3 ->11 000 001
> Должно быть 11 000 011.

***

> стр. 178.
> Цитата:
> Фраза о ModRM:
> "Отметим, что биты 3-5 никак не зависят от выбранного режима адресации
> и всегда задают либо регистр, либо непосредственный операд"
> Коментарий:
> Биты 3-5 (поле codr) никогда не задают непосредственный операнд (он
> вообще битовым полем не задаётся, а представляет собой сами данные
> расположенные в хвосте инструкции).
> Биты 3-5 могут либо содержать код регистра, либо часть кода операции.

***

> стр.178.
> Цитата:
> "Формат поля R\M, строго говоря, недокументирован, однако достаточно
> очевиден".
> Он документирован, и без документации не очевиден.
> Далее идёт странная схема.
> Про бит обозначеный цифрой 3 (надо понимать это бит_2 поля memr)
> написано например:
> 0 - нет базирования.
> 1 - есть базирования.
>
> Понять, что здесь могло подрузамеваться под "базированием" мне не
> удалось. Скажем просто
> в 16и битной адресации, при mod<>11, за исключением случая
> mod=00 & memr = 110 ,бит_2 означает
> 0 - используется пара регистров в формировании указателя [база][индекс]
> 1 - используется 1 регистр (можно - [база]).
> Дальше эту схему разбирать не буду, она настолько несостоятельна, что
> проще написать заново всё.
> Скажу только что приступая к разбору кодирования адреса через MEMR
> нужно было бы отметить в начале, что здесь вначале приводится
> кодирование в 16и битном режиме. При некотором сходстве с 32х битным
> кодированием ModRM существуют существенные различия и объясняя систему
> кодирования хорошо было бы говорить о скольки разрядной адресации идёт
> речь.

> стр. 178.
> Цитата:
> "..поля mod. Оно фактически задаёт длину следующего элемента в
> байтах".
> Это неверно. Оно действительно определяет длину.
> Но назовём это лучше не следующего элемента а смещения в команде.
> Или displacement.
> Почему несостоятельно название "следующий элемент".
> Простой пример:
> пусть в команде отсутсвует дисплейсмент но присутсвует
> непосредственный операнд.
> Что тогда "следующий элемент"?
> Непосредственный операнд.
> И поле mod к его длине никакого отношения не имеет.
> Но это не самое плохое в процитированном месте.
> Главная ошибка "задаёт длину .. в байтах".
> Это не так. Совпадение будет только в 16и битном режиме при отсутсвии
> префикса 67 или в 32х битном с префиксом 67.
> Поле mod задаёт:
> 00 - отсутвие displacement. (исключение memr=110 в 16и битной
> адресации, memr=101 в 32х битной адресации)
> 01 - displacement как знаковый байт, который будет расширен до полного
> размера.
> 10 - displacement размером с полный операнд (а не размером в 2а байта)
> это может быть и 16 бит и 32а.
> 11 - регистровая адресация.

***

> стр 179. (перебрались ещё на одну страницу)
> Цитата про кодирование displacement знаковым байтом:
> "Таким образом, диапозон возможных значенией младшего байта
> от -127 до 127"
>
> Ошибка: от - 128 до 127.
> Отрицательные от FF(-1) до 80(-128)
> Дальше весёлое дополнение :)
> "(или от -0х78 до 0х78)"
> дело в том что тут мне уже никак не поправить :)
> Максимальный модуль отрицательного не выразить через знаковое
> положительное в дополнительном коде - он совпадёт.
> Т.е. что я запишу абсолютным безнаковым будет 80h
> что знаковым - 80h что неточно и эквиваленто 80h что точно.
> Вообще разные числа придуманы чтобы лучше были видны те или иные
> стороны. Двоичные и HEX в частности для того чтобы лучше было
> понятно с положением\состоянием бит и двоичной экспонантой (порядком
> числа). Никогда не видел удобства записывать математическое отрицание
> с помощью HEX.

***

> стр. 179.
> Цитата:
> "Отсюда следует, что для экономии следует избегать непосредственного
> использования BP в качестве индексного регистра. BP может быть только
> базой".
> Вообще напротяжении всей книги используются слова "база, индекс" с
> разным значением. И очень трудно понять что имеется ввиду.
> Почему не сказать было что следует избегать использовать BP в качестве
> отдельного указателя (т.е. без наличия смещения в команде или
> дополнительного индексного регистра)?
> Зачем эти жанглирования словами "индекс, база" смысл которых в твоём
> контексте ты строго не определял.
> Ну пусть например я за базу возьму некоторое слогаемое указателя
> которое неподвижно, тогда индексом буду считать подвижную(чаще
> изменяемую в коде) часть.
> Тогда чем bp не индекс например в коде.
> @1:
> mov al,[100][bp]
> ...
> inc bp
> loop @1
>
> Далее опять пассаж привлекающий мистическое значение слова индекс:
> "Сильнее всего сказалось ограничение, позволяющее использовать в
> качестве индекса только три регистра (BX,DI,SI)"...
> Утомило что то меня отлавливать ошибки в описании 16и битной
> адресации.
> Реальность такова
> В 16и битном коде привлекаться к формированию указателя на память
> могли только 4е регистра...
> Впрочем вот - посылаю свою краткую доку по этому поводу.
> Чтобы не повторятся и не потерялись слова в письмах.

(мое примечание - дока лежит на сайте в разделе "образовательные программы")

> стр. 184.
> Цитата:
> "Вряд ли мы скажем, о чём говорит опкод 0х87. (Впрочем, обращая
> внимание на его близость к операции NOP = xchg ax,ax, можно
> догадаться, что 0х87 это код операции xhcg)"
>
> Гениальный способ :)
> Это значит если близко к 90h (nop) то скорее всего тот же опкод?!
> Интуитивная математика в действии :)
> ID то опкод занимает кусочек байта (а может и больше быть)никакими ты
близко далеко ничего не
> раскопаешь - это бинарное поле а не порядковый номер.
> Тогда 8Eh по такой системе - уж точно стопудово xhcg :)
> Он ещё ближе к 90h ! Только я почему-то уверен что это mov ;)
> У 90h и 87h - вообще разные ID, они относятся к разным форматам.
> 90h - это группа 10010 reg (xchg (e)ax,reg) (oт 90h до 97h)
> А 87h - это группа
> 1000011w:modrm (xchg reg,mem/reg)
> И если кодировать xchg ax,ax в этой именно группе то получиться вовсе
> не 90h а 1000011 1: 11 000 000 (87 C0)

***

> стр. 185. Анализ опкода BEh
> Цитата:
> "Обратим внимание на третий (от нуля) бит. Он равен нулю для AH и
> единице в нашем случае. Рискнём предположить, что это и есть бит
> размера операнда: хотя это и не утверждается явно Intel..."
>
> Ну что ты постоянно бочку на Intel катишь, по поводу
> недокументированности - всё у них расписано
> про этот опкод. Смотри во втором томе нужные форматы.
> Вот точная цитата из Intel по поводу конкретно mov reg,imm:
>
> immediate to register (alternate encoding)
> 1011 w reg : immediate data
>
> Конкретно как видишь написано - 3ий бит - w .
> Бит размера то есть.

***

> стр. 185 рассуждения об опкоде BE.
> Цитата:
> "Заметим, что это, строго говоря, частный случай, - могло бы оказаться
> и иначе. Так, например, четвёртый справа бит должен быть флагом
> направления или знакового расширения"
>
> И не должен и не может.
> Битом направления он не может быть по двум причинам
> 1. Бит направления присутсвует тогда и только тогда, когда
> - есть байт ModrM (а здесь его нет)
> - в байте ModrM в обоих полях memr и codr содержаться операнды
> которые могут быт определяемы через эти поля (здесь такой операнд
> один и направления задавать нечего - непосредственный операнд
> ВСЕГДА в конце инструкции и никак иначе, и всегда источник, поэтому его
местоположение
> или направление определять нет смысла)
> 2. Вторая причина бит направления D если присутсвует то всегда
> находится по индексу 1.
> Второе условие справедливо и для бита S, поэтому он тоже никак не
> может быть на месте бита по индексу 4.

volodya
Все скопировал! Большое спасибо за выделенное для меня время. Очень приятно!

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