Первый шаг. Основной цикл ВМ.

Что должна делать виртуальная машина? Она должна принять на вход программу, в виде некоторой последовательности команд, и выполнить ее. Процесс чтения команды, ее распознавания и выполнения циклический и может быть описан обычным циклом языка программирования. Что еще важно? Важна скорость выполнения. Сегодня можно позволить себе немного проиграть в памяти, но достичь максимального быстродействия. А иначе для чего использовать Си, чтобы при этом писать тормозной код? 

А теперь небольшие кусочки кода.
В виде чего будет представлена наша ВМ в коде на языке Си? В виде одной единственной переменной структурного типа. В нашем коде имя этой переменной эта_ВМ. А если еще точнее, то это имя указателя на эту переменную.
Внутри этой структуры есть член с именем регистр_команд. Это указатель на текущую команду. Тогда как будет выглядеть цикл ВМ?

  для( ;  эта_ВМ -> регистр_команд -> структура_команды.операция != СТОП; эта_ВМ -> регистр_команд++ ) 
{
    таблица_вызовов[ эта_ВМ -> регистр_команд -> структура_команды.операция ](эта_ВМ);
 }

Всё. Это весь цикл ВМ. Если кто-то знает, как можно сделать быстрее, пишите.
Разберем, что происходит внутри цикла. Мы вызываем функцию, указатель на которую лежит в ячейке массива с именем таблица_вызовов. Еще раз, в массиве лежат адреса малюсеньких функций, каждая из которых делает единственное действие. (например: поместить в регистр А сумму регистра А и регистра Б). Тогда возникает вопрос, а как нам найти нужную функцию в этом огромном массиве? По индексу, который мы извлечем из прочитанной команды.

Отредактировано Евгений (2023-03-20 21:38:35)

В отличии от MMIX я хочу "ужать" размер команды до 16-бит. Вернее не самой команды, а ее операционной части (оперкод + адреса регистров). Мне это нужно, чтобы таблица указателей не "раздулась" до невероятных размеров.

Отредактировано Евгений (2023-03-20 22:42:57)

Поскольку полное число различных вариаций команд скорее всего будет четырехзначным, то писать это вручную будет мягко говоря утомительно. И вот тут я и хочу сделать и использовать некий программный генератор.
Осталось решить, как оптимальнее распорядиться 16-ю битами.
Пока в мыслях сделать такую структуру: ОП Р1 Р2 Р,
где ОП - оперкод, занимающий 7 бит,
Р1, Р2 - регистры операнды по 3 бита,
Р - регистр, куда помещаем результат тоже 3 бита.
В результате у нашей ВМ получается восемь 64-битных регистров общего назначения, их можно дополнить восьмью регистрами для операций с плавающей точкой. И на все это богатство 128 команд.

Лис не уловил идею. У меня только число ячеек в таблице 65 тысяч. Каждый дополнительный бит удваивает таблицу.

Даже спорить не буду... Если у Лиса есть место на 2**32 * 8 Байт в оперативной памяти. Но это не значит, что нельзя сделать больше. Просто нельзя это сделать предложенным способом.
И зачем нам 256 регистров, если у них такая же скорость, как у ячейки памяти? Все же эмулятор железного процессора и эмулятор упрощенного процессора это разные вещи.

Отредактировано Евгений (2023-03-21 01:00:50)

Хорошо, сколько Лис хочет регистров при максимальном быстродействии? При определенном пороге быстродействие упадет в 6-8 раз.
Если очень грубо 8 регистров 0.5 МБ
16 регистров 4 МБ
32 регистра  32 МБ
64 регистра 256 МБ
128 регистров 2 ГБ
256 регистров 16 ГБ

Хотя нет. Нет смысла сейчас спорить. Нужно попробовать этот вариант для 8 регистров и сделать вывод. Там только один файл исходника будет сумасшедший.

Отредактировано Евгений (2023-03-21 01:26:25)

256 регистров нужно однозначно делать другим способом. Но генератор я все равно хочу обкатать. Может придут новые мысли.

Предположение Лиса оказалось верно. Прямая обработка команды (декодирование и выполнение) примерно равна по скорости вызову функции через таблицу. Эксперимент был полезным.
Тестовая ветка для проверки производительности разных вариантов. Комит

Отредактировано Евгений (2023-03-21 21:37:10)

Лис весьма вольно трактует нормативную базу.
Если провести параллель с ГОСТ Р 2.105—2019, то в нем есть такой пункт:

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

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