С Наступившим!
Вообщем попытаюсь объяснить на пальцах - есть код примерно такого вида (утрирую):

изобретаю велосипед - условным переходам JE/JG/JL... используя операнд назначения $1 (это указатель на метку) нужно прыгнуть на собственно саму метку . Как это сделать БЫСТРО и КОРРЕКТНО?
Мыслю так - минимум требуется три итерации:
1. Черновая (draft) - берем адрес метки %1 и адрес первой инструкции от фонаря. Строим таблицу размеров инструкций - что сколько примерно занимает места, ибо ВООБЩЕ НЕ ЗНАЕМ, ГДЕ ЭТА МЕТКА и куда точно прыгать. Плевать, сколько условные переходы могут занимать байт в этом случае.
2. Чистовая (precision) - зная примерное количество занимаемых байт каждой инструкции, ребилдим таблицу. Взводим флаг повтора для следующей итерации, когда размеры draft != precision (если условный переход был 6 байт, а превратился в short. безусловный 5 байт - в 2 байта).
3. Чистовая-повторная (precision repeat) - если в предыдущем шаге флаг повтора взведен (draft != precision), то требуется с самого начала скорректировать операнды ВСЕХ условных переходов. Но, опять-же, далеко не факт, что здесь-м размеры инструкций совпадут с предыдущим шагом.

Может это как-то по другому делается?

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным: Vamit

ELF_7719116

Главная проблема в рекурсивной функции, если смещение удлиниться, то это сместит остальные ветвления. Эта же проблема имеется и при изменении кода.

Решение зависит от модели графа. В самом простом случае следует начинать пересчёт размера всех ветвлений, если хоть одно удлинится.

-----
vx

| Сообщение посчитали полезным:

Archer пишет:
Закладывай все переходы длинные
Да я тоже об этому думал, но как объяснить XEDParse/asmjit, чтобы они автоматом long переходы ставили, а не short?
difexacaw пишет:
Главная проблема в рекурсивной функции, если смещение удлиниться, то это сместит остальные ветвления.
Так я жэ про ето - пересчитывать можно бесконечно

| Сообщение посчитали полезным:

ELF_7719116

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

-----
vx

| Сообщение посчитали полезным:

Да и не надо асмам объяснять, тыкай на 1 проходе 6 нопов. А на 2 проходе тыкай переходы. Воткнёт длинный-как раз на 6 байт. Воткнёт короткий-да и фиг с ним, будет 4 нопа ещё.

| Сообщение посчитали полезным: sefkrd

Archer

А если инструкция по какой то причине изменится, это сместит код и все ветвления. Фиксировать резервные пространства по определённым адресам не есть общее решение.

-----
vx

| Сообщение посчитали полезным:

difexacaw
постпроцессор сделать?

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным:

difexacaw пишет:
не есть общее решение
Если каждый раз пилить "общее решение" за всю жизнь можно не написать ни одной работающей софтины

Тут вроде вполне применимо. Я в приблизительно* похожей ситуации делал "вторую итерацию" в виде патчера, который проходился по скомпилированному файлу и по маске перезаписывал нужные адреса.
Прошли годы, сабж работает без проблем до сих пор на всех ОС (да и почему бы ему не работать?).

| Сообщение посчитали полезным:

Парни, не накидывайтесь на Клерка. Я долго думал над эпитетом, который ярче всего охарктеризовал бы его и понял, что это - идеалист. Человек стремится написать идеальный код и рассмотреть все возможные и невозможные ситуации, в которых этот самый код побывает. Каждый мыслит по-своему, но это не повод для гнобления. Мир всем!

| Сообщение посчитали полезным:

упс ...задачка то на самом деле довольно простая, дистанция прыгов определяется максимум за 2 прохода по меткам, и то при условии, что изначально все прыги намеренно длинные.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным:

ELF_7719116 пишет:
Да я тоже об этому думал, но как объяснить XEDParse/asmjit, чтобы они автоматом long переходы ставили, а не short?
Пиши просто jxx long addr, если асм нормальный он сделает все длинные как указано, при условии что отключена оптимизация по размеру

-----
Everything is relative...

| Сообщение посчитали полезным:

Как описал Archer - так и работают все однопроходные ассемблеры.
В принципе, если в тексте не встречаются нераскрытые макросы,
то одного прохода по тексту вполне достаточно для разбора.
- Если иметь фиксированный размер инструкций переходов.

..Помнится такое:
даже TASM в режиме USE32 генерировал такой "разбавленный" код - например, <74h,25h,90,90,90,90>.
Если не был дан ключ трансляции "/mX" , где X=2,3.. проходов трансляции.
Это емнип.

ELF_7719116 пишет:
как объяснить XEDParse/asmjit, чтобы они автоматом long переходы ставили, а не short?

Вспомним, как оно было в TINY модели, MASM (.8086) синтаксис -
- Jx переходы всегда генерировались длиной в 2 байта.
- Jmp переходы (ближние) всегда генерировались длиной в три байта (по умолчанию).
Если же нужен был короткий двухбайтовый jmp переход (0EB,{BYTE}), тогда следовало явно написать - <jmp short>.
Но тогда, если метка, после добавления кода между нею и инструкцией <jmp short> на неё, оказывалась дальше 127 (или -128) байт, то выходил затык.


difexacaw пишет:
На чём именно затыка

На том, что просто выдавалась ошибка трансляции
"**Error** - Relative jump out of range".

--Добавлено--
Это при ".8086" (по умолчанию),
если же было указать ".386", тогда никаких ошибок не выдавалось,
и по JZ, например, генерировалось 4 байта <0F,84,xx,xx>
--Конец Добавленного--


В TASM'e этот логический тупик обходили собственной директивой JUMPS.
тогда вместо

Jx @label

- макросредствами автоматически генерировалось:

JNx $+5 ; всегда 2 байта
JMP @label ; всегда 3 байта
; $+5 - это здесь (2+3=5)

Можно попытаться воспользоваться этим решением, концептуально. ( через <DB> ?..)
.. - хотя, это всё лишнее, если имеется в явном виде модификатор <LARGE>. (Или <LONG>, как написал Vamit).



| Сообщение посчитали полезным:

dosprog

На чём именно затыка, на каждом проходе пересчитать ветвления не проблема и в таком простом случае исключаются возможные алгоритмические ошибки, каким бы запутанным не был код :



-->


7434_04.01.2018_EXELAB.rU.tgz - Build.zip

-----
vx

| Сообщение посчитали полезным:

ELF_7719116 пишет: Да я тоже об этому думал, но как объяснить XEDParse/asmjit

Первый своей жизнью живет, а у второго long jmp address

| Сообщение посчитали полезным:

Archer пишет:
Да и не надо асмам объяснять, тыкай на 1 проходе 6 нопов
Да знаю за нопы, но этож не красиво как-то
Vamit пишет:
Пиши просто jxx long addr
shellstorm пишет:
Первый своей жизнью живет
Они long-large не знают. FAR, NEAR, SHORT. В любом случае, короткий будет если достает по операнду
Короче я пока просто подгоню под свой случай, когда в 90% - будет short-переход. Начиная с draft. А так на будущее может форсированно ставить самому LONG и считать всё за две итерации. Действительно головняка и тактов CPU меньше в разы.
thx всем!

| Сообщение посчитали полезным:

ELF_7719116 посмотри этот https://github.com/herumi/xbyak тут long jmp

| Сообщение посчитали полезным: ELF_7719116

ELF_7719116

> Действительно головняка и тактов CPU меньше в разы.

Просадка будет и не малая при стандартной структуре графа и повторным проходам по нему. В данный момент для сборки графа я бы использовал супер эффективный механизм - бинарных деревьев, нт экспортит два вида этих алгоритмов, причём высокоэффективных. Маркером(описателем) одной связанной структуры AVL может быть виртуальный адрес. Проход по данному списку невероятно быстрый, элементы списка двусвязаны(в две стороны можно листать). Более эффективные структуры придумать врядле возможно.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Просадка будет и не малая при стандартной структуре графа
эм? В смысле jmp short выполняется быстрее, чем jmp long(far)?

| Сообщение посчитали полезным: