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

[bigral]

Вложенность вызовов требует стека. Надо же знать, куда возвращаться после подпрограммы!

Подпрограммы не нужны если есть "макросы" которые длинной как и все другие команды processor-a (в данном случае виртуального). В том же forth-e ничего такого нету, там каждое "слово" всего лишь ID соответствующего куска кода который может включать и другие "слова". Сначала идет define "слов" а потом прога из последовательности "слов" (все эти "слова" по сути подпрограммы). Как я понимаю postscript тоже похож.

И вот еще что. Не выйдет никакого virtual Z80 на 48k это может быть другой VM заточенный изначально на переносимость\hibernate-restore возможности.

Тормоз данного софта, если таковой будет написан, будет поражать умы светил этого форума. НО! Скорее всего будет довольно легко запустить его на прикрученном сбоку к спектруму акселераторе в виде какого-нибудь risc cpu на минимальной altera или parallax propeller.

[alone]

Передавать в параметрах?

А параметры где будут храниться? Представьте, что процедура A вызывает процедуру B, а та процедуру C.

[bigral]

А параметры где будут храниться? Представьте, что процедура A вызывает процедуру B, а та процедуру C.

Параметры в стеке - такие же данные как и те что лежат на heap-е ПО СУТИ! (понятно что стек аппаратно поддержан в CPU но в нашем случае это не важно так как речь идет об НАШЕЙ VM в которой можно отказаться от стека). Так что параметры можно передавать либо в регистрах либо через heap.

DATA& param = new DATA(); // выделить на heap место для param, param при этом указатель

procA {
procB(param); // param идет либо в регистре либо как в FORTH-e следующим за "словом" (УКАЗАТЕЛЬ КОМАНДЫ+1)
}
procB(DATA& param) {
procC(param);
}

procС(DATA& param) { }

[GriV]

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

1. Смотря что понимать под плотностью кода: если ты про агрегатные функции типа печать строки/символа, то это ЯВУ или хотя бы уровень Си.
Требование непонятное, скорее всего тут логичнее, как уже советовали, какое-нибудь LZ*. Все биосы (ПО) современных компов сжимаются таким методом.
2. Перемещаемость на этапе загрузки реализована витамином. Смотрим вот и вот. Перемещаемость после загрузки - слишком дорого в тактах процессора.
3. Это сложно. Современные программисты для ZX так не умеют. Они либо экстремально кодят, с самомодифируемым кодом, либо вообще не умеют писать адекватный код. Реализуемо, использовать стек как способ работы и требовать обязательно сохранение данных в некий аналог кучи (heap). Это требование замедляет результирующий код.
4. Таки ты хочешь некое ЯВУ?

[alone]

Параметры в стеке - такие же данные как и те что лежат на heap-е ПО СУТИ!

Вот мы и возвращаемся к написанному выше. Если это адреса, то их надо типизировать при записи в стек, чтобы уметь релоцировать на лету (грубо говоря, пишем в стек не по 2 байта, а по 3: данные+тип). Если это номера подпрограмм, то проще.

Перемещаемость после загрузки - слишком дорого в тактах процессора.

А без этого никак. Если не релоцировать на лету, то после нескольких запусков/снятий задач нижняя память превратится в решето, куда уже ничего не поместится.

Таки ты хочешь некое ЯВУ?

Естественно.

[James DiGreze]

Для начала надо договориться о неперемещении программ во время исполнения.
Условно, если прог1 вызвал на выполнение прог2, то и прог1, и прог2 должны блокироваться на перемещение. При этом если прог1 после прог2 (не из прог2) вызовет прог3, то прог3 может быть перемещен как при работе прог1, так и прог2.

...(грубо говоря, пишем в стек не по 2 байта, а по 3: данные+тип)...

Первый байт: (4бита - тип) + (4бита - длина). Второй и последующие - данные. Правда тогда массивы только ссылками придется передавать, например через команды создания-высвобождения копий.

[GriV]

Предлагаю следющее: у нас уже фактически есть SOS c Басиком, если сделать п/п басика, которая будет выполняться, но храниться при этом в самом ПЗУ?
Расвивая идею, не обязательно ориентироваться на басик.
Надо определить список функций, который необходимы. Затем список операций, которые эти функции будут выполнять. Оттуда строить код, если так хочется. Компилятор это грубо, надо транслятор + парсер. Технически на функции биоса (если они тебе нужны) нужны простые функции вывода символов, построения рамок, менюселектор (это 1-2 кб максимум). Тогда проблема перемещаемости будет решена за счёт отсуствия машинного кода. Проблема реентерабельности тоже. Останется маленький вопрос разработки транслятора

[NovaStorm]

3. Это сложно. Современные программисты для ZX так не умеют. Они либо экстремально кодят, с самомодифируемым кодом, либо вообще не умеют писать адекватный код.

Это, на мой взгляд, довольно просто. Умеют =)
Но не хотят или это не требуется.

Реализуемо, использовать стек как способ работы и требовать обязательно сохранение данных в некий аналог кучи (heap). Это требование замедляет результирующий код.

Да куча тут не причём, это всё на стек-фрейме делается. Сильно код не замедляется, но к локальным переменным таки придётся обращаться через индексные регистры.

---------- Post added at 12:09 ---------- Previous post was at 11:45 ----------

Для хотелок АлКо, думаю, подойдёт гибридный шитый+машинный код. Но! Код плотнее Z80 сделать будет трудно, над этим думали создатели и 8080, и Z80. Гибридизация с машинным однозначно нужна для скорости.
Перемещаемость я пока не вижу способа организовать, тк в спеко-ВМ нельзя малой кровью сделать ни критические секции, ни тегирование.
На полную перемещаемость придётся плюнуть и довольствоваться для дефрагментации памяти перемещением между банками, где у нас есть хоть какая-то виртуальная память.

[James DiGreze]

Сильно код не замедляется, но к локальным переменным таки придётся обращаться через индексные регистры.

Не обязательно, но возможно.

Но! Код плотнее Z80 сделать будет трудно, над этим думали создатели и 8080, и Z80. Гибридизация с машинным однозначно нужна для скорости.

Ну не скажи! Банальное printf("Hello, peoples!"), будет в коде Z80 довольно витиевато выглядеть. Про скорость... тут надо определиться с областью применения. Собственно для рисования простых текстовых менюшек много скорости не надо. Ну ли там каких-нибудь дисковых операций.

Перемещаемость я пока не вижу способа организовать, тк в спеко-ВМ нельзя малой кровью сделать ни критические секции, ни тегирование.
На полную перемещаемость придётся плюнуть и довольствоваться для дефрагментации памяти перемещением между банками, где у нас есть хоть какая-то виртуальная память.

Зачем так усложнять? Игры писать что-ли, али демки? Может тогда сделать проще - дать возможность вызывать интертрепатор байткода из кода Z80? Это будет, на мой взгляд, более рациональным.

[alone]

Может тогда сделать проще - дать возможность вызывать интертрепатор байткода из кода Z80?

При вызове в стек ляжет адрес возврата, который надо релоцировать. Та же проблема, только в профиль.