PING,
Без знания строения опкода,
(это определённый формат данных
который не имеет фиксированный формат
и его длина и назначение полей высчитывается
через него самого)
просто пялится в дизассемблер и дебагер - нет
никакого смысла.
Ну допустим выбирается такая методика:
Узнаем какой мнемонике соответсвует та или
иная бинарная последовательность (сразу перепугаю,
одной и той же мнемонике может соответсветвовать
разные бинарные последовательности как и
одной и той же бинарной последовадельности
может соответсвовать несколько разных мнемоник)

Известно что длина кода инструкции может достигать
15 байт. Т.е. 120 бит.
Мощность множества значений выражаемых через
120 бит = 2^120 = 1,3292279957849158729038070602e+36

Если бы мы тратили только по одной секунде на
ввод\просмотр\запоминание каждой то нам понадобилось
бы ~ 42 149 543 245 335 992 925 666 129 511,68 лет.

Мы столько не живём. Наша планета столько не просуществует тоже.

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

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

Это не так сложно, у меня это делает 7и летний сын.

Bog_
Некоторые бинарные последовательности Hiew может интерпретировать
как push reg8, pop reg8, call byte и т.д.
Я напишу лучше в бинарном виде чтобы понятней было.
Это последовательности
1111111 0, 11 110 xxx ;push reg8
1111111 0, 11 010 xxx ;call reg8
1111111 0, 00(01,10) 011 xxx ;call [byte]
и т.д. Т.е опкоды группы 1111111w xx cod xxx
в которых w должен быть 1, когда инструкции запрещено
работать с байтами.

никаких push al( и т.д) быть не может
как не может быть и call al (и т.д)
Немного разбираюсь в строении опкода, и кажется
понимаю почему это происходит.
Когда декодер встречает 1111111x он начинает воспринимать
что перед ним код формата 1111111w где последний бит
w определяющий размер операнда а ID находится в поле cod\reg байта
modr/m.

Но только несколько опкодов этой группы могут менять
последний бит это
1111111w **001*** (DEC)
и
1111111w **000*** (INC)
Тут действительно могут быть
и
FF /1
FF /0
и
FE /1
FE /0
Остальные
Должны быть только
FF /2
FF /3
FF /4
FF /5
FF /6
(call, jmp, push) никаких FE /6
А hiew тут тоже пытается интерпретировать последний бит :)
в результате получаются такие смешные вещи как call al или push ah
Надо при таком формате сначала проверить ID в поле cod байта modr/m
и если он не равен 2..6 только тогда уже пытаться трактовать
последний бит в 1111111* как бит w.

Целая группа опкода неассемблируется правильно
и hiew определяет её как неверные операнды. А так же неверно
дизассемблирует.
это все варианты smsw reg в 32битном коде
и mov reg32,seg ;mov seg,reg32
Тут сразу две ошибки.
1. Для этих инструкций hiew принимает как валидные только
16и разрядные операнды в ассемблере.
2. При этом он ассемблирует их как 32х разрядные.
Например
mov ax,cs 88C8
хотя это Mov eax,cs
mov ax, будет с префиксом 66.
Может это кажется странным но это реальность.
Регистр общего назначения декодируется эдентично как
и в других интрукциях, поэтому с появляением 32 разрядных
процессоров, чтобы избежать лишних байтов в 32х разрядном
коде для префиксов 66 Intel ввела разрешение на использование
32х битного регистра. При этом если операнд 32х битный регистр
то при mov reg32,sreg верхние 16 бит будут забиты нулями.
А при использовании reg16,sreg останутся нетронутыми.
т.е. допустим в eax FFFFFFFF а в CS AAAA
после выполнения кода
88С8 в EAX 0000AAAA
а при выполнении
66 88С8 в EAX FFFFAAAA
smsw также может кодироваться с префиксом и без и работает это
анологично описанному принципу с mov reg,sreg
Причём при использовании smsw reg32 в документации Интела написано
что верхние биты будут неопределены. Реально же smsw reg32
работает как mov reg32,cr0.
Т.е. копируются в reg32 не только младшие 16 бит но и старшие.
Проверено.
Для уверености можно сверить мои слова с доками интел и экспериментами
с smsw и mov reg32,sreg в отладчике, забивая опкод с и без 66h и
наблюдая за результатом.

Вот написал ещё одну обучалку. Уже 5я по опкоду.
Правда она отличается от предыдущих тем, что
в ней нет тестов\упражнений.
Если будет интерес - я припишу тренировочную часть.
Просто показано как моделируется.
Посвяна кодированию указателя (через поле mem/reg и mod)
в 16 битном адресном режиме. В 32битном отличается. Тоже напишу
как время найду.

Хинты.
mod - 11 - оба операнда регистры.
mod < 11 - mem/r определяет указатель в памяти.
если mod < 11 то его значение определяет сколько
байтов содержит непосредственный оффсет учавствующий
в вычислении смещения:
01 - знаковый байт (расширяется до слова при вычислении заполнением старшего
байт значением старшего бита)
10 - слово
00 - если memr = 110 то говорит, что регистров указателей нет - только смещение
во всех остальных случаях (memr<>110) наоборот говорит, что смещения
в команде нет - офсет будет вычислен только с помощью регистров указателей.

Хинты что такое биты w, d - описаны в предыдущих программках.

P.S. Я писал уроки по опкоду, но английском, нужно наверно перевести
на родной для соотечественников.
Экспертом правда я себя не считаю. Но там несколько подробней чем
остальных подобных доках.


461026005__MODRM16.ZIP

The Svin

Некоторые бинарные последовательности Hiew может интерпретировать как push reg8, pop reg8, call byte

Именно про инструкции Group4 (по описанию Intel) я и говорил в предыдущем посте... Для себя я нашел следующее объяснение: Поленился SEN делать отдельную таблицу для Group4 и использовал Group5, но с признаком 8bit-разрядности операнда, вот и получились глюки (практически то же самое что Вы сказали в своем посте:).

Целая группа опкода неассемблируется правильно
и hiew определяет её как неверные операнды. А так же неверно дизассемблирует. это все варианты smsw reg в 32битном коде и mov reg32,seg ;mov seg,reg32

Вот на это я внимания не обратил. Более того, сам на эту удочку попался... А все потому, что в описании от Intel в таблице опкодов в качестве возможного операнда той же smsw стоит Ew, что заставляет воспринимать операнд как 16битный в любом случае! А в описании же команды упоминание о том, что может использоваться и 32х разрядный регистр уже есть. Возникает вопрос: почему бы в таблице опкодов операнд smsw не обозначить как Ev, тогда и проблем бы не возникло. Что это, очередной глюк мануала, или ... В общем даже коментариев нет :(

Просто ему можно было проверить при
FE if codr > 1. -> кривого опкода обработчик.
Тогда можно было использовать одну группу.
Он обещал поправить. Ждём :)

The Svin
Он обещал поправить

SEN то поправит...
А вот когда б только Intel свою документацию корректорам нормальным отдала :/ Вроде ж фирма то - не пекарня какая нибудь, а одна из лидеров...

The Svin
Посвяна кодированию указателя (через поле mem/reg и mod)
в 16 битном адресном режиме. В 32битном отличается. Тоже напишу
как время найду.

Будь осторожен с байтом SIB! Если в нем записано [EBP+ESP*n], где n=2,4 или 8, то при выполнении произойдет исключение. Когда дойдешь до обучающей программе по SSE2, остерегайся префиксов 66,F2 и F3. Хотя в доке интела написано что они есть часть опкода, но между ними и остальной частью вполне можно поставить какой-нибудь другой префикс.

Я в курсе насчёт SIB.
Про SIB статью я уж давно написал.
Проблема была только с обучающей программой.
Не с кодированием а с внешним видом, интерфейсом.
Я никак не мог остановится на одном каком то варианте.
Блок SIB то появится (при mod <> 11 & memr = 100) то исчезнет, то же и с дисплейсментом, меняется его размер.
И нужно было решить то ли дизаблить элементы демки которые
показывают блок SIB толи скрывать их, а если скрывать - нужно ли динамически сдвигать оставшиеся.
Вобщем, проблемы с дизайном.
Но сейчас уже решил написать как получится, переписать то
непоздно никогда. А то дело затянулось, статья была давно
наглядного пособия всё нет и нет.

Кстати пример с [EBP+ESP*4] не очень удачный вариант для
духа моих тюторов.
Я в них исхожу из реальных вещей - бинарных последовательностей а мнемоники это лишь жалкое отражение
их, в них мало что видно.
Для того чтобы мне мысль свою передать лучше было бы написать.
mod <> 11 или 00
SIB = xx 100 101
и xx <> 00 ;т.е степень двойки в SCALE > 0
Но такую мнемонику как [EBP+ESP*4] закодировать
вообще нельзя.
Код ESP расположеный в index имеет совершенно определённый смысл, он не обозначает ESP - он обозначает
отсутсвие индексного регистра вообще
При этом степень двойки в scale должна быть нулевой.
Иначе, грозит Intel, будет исключение - особый случай неверного опкода.
Если чуть отвлечься от темы - практикой проверено, что
исключение происходит не на всех моделях.
Закодировать так чтобы в арифметическом смысле получить
[EBP+ESP] можно лишь поместив ESP не в индекс (что просто
отключит наличие индекса) а в базу.
т.е.
xx 101 100
код же
xx 100 101 означает не [ESP*2^xx + EBP] а просто один
из вариантов кодирования [EBP]
Последовательности же в SIB
xx 100 xxx
имеют только два практических смысла
1. Закодировать [reg] опкодом на 1 байт длинее (в целях
например получения более длинного опкода для использования в выравнивании не теряя времени на дополнительные инструкции)
2. И основной смысл сделать возможность кодирования
[ESP] которое возможно лишь с помощью SIB, так как в modr/m без SIB это невозможно.
Потому, что код для ESP в поле memr будет означать опять
же не регистр ESP а наличие SIB следующего за modr/m
Это как бы специальный код для указания что для кодировки
указателей на память будет использоваться не 3х битное поле mem/r а следущющий за ним 8и битный блок SIB
вот и приходится кодировать [ESP] как указатель
с помощью
modrm = xx xxx 100 за ним sib = 00 100 100

Запоминашка - медиташка для первых 4х значений
указаетелей в memr в 16и битном режиме адресации

316709080__MEM16B.ZIP

Приехал Ян из отпуска,
посмотрел на программу и предложил
изменить её внешний вид.
Вот новый вариант с его добавлениями.

1625828763__MEM16B.ZIP

Добавил в запоминалку остальные 4е кода указателей

865674631__MEM16B.ZIP

Bog_,
SEN прислал Hiew 6.86.
Ошибки о которых мы говорили - исправлены.