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

[NovaStorm]

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

[Advertiser]

[James DiGreze]

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

[NovaStorm]

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

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

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

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

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

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

[GriV]

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

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

[mastermind]

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

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

[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битное АЛУ.

[NovaStorm]

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

Не, я про машкод. Обращаться к локальным переменным через индексные регистры проще и быстрее всего на Z80, кажется.

Хорошо, пусть будет 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 */

Ну это зависит от системы команд, хоть с непосредственной адресацией одной инструкцией со значениями сразу.
Вот на http://en.wikipedia.org/wiki/Threaded_code дофига вариантов рассмотрено.

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

Согласен, сначала низкий уровень, а вот IO уже наверное можно и виртуализовать. Но уже на памяти можно на это дело начинать забивать из-за тормозов, по сравнению с машкодом.

[bigral]

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 */

Я написал что стек нафиг не нужен как понятие и никто не заметил? Ну зачем он надо?

Вот к примеру в приведенном куске первая команда какую пользу приносит? Не проще ли заменить команды такого типа на 1 типа:
1 "выделить из кучи место и инициализировать его массивом байтов: 0x35, 0x39, 0x30" return addr
2 "умножить первый байт массива по addr на следующее за ним слово и результат вписать на их место"

Конечно стек прикольный тем что результат операции всегда в известном месте как и параметры для операции и это свойство на 100% используется forth-ом или java или этим: http://homepages.cwi.nl/~steven/pasc...k/10pcode.html

НО! в нашем случае можно от него отказаться так как команды не будут такими простыми как mov a,b а будут оперировать сразу кусками памяти минимум по несколько байт! кроме того сначала будет ити внушительный кусок который должен будет сначала обьявить что команды делают (тут можно простой язык применить с mapping-ом на z80 asm 1:1)

[James DiGreze]

1 "выделить из кучи место и инициализировать его массивом байтов: 0x35, 0x39, 0x30" return addr
2 "умножить первый байт массива по addr на следующее за ним слово и результат вписать на их место"

Те же яйца, в анфас. Выделение памяти есть? Есть. Потом результат откуда брать? Типа ссылка? А потом как понять что данные уже нафиг надо удалить? Опять передавать ссылку и удалять ее из списка. Где выгода?

alone, своими мыслями поделись! А то мы тут уже скоро на кофейной гуще гадать начнем

[GriV]

Ребята, вы вначале ТЗ составьте (убейте), а потом уже делите способ реализации (медведя). Я тут набор функций предлагаю, никто не поддержал, зато все ринулись в кодерство. Вначале думаем, потом кодим.