Комментарии 13
Я правильно понял, что у вас только на сам опкод (тип инструкции) уходит 32 бита, и каждый аргумент (например, тип условия в бранче) - тоже 32 бита? Несколько расточительно )
Для упрощения, как кода эмуля, так и системы комманд - это неплохо. Я время от времени балуюсь с написанием эмуля своей вымышленной архитектуры, он восьмибитный, что даёт нам 255 команд(8 бит на команду, жетско). И я туда очень многое впихнул, включая работу со стеком и условные переходы.
Согласен, как первоначальная база вполне неплохо. Но один из вариантов дальнейшего развития - добавить выдёргивание битов опкода и аргументов из инструкции, чтобы поддержать хотя бы RV32I.
А так то можно обойтись одной инструкцией без явного опкода )
там только одно поле name 24+ байта? а со всеми полями так и и под полтинник спокойно может быть. все эти опкоды должны были быть каким-нибудь enum clasы и с прикрученными ассоциативными таблицами про количество аргументов, про имя и прочее. Оно и в кэше лежало б хорошо и по памяти эффективнее вышло бы.
name (имя опкода) нужно для отладки, оно не хранится ни в бинарниках, которые эмулятор исполняет, ни в памяти виртуальной машины. В бинарнике, например, mov 01, 05 запишется как 02 00 00 00 01 00 00 00 05 00 00 00 (если хост little-endian), и это напрямую будет загружено в память ВМ, никакие имена там не хранятся
Про память, потребляемую самой ВМ у хоста да, так было бы эффективнее, как Вы описали
Это эмулятор, какие еще оптимизации по памяти?
выбирая между эмулятором, который на запуске кушает гигабайт оперативки и тем, который кушает всего 10 мегабайт при прочих равных сдаётся мне многие предпочтут именно второй вариант. Есть ещё конечно джависты и джаваскриптеры с нодой, но у них задачи обычно другие.
Да, лучше конечно по памяти чтобы не так много было накладок. Но моя цель была скорее знания систематизировать по архитектуре компьютера, связать их в нечто рабочее, чем выпускать эмулятор в продакшн
Та к вам претензий не имею. Для начала неплохо. Есть странные решения типа сырых указателей на массивы и фабрики всякого, но это уже скорее придирки.
В принципе там и uint8_t хватило бы за глаза, просто чтобы упростить архитектуру, чтобы cpu мог вытаскивать из памяти опкод и его аргументы с использованием одной функцией get_data, но в принципе можно и переделать под uint8_t опкоды и завести для опкодов и аргументов отдельные функции чтобы достать их из памяти, спасибо за идею
Для регистров, в дальнейшем, выберите имена. Даже банальное r0-r15 будет более понятно, чем простое число.
Пишем простую виртуальную машину (1я часть. Минимально работоспособный код эмулятора)