Вид для печати
>адрес возврата, который надо релоцировать
Ну положи туда виртуальный адрес, делов-то. Только если после вычисления реального прога будет перемещена ещё раз, тут-то мы и приплыли.
Или вот как, например, сделать простой инкремент переменной? Нельзя же мутексы на каждый чих городить.
alone, пусть ляжет, оно ему как раз в прок.
Вспомни как калк бейсика 48 работает: попается адрес возврата, и оттуда начинает интерпретироваться байткод, до всречи на своем загогулистом рета самого калка. Тут тот же механизм будет как раз в пору. Ну и нужно сразу разделить понятия аппаратного стека Z80 от стека байткод интерпретатора.
Мне вот тут подумалось, что на самом деле можно реализовать практически интерпретатор Си. Просто за счет функций преобразования ссылок и динамического создания копий переменных.
А еще подумалось, что вот же были башковитые мужики, кто это все придумывал с нуля. И реально копаясь в своей памяти могу только пару своих личных изобретений вспомнить, причем не в компьютерной области, а все остальное либо компиляция информации, либо реверсинжениринг по внешнему виду.
Ну если про самомодификацию мы забыли, то неужели каждый раз считать адреса?Цитата:
Сообщение от James DiGreze
С IX/IY вполне хорошая скорость при минимуме объёма достигается. Или я ещё способы упускаю?
Пример с printf, по-моему, самый неудачный, наверное, из всей стандартной библиотеки =)Цитата:
Сообщение от James DiGreze
Ну АлКо хочет, как я понимаю, ВМ и язык под неё общего назначения, и скорость тут будет играть весьма значительную роль.Цитата:
Сообщение от James DiGreze
Предлагаю следующую систему:
байт-код:
0 - печать следующей за ним аскии-Z строки в активное окно
1 - создание окна, указываются начало X,Y, длина ширина
2 - выбор активного окна, следующий байт - номер окна
3 - очистка окна
4 - ассемблерная вставка
5 - операция работы с переменными, тут непонятно как что. Предлагайте варианты.
По п.4 соглашения - запрешён самомодифицируемый код, запрещены сложные стековые операции, все доп. адресации через индексные регистры.
Какие ещё функции надо?
Ну так система команд делалась под довольно ограниченное ALU. Сейчас же в байткоде можно предусмотреть, скажем 16-, 32- и т.д. разрядную арифметику, FP, более продвинутые логические, сдвиговые и пр. операции и т.п. За счет одного этого код можно сильно уплотнить.Цитата:
Сообщение от NovaStorm
Самомодификацию байткода, я правильно понял?Цитата:
Сообщение от NovaStorm
Хорошо, пусть будет uint32_t mul(uint16_t op1, uint16_t op2), или код x=mul(12345, x) ;), которое к примеру байткодом можно выразить так:Цитата:
Сообщение от NovaStorm
Код: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.Цитата:
Сообщение от NovaStorm
Имхо, слишком высокоуровнево пошел. Для начала простые операции с целочисленными переменными, потом работа с памятью и портами I/O, и уж потом всякие текстовые штучки.Цитата:
Сообщение от GriV
Точнее сказать 4битное АЛУ.Цитата:
Сообщение от mastermind
Не, я про машкод. Обращаться к локальным переменным через индексные регистры проще и быстрее всего на Z80, кажется.Цитата:
Сообщение от James DiGreze
Ну это зависит от системы команд, хоть с непосредственной адресацией одной инструкцией со значениями сразу.Цитата:
Сообщение от James DiGreze
Вот на http://en.wikipedia.org/wiki/Threaded_code дофига вариантов рассмотрено.
Согласен, сначала низкий уровень, а вот IO уже наверное можно и виртуализовать. Но уже на памяти можно на это дело начинать забивать из-за тормозов, по сравнению с машкодом.Цитата:
Сообщение от James DiGreze
Я написал что стек нафиг не нужен как понятие и никто не заметил? Ну зачем он надо?Цитата:
Сообщение от James DiGreze
Вот к примеру в приведенном куске первая команда какую пользу приносит? Не проще ли заменить команды такого типа на 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)
Те же яйца, в анфас. Выделение памяти есть? Есть. Потом результат откуда брать? Типа ссылка? А потом как понять что данные уже нафиг надо удалить? Опять передавать ссылку и удалять ее из списка. Где выгода?Цитата:
Сообщение от bigral
alone, своими мыслями поделись! А то мы тут уже скоро на кофейной гуще гадать начнем ;)
Ребята, вы вначале ТЗ составьте (убейте), а потом уже делите способ реализации (медведя). Я тут набор функций предлагаю, никто не поддержал, зато все ринулись в кодерство. Вначале думаем, потом кодим.