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

[NovaStorm]

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

Ну если про самомодификацию мы забыли, то неужели каждый раз считать адреса?
С IX/IY вполне хорошая скорость при минимуме объёма достигается. Или я ещё способы упускаю?

Ну не скажи! Банальное printf("Hello, peoples!"), будет в коде Z80 довольно витиевато выглядеть.

Пример с printf, по-моему, самый неудачный, наверное, из всей стандартной библиотеки =)

Про скорость... тут надо определиться с областью применения.
...
Зачем так усложнять? Игры писать что-ли, али демки?

Ну АлКо хочет, как я понимаю, ВМ и язык под неё общего назначения, и скорость тут будет играть весьма значительную роль.

[Advertiser]

[James DiGreze]

Ну если про самомодификацию мы забыли, то неужели каждый раз считать адреса?
С IX/IY вполне хорошая скорость при минимуме объёма достигается. Или я ещё способы упускаю?

Самомодификацию байткода, я правильно понял?

Пример с printf, по-моему, самый неудачный, наверное, из всей стандартной библиотеки =)

Хорошо, пусть будет uint32_t mul(uint16_t op1, uint16_t op2), или код x=mul(12345, x) , которое к примеру байткодом можно выразить так:

0x22, 0x35 /*copy var #35 and push result to stack */
0x25, 0x39, 0x30 /* push 12345 to stack */
0x49 /* mul stack */
0x32, 0x35 /*copy result from stack to var #35 */

Ну АлКо хочет, как я понимаю, ВМ и язык под неё общего назначения, и скорость тут будет играть весьма значительную роль.

Вот я и пытаюсь понять, чего точно хочет AlCo.

0 - печать следующей за ним аскии-Z строки в активное окно
1 - создание окна, указываются начало X,Y, длина ширина
2 - выбор активного окна, следующий байт - номер окна
3 - очистка окна
4 - ассемблерная вставка
5 - операция работы с переменными, тут непонятно как что. Предлагайте варианты.

Имхо, слишком высокоуровнево пошел. Для начала простые операции с целочисленными переменными, потом работа с памятью и портами I/O, и уж потом всякие текстовые штучки.

Ну так система команд делалась под довольно ограниченное ALU

Точнее сказать 4битное АЛУ.

[mastermind]

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

Ну так система команд делалась под довольно ограниченное ALU. Сейчас же в байткоде можно предусмотреть, скажем 16-, 32- и т.д. разрядную арифметику, FP, более продвинутые логические, сдвиговые и пр. операции и т.п. За счет одного этого код можно сильно уплотнить.

[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 кб максимум). Тогда проблема перемещаемости будет решена за счёт отсуствия машинного кода. Проблема реентерабельности тоже. Останется маленький вопрос разработки транслятора

[alone]

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

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

[NovaStorm]

>адрес возврата, который надо релоцировать
Ну положи туда виртуальный адрес, делов-то. Только если после вычисления реального прога будет перемещена ещё раз, тут-то мы и приплыли.
Или вот как, например, сделать простой инкремент переменной? Нельзя же мутексы на каждый чих городить.

[James DiGreze]

alone, пусть ляжет, оно ему как раз в прок.
Вспомни как калк бейсика 48 работает: попается адрес возврата, и оттуда начинает интерпретироваться байткод, до всречи на своем загогулистом рета самого калка. Тут тот же механизм будет как раз в пору. Ну и нужно сразу разделить понятия аппаратного стека Z80 от стека байткод интерпретатора.
Мне вот тут подумалось, что на самом деле можно реализовать практически интерпретатор Си. Просто за счет функций преобразования ссылок и динамического создания копий переменных.
А еще подумалось, что вот же были башковитые мужики, кто это все придумывал с нуля. И реально копаясь в своей памяти могу только пару своих личных изобретений вспомнить, причем не в компьютерной области, а все остальное либо компиляция информации, либо реверсинжениринг по внешнему виду.

[GriV]

Предлагаю следующую систему:
байт-код:
0 - печать следующей за ним аскии-Z строки в активное окно
1 - создание окна, указываются начало X,Y, длина ширина
2 - выбор активного окна, следующий байт - номер окна
3 - очистка окна
4 - ассемблерная вставка
5 - операция работы с переменными, тут непонятно как что. Предлагайте варианты.

По п.4 соглашения - запрешён самомодифицируемый код, запрещены сложные стековые операции, все доп. адресации через индексные регистры.
Какие ещё функции надо?