Придумай инструкцию x86!

f13nd,

ТС не ясно что собирает, похоже на полиморф. Можно кучу использовать инструкций, который не делают ничего; это зависит от их зависимостей в dfg. К примеру можно использовать математику, если контекст не связан с fpu. Задача совершенно не понятна. В идеале зная какие регистры используются далее, можно их использовать. Это обычная самая примитивная генерация мусора. Можно даже не думать про контекст, выгружая его через pusha. Но врядле это какой то будет иметь эффект, авер это пройдёт элементарно.

 

Насколько я понял, он хочет через исключения имитировать прерывания.

 

f13nd,

Прерывание это событие в другом моде. Так что хз какая задача. Похоже на полиморф сборку, скажите если я не прав.

 

Он в соседней теме выдвинул предположение, что было бы здорово апи реализовать через прерывания, через сех проще всего это смоделировать.

 

f13nd,

> реализовать через прерывания

А что это значит ?

 

А не, он прерывания портами ввода-вывода хотел заменить https://wasm.in/threads/hardware-dos-machine.33486/ ну то же самое в принципе, забрать аргументы в обработчике исключений, отправить на обработку, продолжить исполнение.

 

f13nd,

Пока он сам не скажет ты не узнаешь. Этот человек мыслит по своему

 

Елe догадался, о ком речь…
(Гвоздями не пахло…)

Идея уходит ещё в бородатые годы эпохи «РАДИО-86РК»…
У него портов ввода-вывода вообще не было, так как всё проецировалось в память.
И хотелось (хотя бы мысленно) провести эксперимент, где один РЛК имеет 256 портов через нормальные IN/OUT-инструкции, но вместо различных УВВ/ПДП и прочей элементарной лабуды каждый из 256 портов ссылается на свой другой РЛК из 256.
То есть, имеется 32 компьютера «Специалист», 32 компьютера «Орион-128», 32 компьютера «ZX-Spectrum» и т.д…
И всем этим хозяйством заведует один центральный РАДИО-86РК - компьютер №257!

Скажем, читает он порт №34. Это - «Орион-128» второй из 32. Сам РАДИО-86РК через пин WAIT процессора уходит в ожидание…
А в Орионе срабатывает прерывание, он может на экране у пользователя что-то спросить и ждать ответ.
Когда пользователь ответит, результат через код вернётся обратно центральному РАДИО-86РК и сигнал WAIT снимется.
Тем самым, при единственном чтении/записи порта центральный компьютер может уйти в ожидание на минуты/сутки/годы…

Поэтому меня не пугает, что обработка исключений может занять миллиарды тактов на порт.

Мне важно, чтобы процесс работал в совершенно чистой среде (без обратной PC-совместимости).
Тем самым, ни портов (стандартных) быть не должно, ни FPU.
А под портами должны скрываться другие (системные/прикладные) процессы.

Допустим, порт №1296126547 (не забывайте: я читаю EDX целиком все 32 бита) адресует ПК на планете Марс (индекс порта в хексу переведите) и ответ может прийти минимум - только через 4 минуты (в хороших условиях). И это значит, что приложение при чтении этого порта может уйти в ожидание на несколько минут.
Это плохо? Если программист - олух и его программа только и занимается Марсианскими-транзакциями, безусловно - да!
Но если программист серьёзно всё спланировал, то 4 минуты простоя в сутки - это нормально.

Но, боюсь, Вы вообще сейчас заблудились в моих «грёзах»…

P.S.: Тайм-аут (переварите пока это)…

 

Придумай инструкцию х86?
Я бы сделал инструкцию типа COMISS для FPU, для условных переходов, а то как то геморрно сделано.
Так же, обратную инструкцию для BT, т.е. установить бит в слове из флага CF.
Flag32 flag = 0;
flag.set(5, foo(param0));
Кодируется одной инструкцией, а не кучей.

 

Нa заметку: MOV TR - Давно просто вызывают исключения.
(Это для себя в рамках «эскейпно-портового» безобразия…)

 

к #269 FCOMI(P) FUCOMI(P) ? и даже есть FCMOVcc все для стековых регистров.

 

Что тут придумывать?
Я половину этих инструкций не знал:

И вспоминаю, была тут когда то задача (тема) которая оказывается решалась одной инструкцией PEXT.

 

Эти инструкции не безумные, просто узкоспециализированные. Часть из них дико поздние (rdseed судя по всему с 2012 года), поэтому ради обратной совместимости они наверное вообще никем не используются. У того же pshufb просто адовый потенциал например для конвертирования BE-LE сразу нескольких полей (в ip например все в BE кодируется), но это sse3 и 2004 год.

 

Кстати, раньше вроде говорили, что собираются добавить отдельные инструкции для AES и GZIP алгоритмов прямо на проце. Это уже сделали или все еще планируют сделать или я что-то попутал?

 

Rel,
aes давно уже есть.

 

Инструкций как раз два десятка и одна из них хороша.
Исходники на асм / SOURCE > ASM 1 - 21 .txt

 

их добавили еще году в 2008 вроде, или чуть позже, гугли AES-NI. Даже локеры какие-то были, что это юзали.

 

Для работы с юникодом, например.

 

Вoт не знаю, может кто подскажет?
В сети очень много сервисов онлайн-отладки, включая интерактивные, как вот этот, например.
Но вот ознакомиться с некогда популярной MMX-технологией всё так же сложно.

И я решил потратить весь выходной и сделать шуточный симулятор (не эмулятор) MMX-инструкций.
Суть симуляции в том, что я взял свою оболочку эмулятора с ассемблером и переделал всё так, чтобы уже на уровне ассемблера MMX-операции не переводились в машинный код, а исполнялись. При этом ведётся лог всех MMX-регистров и снимки их состояний сохраняются и закрепляются за конкретной строчкой листинга.
Перемещаясь кареткой по листингу мы перемещаемся по истории лога трансляции ассемблера в симуляцию.
Не ручаюсь за корректность работы всех команд, так как за один выходной всё не отладишь.
Да и список инструкций не полный: Лишь те, что использованы в конкретном алгоритме листинга…

P.S.: Попробовать скрипт в работе можно по этой ссылке…

 

Позвольтe поинтересоваться!

Нa сколько актуальна сейчас информация по оптимизации, в частности, изложенная в статьях форума?
На предварительных проверках онлайн этот код не уступает этому, но показывает неудовлетворительный результат холостого (без отрисовки) Брезенхэма, даже при несущественном количестве меток.
(Алгоритм адаптирован от MMX на стандартные x86-инструкции в качестве эксперимента для запуска на старых ПК.)

Спасибо!