Нужна виртуальная машина на ZX

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

Там получился такой набор команд:

opCallFunction - вызвать стандартную функцию
opCallMethod - вызвать метод класса
opCall - вызов собственный метод (подпрограмму)
opPushSelf - поместить в стек this (указатель на свой объект)
opJmp - перейти на строку
opLongJmp - перейти на строку и освободить стек
opRet - завершить выполнение

Далее обработка исключений.

Для каждой команды указан адрес, куда следует перейти, если произошло исключение. А так же, что следует удалить из стека. После освобождения стека, в стек кладется объект Exception с описанием ошибки.

И опкоды, которые используются только в блоках FINALLY..END или EXCEPT..END (catch...end):

opTryFinallyEnd - если на верхушке стека лежит не NULL, то исключение. Иначе освободить стек.
opThrow - сгенерировать исключение по объекту лежащему в стеке.
opGetExceptionText - поместить в стек текст исключения из объекта лежащего в стеке.

Далее идут команды для работы с типами данных VARIANT, OBJECT, INTEGER, FLOAT, BOOLEAN, STRING, CURRENCY ...

Например набор команд для Integer:

opPush_i - Поместить в стек непосредственное значение
opPop_i - Освободить стек от Integer (увеличить указатель стека на sizeof(Integer))
opPushVar_i - Из переменных в стек
opPopVar_i - Сохранить из стека в переменные
opPushObj_i - Из объекта в стек
opPopObj_i - Из стека в объект
opDup_i - Дублировать значение в стеке

opAdd_i,opSub_i,opMul_i,opDivInt_i,opDiv_i,opMod_i ,
opAnd_i,opOr_i,opXor_i,opCmpE_i,opCmpNE_i,opCmpL_i ,
opCmpG_i,opCmpLE_i,opCmpGE_i,opCmpNEX_i,opNeg_i,
opShl_i, opShr_i - эти команды производят операцию с парой чисел на верхушке стека так, что остается одно число.

Да, а команда условного перехода всего одна. Она в наборе команд Boolean:

opJt_b - Перейти, если TRUE.

Но оптимизатор пораждает массу команд перехода. Например, opNeg_b + opJt_b заменяет на opJf_b

В результате оптимизации может рождится команда типа:
opPushVar_i_opPush_i_opCmpE_opJf_i(A, B, C)
которая вообще не работает со стеком. Она выполняет действие
if(variables[A] == B) ip += C;

Или вот пример оптимизации получения элемента массива:
opPush_i 0
opPushObj_o номер
opPushVar_i номер
opCallMethod arrayOfInteger::getItem
opPop_i
opPop_o
Заменяется на единственный опкод:
opArrayOfIntegerGet_o_v(A,B)
Который выполняет действие:
ArrayOfInteger* a = objectVariables+A; if(B>=a->count) throw_bound(); *st++ = a->items[B];

Эти все оптимизации ускоряют работу, но размер исходника интерпретатора занимает несколько сотен килобайт.

Griv, это кто же это кинулся в кодерство? Я написал "от фонаря" байт код, типа с пояснениями, в стековой реализации, которая на мой, может быть не хужее "хипной". А ТЗ мы уже похерили, только вот медведь не делится на ноль, хоть тресни меня битой в лоб ;)
Уже несколько раз перечитал первый пост AlCo, возникло подозрение, что первоначальная мысль была отнюдь не за байт-код, а именно некоторое подобие муляции кода Z80 с возможностью дополнения новыми командами а-ля префикс типа неиспользуемого rst x.
AlCo, выходи уже из раздумий, а то я пошел за варенным кофе!

Цитата:

---

Сообщение от NovaStorm

Код плотнее Z80 сделать будет трудно, над этим думали создатели и 8080, и Z80.

---

Даже код калькулятора бейсика плотнее. См. питона в Info Guide #10.

У меня пока идей нет. Байт-код явы мне весьма понравился.

Цитата:

---

Сообщение от alone

Трезвой форт-машины для Z80 не знаю. Покажите процедуру NEXT.

---

Есть одна идея, как можно реализовать наиболее быстрый вариант виртуальной машины на Z80 — может и не по всем пунктам, обозначенным топикстартером, но вариант интересный. Судите сами.

Это аналог Форт-машины с прямым шитым кодом. Подпрограммный шитый код мы не рассматриваем, потому что это фактически подмножество машинного кода, просто организованный массив подпрограмм со своей логикой.

1. Код плотнее, чем на Z80.

Отчасти, да. Интересные вещи писали авторы отечественных Форт-систем о компактности фортовского шитого кода, который превосходил реализации с машинным кодом.

2. Перемещаемость (помогло бы для ОС с одним окном памяти, где код лежит внизу).

Нет, потому что код шитый. Или разве что да, но будет требоваться простая настройка адресов, что не должно вызвать проблем.

3. Реентерабельность (опять-таки для ОС).

Вероятно, это можно реализовать.

4. Возможность использования ассемблерных вставок с ограничениями.

Безусловно.

Прямой шитый код Форт-машины — это последовательность адресов вызываемых подпрограмм на Форте или в машинном коде. Для Z80 может выглядеть примерно так:

Код:

---

DW LITERAL_BYTE ; Заносим на стек
DB 5 ; число 5
DW DUP ; Дублируем значение на стеке
DW MULT ; Умножаем само на себя (возводим в квадрат)
DW EMIT ; Печать числа

---

Вероятно, большой проблемой будет слово NEXT, от которого сильно зависит скорость работы всей машины. (NEXT передаёт управление следующему за текущим словом. Вероятно, имеет смысл модифицировать шитый код для большей производительности слова NEXT, если это вообще возможно. Моё предложение имеет один минус, который многим покажется критичным. Тем не менее, всё-таки посмотрите, что предлагается.

Код:

---

DI
LD SP, ExecThread
RET

DW EMIT ; Адреса слов потока исполнения, но в обратном порядке
DW MULT
DW DUP
DB 5
DW LITERAL_BYTE
ExecThread: ; Сюда устанавливается верхушка стека

---

В такой реализации словом NEXT в шитом коде будет адрес, указывающий на RET (и обычный RET в машинных подпрограммах). Не все проблемы решены. Остаются трудности с вложенными вызовами шитого кода из шитого кода (или из машинной подпрограммы) — нужно куда-то сохранить адреса возврата. Значит нужен стек, притом не SP, ибо он активно занят другими делами. Если вложенность гарантированно будет одинарная (ну, такой гипотетический случай), должно хватить одного регистра под это. Например, IY.

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

Плюсы решения: при запрещённых прерываниях не нужно на них отвлекаться процу — код будет работать быстрее. Второй плюс — такая машина может быть регистровой, а не стековой, как Форт. И параметры будут передаваться в регистрах.

Практическое применение этой идее наверно найти трудно, но вдруг у кого-то появится мысль как её усовершенствовать.

P.S. На законченность концепции не претендую — так, сырая идея.

А что бы и не JP (HL)? Да и это всё равно мелочи реализации.

Oleg N. Cher, Идея неплохая
рекомендую также посмотреть игру IronLord от UbiSoft

Разумеется изнутри
есть вероятность что либо Форт либо какой то свой язык

Код:

---

DI
LD SP, ExecThread
RET

---

Вот подумалось тут ещё, а адреса-то должны быть виртуальными...

Олег, данная концепция именно в том виде, как вы описали, используется в ксорке-защите от Max Iwamoto. Можно посмотреть во многих его Cracktro к играм. На стеке лежала куча адресов, каждый из которых указывал на коротенькую подпрограмму, заканчивавшуюся, как правило, командой RET.

Максом Ивамото, конечно, преследовалась цель не уплотнить код, а запутать его. Но эта задача не была им решена. Стоит только разобраться с основной идеей, что на стеке расположена фактически программа из инструкций, семантика которых задается лежащими на стеке адресами подпрограмм - как все становится понятно, а изучающий эту защиту получает чувство глубокого удовлетворения от знакомства с красивой концепцией и легкостью, с которой он ее взломал. Каждой "инструкции" присваивается мнемоника, потом адреса подпрограмм заменяются на эти мнемоники - и вуаля, программа как на ладони. Там и циклы были, и условные переходы и, конечно же, регистр R.

а сейчас это называется Return Oriented Programming и широко используется во взломах программ.

Цитата:

---

Сообщение от Oleg N. Cher

Код:
DI
LD SP, ExecThread
RET

DW EMIT ; Адреса слов потока исполнения, но в обратном порядке
DW MULT
DW DUP
DB 5
DW LITERAL_BYTE
ExecThread: ; Сюда устанавливается верхушка стека

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

---

А почему прерывания должны быть запрещены?
*(Извините, если что, башка от жары перестала варить)

Ну как же. На стеке лежат адреса подпрограмм, переход на них осуществляется командой RET. А любое пришедшее прерывание сразу затрёт адрес, как минимум, своим адресом возврата.

Цитата:

---

Сообщение от Andrew771

А почему прерывания должны быть запрещены?

---

Потому, что SP указывет тут не на стек, а на программу. Если возникнет прерывание, программа испортится (будет записан адрес возврата).
И кстати, "Адреса слов потока исполнения" должны быть как раз в прямом порядке. RET увеличивает указатель SP.

Вроде дошло, спасибо!
Может тогда при разрешенных прерываниях в процедуре прерывания вначале сохранять кусок стека, а затем в конце перед выходом восстанавливать?

Так было бы можно в случае более глубокого использования стека. Но на одно (то самое, для адреса возврата) слово стек будет испорчен всегда. До сохранения ещё дело не дошло. В этом-то и проблема.

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

Цитата:

---

Сообщение от Lethargeek

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

---

Можешь подробнее описать, каким образом?

Самый простой способ - держать копию программы, и в прерывании восстанавливать повреждённые байты.

Цитата:

---

Сообщение от Andrew771

Можешь подробнее описать, каким образом?

---

да что там описывать, условно разбиваешь подверженную порче память на блоки размером, допустим, по 256 байт
для каждого блока вычисляешь эталонную двухбайтную контрольную сумму или две ксорки (для чётных и нечётных байт)
в обработчике прерывания находишь по адресу в sp блок, вычисляешь для него новую контрольную сумму/ксорки
восстанавливаешь испорченные два байта по разнице с эталоном (предварительно забрав оттуда адрес возврата)

и неважно, какой смысл имеют данные в блоке: например, в commando ксорки применяются аналогично для восстановления спрайтов

Цитата:

---

Сообщение от b2m

Самый простой способ - держать копию программы, и в прерывании восстанавливать повреждённые байты.

---

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