Как стать автором
Обновить

Комментарии 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 будет более понятно, чем простое число.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории