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

[alone]

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

[Advertiser]

[Raydac]

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

[alone]

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

[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]

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

[alone]

Цель такая: загнать многозадачную ОС в 128К. Пока нет решения, предлагаю закрыть вообще тему многозадачной ОС на 128К. Если есть как минимум два окна (ATM Turbo, NeoGS) такие вопросы не встают.

Впрочем, задача создания плотного кода интересна для разработки прошивок ПЗУ со всякими командерами, дискдокторами и т.п., где скорость не важна, а места мало.

[mastermind]

Raydac, я делюсь информацией о которой знаю. Для реализации вышеописанного у меня лично не хватает ни времени ни мотивации, но не хочется чтоб кто-то кто возьмется что-то такое делать, изобретал велосипед, когда уже есть отличный инструментарий.
А "макетов" в общем-то предостаточно , только не для Z80, ссылку на демо одного из них я давал.

---------- Post added at 17:50 ---------- Previous post was at 17:40 ----------

Цель такая: загнать многозадачную ОС в 128К. Пока нет решения, предлагаю закрыть вообще тему многозадачной ОС на 128К. Если есть как минимум два окна (ATM Turbo, NeoGS) такие вопросы не встают.

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

[Eltaron]

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

Большинство средств это как раз умеет. Ассемблер из GNU Binutils для z80 генерирует COFF, Си-компилятор gcc генерирует даже ELF. Оба формата содержат всю информацию о тех участках кода, куда нужно добавить какое-нибудь смещение при релоцировании.
ELF перебор, а вот COFF поддержать на спекки милое дело
sdcc тоже генерирует какой-то перемещаемый формат, но свой, не стандартный.

[mastermind]

Это вышеупомянутое "большинство" часто спектрумистами используется? Я неточно выразился, конечно. Имел ввиду наиболее употребляемые средства.
ELF да, наверное слишком громоздок. А хотя бы загрузчики COFF есть на спеки, интересно, хоть в каком-то виде?