Сабж, собственно... точнее "как проще и лучше..."
Интересует, в виде каких структур лучше всего представить множество инструкций не только Intel, но и ADM?
Просмотрел массу сорцов (типа OllyDebug), но так и не понял, по каким признакам следует группировать инструкции (и следует ли вообще группировать), как их представлять внутри дизассемблера и т.п.?
Может кто че посоветует?
Особенно интересует мнение The Svin'а как спеца по опкодам

Я дизассемблеров не писал :)
Думаю сначала формат внимательно изучить.
Когда сам предмет понятен, понятен и алгоритм и структуризация. Можно ведь написать и свой оригинальный,
может от того "глаз не намылен" чужими сырцами, он получится ещё лучше.

Я тоже не писал. Но литературы масса. Простой синтаксический движок написать можно просто.
Вот тебе еще пара ссылок до коллекции:

http://bastard.sourceforge.net/libdisasm.html

внутри нее ссылка на перловский дизасм.
Кроме того, в Art Of Disassembly поднималась эта тема.
А вообще, при написании такой радости, если хочется, чтобы работала быстро, что-то вроде таблицы создавать. Посмотри на rsdn.ru статьи по синтаксическому анализу и конечным автоматам. Может там что-то есть.
А потом статью напишешь! А?

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

Что значит "опкодов до черта" - их меньше пяти сотен - по первому байту - 256 штук, а по второму (после 0x0F) еще меньше.

Max
У 90210 была статья по этому поводу, а что касается структур, то по моему сперва стоит посмотреть на структуру команд.
Там само собой всё красиво.

Структуру же твою можно было бы сделать в отличии команд IA-32 со статическими полями.

Ведь что такое команда IA?

Это как бы одна большая структура, в которой много объединений, и так далее.

Например для Дебугера, структура описания команды выглядела таким образом:

1. Поле ОПКОД
2. Поле размера операндов (1 байт, 2, 3, 4)
3. Поле регистров
4. Поле адресации + указатель на дополнительные поля
5. Поле операнда 1
6. Поле операнда 2
7. Дополнительные поля

Но это полная порнография

Для компилятора, я использовал совершенно иное.
Не думаю, что это то, что тебе нужно (Володя снова скажет закрутил :))

Всё состоит из таких маленьких структурок, которые складываются в более большие.

BASE_EL struc

flag    db ?
XXX1    db ?
XXX2    db ?
XXX3    db ?

field    dd  ?

BASE_EL

Это базовый элемент потока в XASM. Его размер 64 бита.

Любая команда складывается из нескольких таких элементов, минимум из 2-x

Вот например, для команд можно использовать следующее:

1. Первый базовый элемент (его flags указывает ссколько дальше идёт ещё таких же элементов)
в поле field находится ОПКОД
Далее идёт ещё одна махонькая структура на 64 бита
Но теперь в ней (это по правилам)
уже нет поля flag, потому что эта структура зависима.

2. Второй элемент:

2.1 Первый байт: Флаги, которые описывают команду

- команда имеет непоср. операнды
- команда имеет адресацию
- и так далее

И так далее...

Ой, батюшки. И насколько это экономично?

Edmond, упущено поле префиксов.
Проще при декодировании до блока опкода закодировать
во флагах, битов хватит с лихвой.
Dr.Golova.
маленькие уточнения
1. Не все 00-FF используются для ID, некоторые зарезервированы.
2. Существует кодирование через code block = ID группы,
и далее ID опкода в поле cod/r ID опкода.
Таким образом байт блока кода ссылается не на одну а
на сразу до 8и разных инструкций.
Вот одна из моих обучалок, демострирующая логику подобного формата.


_1016841789__MULDIV~1.ZIP

volodya
Тут не столько в экономии, сколько в переносимости и гибкости формата... дело.

Во первых специально под 64 бит заточено.

Вот вторых что такое XASM -- это где-то N програм в одной, которые беспредельничают как хотят.
Каждая использует поток данных ЭТОГО формата и обрабатывает его.

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

Насколько экономично?

Я отвечу так, это куда экономичнее чем формат Word :)))

The Svin
Edmond, упущено поле префиксов.
Проще при декодировании до блока опкода закодировать
во флагах, битов хватит с лихвой.
Я собственно не спорю...
Но тоже могу вас подколоть:)

Кроме того, что хранить команду в ДизАсме было бы удобно так же хранит вспомогательную информацию различного типа.
Так что всё равно придётся делать структуры переменного размера, или делать ещё один поток данных паралленьно с указателями их потока Опкодов.
Кстати хорошая схема.

я вот написал
самое сложное написать компактно,
сгрупировав опкоды, которых вообще-то много
250 основных по первому байту + группа 0xf (которая для pentium 4
практически заполнена с 0 до 256 по второму байту)
+ мелкие группки: 0xfe, 0xff и другие
кроме того float point инструкции и т д

есть подводные камешки типа префиксов 0x66 и 0x67
на работу ушел месяц - все вик-енды + некоторые вечера
затем долгое тестирование

кому интересно можно прочесть на
http://www.quadspeedi.net/~smike/disasmdll.htm
кому лень писать самому может взять DLL под win32
и пользовать
http://www.quadspeedi.net/~smike/disasm.zip

сообщения о багах (которые наверняка еще есть) будут приняты с благодарностью

SmikeX

Здорово. Интересно :)

SmikeX
У тебя дизассемлер только в одном режиме работает?
32 разрядном?
Т.е. декодирует указатель mem/r исходя из того что код
32 разрядный и переходит на 16и разрядное декодирование
только когда встретит префикс 67?
250 основных по первому байту + группа 0xf (которая для pentium 4
практически заполнена с 0 до 256 по второму байту)
Непонятно для меня это разъяснение,
по местоположению опкода или по полному байта значению ты имел ввиду?
Там ведь ID занимает только часть блока кода, остальная часть общая, а ID (обычно при однооперандных инструкциях)
просто ID группы и расширяется в cod/r блока modr/m.
Я не то, чтобы считаю, что ты не знаешь этого.
Но просто человек плохо разбирающийся в формате опкода не понял бы, а тем кто разбирается - и объяснять нечего, и так знают.
есть подводные камешки типа префиксов 0x66 и 0x67
Так это на определение ID никак повлиять не может,
только на переключение размерности "полного" операнда (66)
и декодирование указателя на память (67), я так считаю, что всё касаемое операндов должно быть в отдельной процедуре, если хочется именно компактности её можно сделать разрядно-независимой и вызывать из основной,
основная читает код и находит блок кода попутно кодируя
полученную информацию о префиксах в битах какой-то флаговой переменной, после того как найдёт ID извлекает
что ей надо (биты w,d,s например) и когда наступила очередь писать операнд вызывает процедуру декодирования регистра или адреса, пересылая ей указатель на modr/m и
необходимую информацию в каком нибудь флаговом виде.
При этом понятно что, например операнд в памяти
в 32битном режиме кодируется также как в 16 битном с префиксом 67 и наоборот. Поэтому процедуру декодирования
адреса или операнда можно настроить на, например, 32х разрядный режим, а перед вызовом её главная процедура проверит в каком текущем режиме адресации она работает
и если текущий режим 16 - поменяет флаги передаваемые
процедуре декодирующей адрес на обратные (всё это можно
сделать парой тактов - просто ксоря флаги префиксов 66, 67 на значение флага разрядности).
Соответсвенно процедура декодирования адресса просто имеет две ветви - декодирования по 16и битным и 32х битным законам. И соответсвенно им начинает декодирование с поля
memr учитывая mod.

+ мелкие группки: 0xfe, 0xff и другие
?
Непонял по какому принципу ты разделяешь FE и FF?
По биту w что ли? И они у тебя в разные группы попадают.
Разве ж это компактно?
Во первых сама группа 1111111w конечно же делится на две
группы, но по несколько другому принципу - по значению
в codr
Если codr > 001 то w всегда = 1, иначе это кривой опкод
(получатся всякие push al, и call cl и прочие маразмы)
В остальных случаях (codr = 000 или 001) w может быть
и 1 и 0.
Или у тебя FF C0 относится к одной группе а FE C0 - к другой?

Edmond,
2. Поле размера операндов (1 байт, 2, 3, 4)

Сейчас только обратил внимание:
Это что за операнд такой в 3байта?
Полутора - ворд?
:)

Проблема в том, что опкодов до черта, а вот классифицировать их по каким-то четким признакам у меня не получается, т.к. не могу сформировать этот самый набор признаков.
Max,
значит самое первое сообщение от меня верное.
Я понимаю твою проблему, нужно изучить строение хорошо.
Именно в логическом (и разрядном разумеется) плане.
Сам формат - он уже содержит в себе эти структуры.
Единственное, что ещё может быть надо сделать,
развалить эти битовые поля в более удобный для обработки формат.
Со своей стороны я своё маленькое скромное дело помощи сделаю -
допишу тюторы по Опкоду, и переведу их на русский.
Там всё предельно (даже избыточно) детально, с упражнениями и наглядными пособиями.
Единственое что не могу обещать - когда, пишется как пишется, я процес ускорять не хочу.
Если ты формат поймёшь - зачем тебе чужие мнения - свою
структуру напишешь, как тебе удобней и понятней.
Тебе же свои мысли удобнее выражать своими словами, представь, например, что тебя заставили говорить только фразами из Простоквашено.
Если классифицировать пока не получается, значит не пришло время ещё, не сложилось чёткое представление, посиди, почитай, поработай с демками, поэксперементируй в дебагере. Чего время то торопить исскуственно?
Пусть твой продукт будет качественным и быстрым.
И удачи тебе в этом увлекательном деле!