Pequeno RISC emulador

Question

Eu estou olhando para construir uma VM em um jogo e queria saber se alguém sabia de qualquer realmente simples da VM (Eu estava pensando RISC / PIC foi perto do que eu queria) que são normalmente utilizados para projetos embutidos, tais como controle de robôs , motores, sensores, etc. a minha principal preocupação é ter que escrever um compilador / montador se eu fazer a minha própria. Eu seria bom para usar as ferramentas que já estão lá fora, ou na sua forma mais simples apenas um compilador C que pode compilar para isso :-P.

Eu realmente não quero re-inventar a roda aqui, mas eu também preciso de milhares deles correndo em torno de um mundo virtual que eles tenham de ser tão simples e tão rápido quanto possível. Como uma pessoa já mencionou Eu também não se preocupam com questões do mundo real tal momento e ônibus e todas essas coisas divertidas. Eu acho que os seus relógios virtuais será limitado a somthing bastante lento; e, eventualmente, eu provavelmente vou ter que olhar para compilação nativa para fazê-los correr ainda mais rápido, mas por agora estou apenas colocando protótipos em conjunto para obter uma prova geral do conceito.

Como entrada, estou pensando em distância, luz sensores, e materiais de toque montado em torno do corpo cilíndrico (16, talvez 32 deles), em seguida, simplesmente 2 motores para a saída direccional para controlar um tipo de roda em cada lado. essencialmente o processamento não será muito extenuante e do mundo será suficiente simples para que a máquina de não ter que jogar lotes de poder de processamento em tarefas simples.

Em termos de memória, eu gostaria que eles sejam capazes de armazenar dados o suficiente para ser deixado sozinho por um par de dias sem intervenção para a construção de mapas e coleta de estatísticas. Eu não gosto de 8bit iria cortá-la para o processamento ou memória, mas 16bit seria definitivamente um contendor. 32 e 64 bits seria apenas empurrando-o e não há nenhuma maneira que eles terão mais do que 1MB cada uma memória - provavelmente mais perto de 256-512k. (Bill disse um 640k seria suficiente para por que não posso !!)

Answer 1

Se você quer algo enraizado no mundo real, um dos microcontroladores RISC embutidas mais utilizados é a família PIC. Google dá vários emuladores, mas eu não acho que a fonte está disponível para a maioria.

Outra possibilidade é QEMU, que já emula diversas variedades ARM.

e, é claro, se você não está interessado em emular um dispositivo do mundo real, muito mais fácil e melhor desempenho seria a rolar o seu próprio. com apenas o que você precisa, e não entrar na confusão de bandeiras do estado, pedaços de estouro, largura de barramento limitada, horários de RAM, etc.

Answer 2

Eu escrevi Wren para um amigo que queria uma linguagem VM em execução em um controlador incorporado com cerca de 16K de RAM. (Mas permite que até 64k por processo no código como escrito.) Ele inclui um compilador para uma pequena linguagem de programação mudo. É tudo, uh, bastante básico e não tem visto muito uso, mas é apenas o que você descreveu em seu primeiro parágrafo.

Answer 3

O ADIANTE "máquina virtual" é tão simples como eles vêm. espaço de endereçamento de 16 bits (tipicamente), palavras de dados de 16 bits, duas pilhas, memória. de Loeliger "Rosqueou Interpretativos Línguas" diz muito sobre como construir um intérprete para trás em um Z80.

Answer 4

Se você quiser simples, considere o Manchester Mark I. Ver página 15 do este PDF. A máquina tem 7 instruções. Demora cerca de uma hora para escrever um intérprete para ele. Infelizmente, as instruções são bastante dang limitado (que é porque praticamente uma especificação completa da máquina pode caber em uma página).

abordagem de rolar sua própria Javier é muito pragmática. Concepção e criação de uma máquina pequena é uma tarefa dois dias, se tanto. Eu construí uma pequena VM para um projeto há alguns anos atrás e ele me levou dois dias para escrever o VM com um depurador visual simples.

Também - que tem que ser RISC? Você pode escolher, dizer, 68K para os quais não são open source emuladores e 68K era um alvo bem compreendido para gcc.

Answer 5

Muitas pessoas escrevem programas de jogos e outras aplicações de incorporar uma linguagem para o aplicativo para permitir aos usuários escrever pequenos programas.

Tanto quanto eu posso dizer, o mais popular idiomas incorporados em muito roughtly mais popular-primeira ordem (embora "mais popular" não significa necessariamente "melhor") parecem ser:

• linguagem específica de domínio customizado para esta aplicação específica um e utilizado em nenhum outro lugar
• Lua a
• Tcl
• um b , muitas vezes, um subconjunto simplificado, como PyMite c
• Forth
• JavaScript a
• Lisp
• um
• um b
• um
• um < a href = "http://www.cs.um.edu.mt/gordon.pace/Research/Papers/wict2010-01.pdf" rel = "nofollow noreferrer"> b
• NPCI (Nano Pseudo C interpretadas) um
• RoboTalk
• interpretar alguma linguagem de máquina de hardware (Por que isso é a escolha menos popular? Por boas razões, descrito abaixo).

Você pode querer verificar o Gamedev Stackexchange, em especial, questões como " Como você adicionar uma linguagem de script para um jogo? ".

Você pode querer verificar para fora algumas das perguntas aqui na StackOverflow marcado "linguagem embutida" ; tal como "Selecionando um idioma incorporado" , "O que é um boa linguagem embutido posso usar para scripts dentro do meu software? " "Alternativas a Lua como uma linguagem embutida?" "Que jogo linguagem de script é melhor usar: Lua ou Python? ", etc.

Muitas implementações de línguas usam algum tipo de bytecode internamente. Muitas vezes duas diferentes implementações da mesma linguagem de programação de alto nível, tais como JavaScript uso de dois bytecode languag completamente diferentees internamente ( um ). Muitas vezes, linguagens de programação vários de alto nível compilar para o mesmo idioma bytecode subjacente - por exemplo, a implementação Jython de Python, a implementação do rinoceronte de JavaScript, a implementação Jacl de Tcl, JScheme e várias outras implementações de Scheme, e várias implementações Pascal; todos de compilação para o mesmo bytecode JVM.

detalhes

Por que usar uma linguagem de script em vez de interpretar alguma linguagem de máquina de hardware?

Por "camadas alternadas duro e mole" ? Para obter simplicidade, e mais rápido desenvolvimento.

desenvolvimento mais rápido

As pessoas geralmente começar o material trabalhar mais rápido com linguagens de script em vez de linguagens compiladas.

Obtendo o protótipo de trabalho inicial é geralmente muito mais rápido - o intérprete lida com um monte de coisas por trás das cenas que em linguagem de máquina obriga a escrever explicitamente salientar: definir os valores iniciais de variáveis ??para zero, sub-rotina, prólogo e sub-rotina código -epilog, malloc e realloc e coisas de gerenciamento de memória livre e relacionados, aumentando o tamanho dos recipientes quando chegar cheia, etc.

Uma vez que você tem um protótipo inicial, adicionando novos recursos é mais rápido: Linguagens de script têm ciclos edit-executar-depuração rápidas, uma vez que evitam o estágio "compilação" dos ciclos de edição-compilação-execução-depuração de linguagens compiladas

simplicidade

Queremos a língua idioma incorporado para ser "simples" de duas maneiras:

• Se um usuário quer escrever um pouco de código que faz alguma tarefa conceitualmente trivial, não queremos assustar esta pessoa com uma linguagem complexa que leva 20 toneladas de livros e meses de estudo, a fim de gravação um "Olá, $ USUÁRIO" sem estouros de buffer.

• Uma vez que estamos implementando a linguagem, queremos algo fácil de implementar. Talvez um simples poucos instruções subjacente podemos bater para fora um simples intérprete em um fim de semana, e talvez algum tipo de compilador pré-existente, podemos reutilizar com ajustes mínimos.

Quando as pessoas construir CPUs, restrições de hardware sempre acabam limitando o conjunto de instruções. Muitos conceitualmente operações "simples" - coisas que as pessoas usam o tempo todo - acabar exigindo muitas instruções em linguagem de máquina de implementar.

idiomas incorporados não têm estas restrições de hardware, o que nos permite implementar mais complicado "instruções" que fazem coisas que (a um ser humano) parecem conceitualmente simples. Isso muitas vezes torna o sistema mais simples em ambos maneiras mencionadas acima:

• As pessoas que escrevem diretamente na língua (ou pessoas que escrevem compiladores para a linguagem) acabar escrevendo muito menos código, gastando menos tempo single-percorrendo o código depurá-lo, etc.

• Para cada operação de nível superior, mudamos complexidade do compilador para a implementação de uma instrução dentro do intérprete. Ao invés de (você escrever código em) o compilador quebrar alguma operação de alto nível em um curto circuito no idioma intermediário (e repetidamente percorrendo esse ciclo em seu intérprete em tempo de execução), o compilador emite um instruções no idioma intermédio (e você escrever a mesma série de operações na implementação do seu interpretador de que "instrução" intermediário). Com todas as coisas intensivo da CPU implementado em sua linguagem compilada ( "dentro" instruções complexas), intérpretes extremamente simples são muitas vezes mais do que suficiente rápido. (Ou seja, você evita gastar muito tempo construindo um JIT ou tentando acelerar as coisas de outras maneiras).

Por estas e outras razões, muitos programadores de jogos usar uma linguagem "script" como sua "linguagem embutida".

(Iver agora que Javier já recomendado "usar uma linguagem de script embutido", de modo que este se transformou em um longo discurso em por que é uma boa alternativa para interpretar a linguagem de máquina hardware, e apontar alternativas quando uma linguagem de script em particular não parece adequado).