Короче я думаю никто не обидется если я расширю эту тему.
Вчера взял из дому описание XS потока:

============ Выдержка ================================
;; Структура для любого типа систем
XSCODE struct

var dd ? ;; Зависимое поле
main dd ? ;; Главное поле

XSCODE ends
Из всех вариантов был выбран последний, так как его эффективность в использовании не зависит от типа разрядности системы.
Таким образом, элемент XSCODE представляет собой 64-битовое поле, при чём по старшему адресу расположено главное поле, а по младшему адресу зависимое поле, называемое переменной.
Основная идея архитектуры XSCODE это связка полей main и var.
Поле main является в свою очередь сложным полем, обладающим возможностью связывать коды потока в секции до 64*4. Секцией называется взаимосвязанная последовательность XSCODE структур. Информация о том, как читаются и связываются поля, хранится в младшем бите поля main. Вот полная структура main:

Бит 0 Флаг режима XSCODE_MAIN_FMODE

Если XSCODE_MAIN_FMODE = 0
Биты 1-31 Идентификатор кода
Если XSCODE_MAIN_FMODE = 1
Бит 1 Флаг размера секции XSCODE_MAIN_FSSIZE
Если он установлен, то размер секции составляет 4*XSCODE, включая и эту секцию, иначе размер секции 2*XSCODE.
Бит 2-3 Размер XSCODE XSCODE_MAIN_SIZE
00 - 64
01 - 128
02 - 256
03 - 512 бит
Наличие этого поля, даёт возможность изменить размер XSCODE.
Бит 4 CUSTOM XSCODE_MAIN_FCODEPOS
Определяет позицию кода,
1 - поле кода находится в следующих 24 битах (чего в большинстве случаев достаточно),
0 - код находится в поле var этого XSCODE.

Тем не менее, режим 0, используется чаще, а поле data обычно содержит дополнительные данные.
Бит 5-7 Неопределенны и зарезервированы
Бит 8 - 31 Поле data.

На основе XSCODE структуры, строятся все внутренние потоки XASM. Их достаточно много, они имеют свои особенности и расширения по отношению к XSCODE, в границах текущего соглашения.


Вот кстати пример использования формата этого потока

Формат ACODE зависит во многом от содержания. Мы рассмотрим поток ACODE, который используется для описания исходного кода в текстовых файлах.
Например:
#function::MyFunction::{
a = b+c;
f = 2+d;
t = f+a;
MyFunction::===::t;
}::MyFunction::function#


Здесь рассматриваемый код преобразуется в поток протолексем, в зависимости от схемы ключевого скрипта.
1. <#>
2. <function>
3. <::>
4. "MyFunction"
5. <::>
6. <{>

Анализ TXT потока, выполняемый стримерами, основывается на простейших правилах регулярных выражений, и схем зависимости. Однако проблемы стримеров на этом не заканчиваются, и об анализе потока TXT в XASM говорится отдельно.
При этом поток ACODE выглядит как:

c.main.data = "lkey";
c.var = id <#>

c.main.data = "lexem";
c.var = id <function>

c.main.data = "lexem";
c.var = id <::>

c.main.data = "lexem";
c.var = id <MyFunction>

c.main.data = "lexem";
c.var = id <::>

c.main.data = "lexem";
c.var = id <{>


ACODE определяет некоторые стандартные значения идентификаторов операции (в поле code XSCODE), всего их зарезервировано для внутреннего использования ACODE 256 первых значений включая ноль:

XSCODE_ID_EOF 0 Окончание потока
XSCODE_ID_CMD 1 XS команда потока
XSCODE_ID_CFG 2 Начало секции данных конфигурации
XSCODE_ID_INF 3 Информация о потоке
XSCODE_ID_FORMAT 4 Формат потока
XSCODE_ID_CONVENTION 5 Информация о конвенции потока
XSCODE_ID_FORMAT_GUID 6 Идентификатор GUID формата потока
XSCODE_ID_CONV_GUID 7 Идентификатор GUID конвенции потока
= 8 Зарезервировано
= 15 Зарезервировано
XSCODE_ID_SIZE 16 Размер потока в байтах
= 17 Зарезервировано
= 255 Зарезервировано


Ядра XASM уже не работают со строками, они работают с множеством идентификаторов и словарями идентификаторов, определённые в потоке ACODE.

======================================================

SmikeX
Так, может слабать Туториал по написанию Дизассемблера?
Я готов поддержать!!!

Так, вот это не что иное как Низкоуровнейвый формат потока, на основе которого строятся более высшие форматы. Например бинарный XML или код X86, или альфа код (который является результатом семантики языка программирования)
ACODE

А теперь насчёт эффективности.
Как видите элемент XSCODE устроен так, что минимальный размер составляет 64 бита, при этом из 64 бит мы теряем 1 бит.

Бит 0 Флаг режима XSCODE_MAIN_FMODE 

Именно этот младший бит регулирует внутренний формат элемента.

Максимальный размер XSCODE составляет 64 байта * 4 = 512 байт.


При этом потери составляют 7 бит!!!

Вам может показаться, что с таким форматом вы получаете затраты?
Получаете, если элемент потока меньше 64 бит....
Но !!!! Вы не заыбли что грядёт IA-64!!! ^)

Вот например, упращённая версия формата потока OBJ кода ассмеблера (кстати, а может быть не обязательно код асма :))) в OBJ):

-=-=-=-=-= AASMCODE ==-=-=-=-=-=-=-=-=-=

Для простых команд без операндов используется 64 битная XSCODE. При этом всегда используется вариан с XSCODE_MAIN_FMODE = 0

В этом случае поле (бит 1-31) codeid = это структура имеющая такой формат:

Бит: 1-15 ОПКОД (полный)
Бит: 16-17 - Тип операндов/адресации

0 - Нет
1 - Регистры
2 - Регистр/память
3 - Сложная адресация

Если Тип = 1
биты до в поле XSCODE.main = регистры (первый второй):

Если Тип = 2
Следующие биты до 23 - один регистр
Бит 24 - 31 (тип операнда !!! Это навароты для компилятора а не для кода)

XSCODE.main = операнд (смещение его)

Если Тип = 3
То в этом случае обычно мы имеем дело с XSCODE размером в 128 бит, хотя иногда и в 64...
ТОлько не подумайте, что Тип = 3 определяет размер, просто при описании косвенной адресации нужно больше данных.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Что характерно для XASM, так это то, что операнды это не просто переменные, а переменные имеющие тип, и возможно вспомогательные данные.
ТО есть такой код ассемблера поступает потом на вход к оптимизаторам (их несколько), где изрядно колечится и модифицируется..

Для дизассемблера так же придётся хранить дополнительные данные об операндах, (это вопрос вывода на экран, а так вопрос анализа кода).

Затраты на использование 64 битных элементов не велики, потому что большенство данных == 32 битные.
А эта структура была задумана так, чтобы удовлетворять потребности 32/64 битных архитекрур, при высокой скорости анализа и одновременно хорошей гибкости кода.

То есть анализатор XSCODE отделён от анализатора AASMCODE.

Вот примерно в кратсе как выглядит структурирование таких вещей.

Edmond

Скромно влезу в разговор... Если не секрет, что такое XS поток, описание которого приведено выше?

Edmond

Разошлись с постами по времени :)))

The Svin
Кстати, а как быть с теми командами часть Опкода которого лежит в другом поле?
Как это стыкуется со схемой анализа. Всегда хотел узнать, почему именно так Intel зделала!!!

Bog_
XS - от XScript - универсальный формат записи скриптов в бинарном виде.

А так же -- спецификация по разработке синтаксиса скрипта.
Это примерно что и ECMA стандарт, но для XASM

Попробую выдвинуть свою теорию построения структуры.
Можно инструкцию процессора представить в виде набора данных:
Instruction
{
Address;
flags;
Operand1;
Operand2;
Operand3;
}

Каждый же операнд представим так
Operand
{
TypeAndFlags;
BaseRegister;
ScaleRegister;
Index;
Value;
}
В операнде может указываться тип данных и другие параметры...

Структура Instruction находится в узлах графа, который строится на основе анализа потоков кода. В результате появляется возможность разделения кода и на более крупные логические блоки (процедуры например). Наличие тех или иных префиксов можно учитывать как во флагах, так и путем ввода нового поля данных.
Типы полей данных не приводятся, т.к. могут зависеть от конкретной реализации. В качестве оптимизации можно придумать и динамическое изменение размера структуры (в зависимости от наличия тех или иных полей).

Bog_
выдвинуть свою теорию построения структуры

Только теория не твоя..
Это называется Трёхоперандное представление кода.
:)
Я частично использую её.

Bog_
Структура Instruction находится в узлах графа, который строится на основе анализа потоков кода. В результате появляется возможность разделения кода и на более крупные логические блоки (процедуры например).

Кстати, хочу обламать -- ГРАФЫ Рулят только в выражениях с минимумом нелинейный зависимостей синтаксиса (то есть без всяких там правосторонних штучек) и с предсказуемым развитием.

Для ЯВУ этого хватает конечно. И славо Богу :)

The Svin
Кстати, а как быть с теми командами часть Опкода которого лежит в другом поле?
Как это стыкуется со схемой анализа. Всегда хотел узнать, почему именно так Intel зделала
Я вобще вашу схему понять не могу.
Может и можно формат Intel приводить к какой-то дибильной схеме, программистам на Java. Но зачем низкоуровневым то её приводить к какому то линейному формату?
Код инструкции сам по себе формат, просто не такой тупой
как структуры Windows или таблицы в реляционных базах данных.
Это не другое поле, это расширение поля ID инструкции.
Или как принято его называть опкода.
Но ID тоже не обязательно занимает весь байт. Оно может быть и 4х битное.
Например формат 1011 reg w. ID = 1011
т.е. например B4 09 - mov al,09
ID не B4, здесь ID = 1011(старшая hex цифра B)

Вобщем это абсолютно ясно из обучалок, там всё развалено
на биты - щёлкай, смотри, тестируй себя. Нет ну вы смешные люди. Ладно, замяли, объясню текстом, - хотя там всё наглядней.
Есть такой блок называется он modr/m. Наличие или отсутсвие его процессор определяет когда прочитает часть ID инструкции. Он всегда расположен за блоком code, который
содержит уникальное ID инструкции или группы и в зависимости от размера, также некоторые общие поля (какие
тоже определяет процессор по ID - они группируются по принципам декодирования).
Формат этого поля:
mm c/r m/r т.е. биты 3х полей группируется по 2:3:3 бит.

Поля c/r и m/r используется для кодирования операндов,
причём m/r может "расширяться" в последующие за байтом
modr/m байты. В SIB и 1,2,4 байта смещения.
Первое поле mod помогает определить значение
сколько байтов в инструкции являются - смещением.
Так вот, что особенного можно сказать о различии между
c/r и m/r
Если через c/r можно закодировать только регистр, то через
m/r можно закодировать хоть регистр, хоть любой указатель
в памяти (кроме переопределения сегмента, что делается через префиксы)
Теперь вспомним такую вещь, что туева хучка инструкций
имеет только один операнд, причём эти инструкции работают как с регистрами так и с памятью, и хотят обращаться к памяти со всеми возможностями адресации.
Ну никак тут тогда не обойтись без байта modr/m и евонных
полей mod и m/r и возможности "расширятся дальше".
Но поле то c/r оказывается ненужным, операнд один и биты проподают.
Тогда принимается изящное решение - ID в блоке code становится уже не ID инструкции, а ID группы инструкций,
и какая конкретно инструкция имеется ввиду - определяется
через поле c/r
Оно это поле так и называется code or register - c/r.

Попытка же группировать инструкции по значению байта в блоке кода - это искажение реальности.
Нет такого и процессор не так декодирует, и формат не так построен.
А использование cod/r позволило колосально увеличить диапозон возможных ID инструкций не потратив ни одного лишнего байта.
В группе 1111111w до сих пор не используется 111 в c/r например, только от 000 до 110. И никаких дополнительных байтов.
Интеловские форматы - это бинарные форматы, и конечно высокуровневые структуры с "обычными" типами - это такое убожество, что говорить в голову не приходит о каком то возможном соответсвии, бинарные форматы условно развалены на байты для удобства программирования, но их поля не обязательно разваливаются на байты, чаще наоборот.
И формат кода это к тому же сложный формат - т.е. формат длина которого может изменятся в зависимости от содержания полей. Это как динамическая таблица которая может изменять длину и определение длины нигде не записывается - оно становится ясно при декодировании.

Edmond

Только теория не твоя..
Для меня она моя, так как я ее придумал и реализовал (не основываясь на других источниках). Хотя для других она может быть чьей угодно, на авторство я не претендую (тем более что эта схема логически вытекает даже при поверхностном анализе в терминах объектов)
Это называется Трёхоперандное представление кода
Ну да, даже и название официальное есть :)

ГРАФЫ Рулят только в выражениях с минимумом нелинейный зависимостей
А в случае машинного кода это не так (в большинстве случаев)? Сразу хочу ответить на случай динамического изменения кода: Граф можно достраивать и при эмулировании выполнения кода. Конечно даже в этом случае возможно не удастся избежать неоднозначности, но это лучше, чем вообще не иметь представления о структуре программы.

The Svin
Может и можно формат Intel приводить к какой-то дибильной схеме,

Это вы зря. Вы меня недооцениваете. :)

Но зачем низкоуровневым то её приводить к какому то линейному формату?

Потому что промежуточный формат кода ДОЛЖЕН БЫСТРО АНАЛИЗИРОВАТЬСЯ

Когда то годика два назад, у меня было маниакальное стремление разработать супер экономичный формат для документов типа WORD..
Я ломал эту головоломку пол года, успев овладеть многими хитростями, подобными тому, что использует Интел.

Но потом, когда после разработки формата я начал писать парсер, я понял КАК Я ОШИБСЯ!!!

Всё-таки получилось, написал красивый формат для текста. (Если слова разные он почти не сжимается. Всё продумано до мелочи). Формат переделывался раз 30, в поиске гибкого, но оптимального решения.

И всё к чертям :(((

Для ускорения работы во время редактирования пришлось придумать ещё один формат, потому что тот, к чертям не годился. :(((

Зато я кое что понял :)

Bog_
Для меня она моя, так как я ее придумал и реализовал

Это хорошо!!! Я рад, что общаюсь с подобными людьми.
Но!!!
Не сочтите за обиду, у меня такого "сам придумал" полно.

Говорить что "мне всё равно, что уже придумали " это не культурно.

Есть наука, и её следует придерживаться.

А в случае машинного кода это не так

Согласен, потому что в коде всё идёт с лева на право...
А вот в ЯВУ не всегда :)

Потому что промежуточный формат кода ДОЛЖЕН БЫСТРО АНАЛИЗИРОВАТЬСЯ
А приводится "сырой опкод" к такому формату он быстро должен или как?