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

[alone]

Предлагаю всем вместе поломать головы над виртуальной машиной для Z80. Задачи, которые стоят:
1. Код плотнее, чем на Z80.
2. Перемещаемость (помогло бы для ОС с одним окном памяти, где код лежит внизу).
3. Реентерабельность (опять-таки для ОС).
4. Возможность использования ассемблерных вставок с ограничениями.

[Advertiser]

[Raydac]

виртуальная машина для Z80 что бы плотнее перемещаемее и реентабельность это уже придумано более 30 лет назад )) называется FORTH и пишется за пару дней и есть все перечисленное )))
p.s.
правда что бы на FORTH программить надо мыслить в обратной польской записи )))
p.p.s.
Иван Макарченко в остаток альтеры в спринтере forth-процессор зашивал насколько помню

[alone]

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

[Oleg N. Cher]

Трезвой форт-машины для 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. На законченность концепции не претендую — так, сырая идея.

[Barmaley_m]

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

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

[Andrew771]

Код:
DI
LD SP, ExecThread
RET

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

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

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

[b2m]

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

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

[Raydac]

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

[mastermind]

alone, а цели какие? Виртуальная машина для чего? Чтоб исполнять результат трансляции какого-то собственного языка с ассемблерными вставками?
Кроме п.1 из перечисленных не вижу зачем нужна именно виртуальная машина. П. 2 - вопрос дизайна/реализации загрузчика/OS, п. 3 - вопрос реализации того куда нужна эта реентерабельность , п.4 - в том же LLVM это более чем предусмотрено (см. http://blog.llvm.org/2010/04/intro-t...c-project.html про "Compiler-Integrated Assembler")

Я к тому что для достижения п.1 (для всего остального ВМ не обязательно) с помощью LLVM можно сделать решение еще лучше.
Можно сделать сначала просто бэкенд (таргет) для Z80, а затем на основе него сабтаргет (subtarget) с дополнительным набором "инструкций" (для экономии памяти), генерирующий прологи/эпилоги для нативного кода и т.п. + виртуальную машину для исполнения результата. (кстати, можно еще для всяких акселераторов и т.п. псевдоинструкции делать )
В результате можно получить не "виртуальную машину с возможностью использовать ассемблерные вставки", а компилятор чего угодно в желаемый байткод в перемешку с нативным кодом (т.е. когда ради "кода плотнее" нет смысла использовать байткод, компилятор может генерить нативный код), ну и возможность использовать ассемблерные вставки никуда не денется. Если хочется еще какой-то свой язык специфичный, фронтэнд можно сделать.

Документации (и кода, т.к. не поспевает документация за изменениями), конечно, дофигища придется перечитать. Я читал/копался немного, голова кругом идет от объема информации, но могу сказать что штука очень хорошо задизайненная и крайне гибкая. Всем желающим делать какие либо виртуальные машины для чего угодно, компиляторы или JIT-ы (или все сразу), категорически рекомендую Отличный framework для всех перечисленных целей (и более того).

Инструкция по разработке backend-ов: http://llvm.org/docs/WritingAnLLVMBackend.html
Примеры реализации см. в исходниках в llvm/lib/Target (X86, естественно, самый вылизанный бэкенд на данный момент)

[Raydac]

на местном форуме я уже лет семь и могу сказать что тут всегда есть только одна проблема ))) куча народа предлагает какое то клевое решение или идею но никто (!) не догадывается что можно это запрограммить и показать как макет )))