Небольшой эмулятор RISC

Question

Я хочу встроить виртуальную машину в игру, и мне было интересно, знает ли кто-нибудь о каких-нибудь действительно простых виртуальных машинах (я думал, RISC / PIC близки к тому, что я хотел), которые обычно используются для встроенных проектов, таких как управление роботами, двигателями, датчиками и т.д.Моя главная проблема заключается в необходимости написать компилятор / ассемблер, если я создам свой собственный.Было бы неплохо использовать инструменты, которые уже существуют, или в простейшей форме просто компилятор C, который может скомпилировать для него:-p.

Я действительно не хочу заново изобретать колесо, но мне также нужны тысячи таких, которые бегают по виртуальному миру, поэтому они должны быть как можно более простыми и быстрыми.Как уже упоминал один человек, меня также не волнуют проблемы реального мира, такие как время, автобусы и все такое прочее.Я думаю, что их виртуальные часы будут ограничены чем-то довольно медленным;и в конце концов мне, вероятно, придется заняться нативной компиляцией, чтобы заставить их работать еще быстрее, но пока я просто собираю прототипы, чтобы получить общее подтверждение концепции.

В качестве входных данных я планирую использовать датчики расстояния, освещенности, материала и касания, установленные вокруг цилиндрического корпуса (16, возможно, 32 из них), затем просто 2 двигателя для направленного вывода для управления своего рода колесом с каждой стороны.по сути, обработка не будет слишком трудоемкой, а мир будет достаточно простым, так что машине не придется затрачивать много вычислительной мощности на выполнение простых задач.

Что касается памяти, я бы хотел, чтобы они могли хранить достаточно данных, чтобы их можно было оставить в покое на пару дней без вмешательства для построения карт и сбора статистики.Мне не нравится, что 8bit сократил бы его для обработки или памяти, но 16bit определенно был бы претендентом.32 и 64-битные будут просто нажимать на это, и у них ни в коем случае не будет больше 1 МБ памяти у каждого - вероятно, ближе к 256-512 Кб.(Первый билл сказал, что 640 тысяч будет достаточно, так почему я не могу !!)

Answer 1

если вы хотите что-то внедрить в реальный мир, одним из наиболее часто используемых встроенных микроконтроллеров RISC является семейство PIC. Google дает несколько эмуляторов, но я не думаю, что источник доступен для большинства.

еще одна возможность - QEMU, которая уже эмулирует несколько разновидностей ARM.

и, конечно же, если вы не заинтересованы в эмуляции реальных устройств, гораздо проще и эффективнее будет работать самостоятельно. только с тем, что вам нужно, и не попадать в путаницу флагов состояния, битов переполнения, ограниченной ширины шины, времени ОЗУ и т. д.

Answer 2

Я написал Wren для друга, который хотел, чтобы язык виртуальных машин работал на встроенном контроллере с примерно 16K БАРАН. (Но он разрешает до 64 Кб на процесс в написанном коде.) Он включает в себя компилятор для небольшого тупого языка программирования. Все это довольно просто и не очень полезно, но это именно то, что вы описали в первом абзаце.

Answer 3

FORTH " виртуальная машина " примерно так же просто, как они приходят. 16-битное адресное пространство (обычно), 16-битные слова данных, два стека, память. Loeliger's "Threaded Interpretive Languages" много рассказывает о том, как построить интерпретатор FORTH на Z80.

Answer 4

Если вы хотите простой, рассмотрите Manchester Mark I. См. стр. 15 это PDF . Машина имеет 7 инструкций. На то, чтобы написать переводчика, требуется около часа. К сожалению, инструкции довольно ограничены (поэтому почти полная спецификация машины может поместиться на одной странице).

Подход Хавьера к собственной работе очень прагматичен. Проектирование и создание крошечной машины - двухдневная задача, если это так. Я построил крошечную виртуальную машину для проекта несколько лет назад, и мне потребовалось два дня, чтобы написать виртуальную машину с помощью простого визуального отладчика.

Также - это должен быть RISC? Вы можете выбрать, скажем, 68K, для которых есть эмуляторы с открытым исходным кодом , и 68K была понятной целью для gcc.

Answer 5

Многие люди, пишущие игровые программы и другие приложения, встраивают в приложение язык, позволяющий пользователям писать небольшие программы.

Насколько я могу судить, самый популярный встроенные языки в очень приблизительном смысле наиболее популярный первый порядок (хотя "более популярный" не обязательно означает "лучший"), по-видимому, является:

• специфичный для домена язык, специально разработанный для данного конкретного приложения и нигде больше не используемый
• Lua a
• Tcl
• Питон a b, часто упрощенное подмножество , такое как PyMite c
• Вперед
• JavaScript a
• Шепелявить
• Ангельский текст a
• XPL0 a b
• Белка a
• Хаскелл a b
• NPCI (интерпретируемый Nano Псевдо C) a
• Общение с роботом
• интерпретация некоторого аппаратного машинного языка (почему это наименее популярный выбор?По уважительным причинам, описанным ниже).

Возможно, вы захотите ознакомиться с Gamedev StackExchange, в частности, с такими вопросами, как "Как вы добавляете язык сценариев в игру?".

Возможно, вы захотите ознакомиться с некоторыми вопросами здесь, в StackOverflow с тегом "встроенный язык";такие , как "Выбор встроенного языка", "Какой хороший встраиваемый язык я могу использовать для написания сценариев внутри моего программного обеспечения?" "Альтернативы Lua как встроенному языку?" "Какой игровой скриптовый язык лучше использовать:Lua или Python?", и т.д.

Многие реализации этих языков используют своего рода байт - код внутренне.Часто две разные реализации одного и того же высокоуровневого языка программирования, такого как JavaScript, внутренне используют два совершенно разных языка байт-кода ( a ).Часто несколько языков программирования высокого уровня компилируются в один и тот же базовый язык байт-кода - например, реализация Python на Jython, реализация JavaScript на Rhino, реализация Tcl на Jacl, JScheme и несколько других реализаций Scheme, а также несколько реализаций Pascal;все они компилируются в один и тот же байт-код JVM.

Подробные сведения

Зачем использовать язык сценариев, а не интерпретировать какой-то аппаратный машинный язык?

Почему "Чередуйте Твердые и Мягкие слои"?Чтобы добиться простоты и более быстрого развития.

более быстрое развитие

Люди обычно быстрее работают со скриптовыми языками, а не с компилируемыми языками.

Запуск начального прототипа, как правило, происходит намного быстрее - интерпретатор обрабатывает кучу закулисных вещей, которые машинный язык заставляет вас явно выписывать:установка начальных значений переменных равными нулю, код subroutine-prolog и subroutine-epilog, malloc и realloc, а также свободные и связанные с ними элементы управления памятью, увеличение размера контейнеров при их заполнении и т.д.

Как только у вас есть первоначальный прототип, добавление новых функций происходит быстрее:Языки сценариев имеют быстрые циклы редактирования-выполнения-отладки, поскольку они избегают стадии "компиляции" циклов редактирования-компиляции-выполнения-отладки скомпилированных языков.

простота

Мы хотим, чтобы язык встроенного языка был "простым" двумя способами:

• Если пользователь хочет написать небольшой код, который выполняет какую-то концептуально тривиальную задачу, мы не хотим отпугивать этого человека сложным языком, который требует 20 фунтов книг и месяцев изучения, чтобы написать "Привет, $USER" без переполнения буфера.

• Поскольку мы внедряем язык, нам нужно что-то простое в реализации.Возможно, несколько простых базовых инструкций, для которых мы сможем создать простой интерпретатор за выходные, и, возможно, какой-то уже существующий компилятор, который мы сможем повторно использовать с минимальной настройкой.

Когда люди создают процессоры, аппаратные ограничения всегда приводят к ограничению набора команд.Многие концептуально "простые" операции - вещи, которыми люди пользуются постоянно - в конечном итоге требуют для реализации множества инструкций на машинном языке.

Встроенные языки не имеют таких аппаратных ограничений, что позволяет нам реализовывать более сложные "инструкции", которые выполняют вещи, которые (человеку) кажутся концептуально простыми.Это часто упрощает систему в и то , и другое способы, упомянутые выше:

• Люди, пишущие непосредственно на этом языке (или люди, пишущие компиляторы для этого языка), в конечном итоге пишут гораздо меньше кода, тратят меньше времени на пошаговое выполнение кода, его отладку и т.д.

• Для каждой такой высокоуровневой операции мы переносим сложность с компилятора на реализацию инструкции внутри интерпретатора.Вместо того, чтобы (вы пишете код в) компиляторе разбивать какую-либо операцию более высокого уровня на короткий цикл на промежуточном языке (и многократно выполнять этот цикл в вашем интерпретаторе во время выполнения), компилятор выдает одну инструкцию на промежуточном языке (и вы записываете ту же серию операций в реализации вашего интерпретатора этой промежуточной "инструкции").Учитывая всю трудоемкость процессора, реализованную в вашем скомпилированном языке ("внутри" сложных инструкций), чрезвычайно простые интерпретаторы часто работают более чем достаточно быстро.(То есть вы избегаете тратить много времени на создание JIT или попытки ускорить процесс другими способами).

По этим и другим причинам многие программисты игр используют "скриптовый" язык в качестве своего "встроенного языка".

(Теперь я вижу, что Хавьер уже рекомендовал "использовать встроенный язык сценариев", так что это превратилось в длинную тираду о почему это хорошая альтернатива интерпретации аппаратного машинного языка и указанию альтернатив, когда один конкретный язык сценариев кажется неподходящим).