Petit émulateur RISC

Question

Je souhaite intégrer une machine virtuelle à un jeu et je me demandais si quelqu'un connaissait une machine virtuelle vraiment simple (je pensais que RISC / PIC était proche de ce que je voulais) qui est généralement utilisée pour des projets intégrés tels que le contrôle de robots. , moteurs, capteurs, etc. Ma principale préoccupation est de devoir écrire un compilateur / assembleur si je lance le mien. Ce serait bien d’utiliser les outils déjà existants ou, sous sa forme la plus simple, un compilateur C capable de compiler pour cela :-p.

Je ne veux vraiment pas réinventer la roue ici, mais j’ai également besoin de milliers d’entre eux tournant dans un monde virtuel, ils doivent donc être aussi simples et rapides que possible. Comme une personne l'a déjà mentionné, je ne me soucie pas non plus des problèmes du monde réel tels que la synchronisation, les bus et tout ce qui est amusant. Je pense que leurs horloges virtuelles seront limitées à quelque chose d'assez lent; et finalement, je devrai probablement me pencher sur la compilation native pour la faire fonctionner encore plus vite, mais pour l’instant, je ne fais que monter des prototypes pour obtenir une preuve générale du concept.

En entrée, je prévois des capteurs de distance, de lumière, de matériau et tactiles montés autour du corps cylindrique (16, voire 32), puis deux moteurs de sortie directionnelle pour contrôler une sorte de roue de chaque côté. essentiellement, le traitement ne sera pas trop pénible et le monde sera suffisamment simple pour que la machine ne soit pas obligée de consacrer beaucoup de puissance de traitement à des tâches simples.

En termes de mémoire, j'aimerais qu'ils puissent stocker suffisamment de données pour être laissés seuls pendant quelques jours sans intervention pour la construction de cartes et la collecte de statistiques. Je n'aime pas que 8bits le coupe pour le traitement ou la mémoire mais 16bits serait certainement un concurrent. 32 et 64 bits ne feraient que le pousser et il est impossible qu'ils aient plus de 1 Mo de mémoire chacun - probablement plus proche de 256-512k. (Le premier projet de loi dit que 640k serait suffisant, alors pourquoi pas moi !!)

Answer 1

si vous voulez quelque chose enraciné dans le monde réel, l’un des microcontrôleurs RISC intégrés les plus utilisés est la famille PIC. google donne plusieurs émulateurs, mais je ne pense pas que la source soit disponible pour la plupart.

Une autre possibilité est QEMU, qui émule déjà plusieurs variétés ARM.

et, bien sûr, si vous n'êtes pas intéressé par l'émulation d'un périphérique réel, il est beaucoup plus facile et plus performant de lancer le vôtre. avec seulement ce dont vous avez besoin, sans entrer dans le désordre des drapeaux d’état, des bits de débordement, de la largeur de bus limitée, des synchronisations de RAM, etc.

Answer 2

J'ai écrit Wren pour un ami qui souhaitait utiliser un langage de machine virtuelle sur un contrôleur intégré avec environ 16 Ko de RAM. (Mais cela permet jusqu'à 64k par processus dans le code écrit.) Il inclut un compilateur pour un petit langage de programmation stupide. C'est tout, euh, assez basique et peu utilisé, mais c'est exactement ce que vous avez décrit dans votre premier paragraphe.

Answer 3

Le FORTH " machine virtuelle " est à peu près aussi simple qu’ils viennent. Espace d'adressage de 16 bits (généralement), mots de données de 16 bits, deux piles, mémoire. Loeliger's " Threaded Interpretive Languages ??" vous explique comment construire un interpréteur FORTH sur un Z80.

Answer 4

Si vous voulez simple, considérez le Manchester Mark I. Voir page 15 de this PDF . La machine a 7 instructions. Il faut environ une heure pour écrire un interprète. Malheureusement, les instructions sont assez limitées (c’est pourquoi une machine peut parfaitement contenir les spécifications de la machine sur une seule page).

L’approche de Javier à rouler la vôtre est très pragmatique. Concevoir et créer une petite machine est une tâche de deux jours, si cela se produit. J'ai construit une petite machine virtuelle pour un projet il y a quelques années et cela m'a pris deux jours pour l'écrire avec un simple débogueur visuel.

Aussi - faut-il que ce soit RISC? Vous pouvez choisir, par exemple, 68 Ko pour lesquels il existe émulateurs open source , et 68 Ko était une cible bien comprise. pour gcc.

Answer 5

De nombreuses personnes qui écrivent des programmes de jeux et d’autres applications incorporent un langage dans l’application pour permettre aux utilisateurs d’écrire de petits programmes.

Autant que je sache, les langues incorporées les plus populaires dans in de première classe (bien que "plus populaire" ne signifie pas nécessairement "meilleur") semble être:

• langage spécifique au domaine, conçu sur mesure pour cette application spécifique et utilisé nulle part ailleurs
• Lua a
• Tcl
• Python a b , souvent un sous-ensemble simplifié tel que PyMite c
• En avant
• JavaScript a
• Lisp
• AngelScript a
• XPL0 a b
• Squirrel a
• Haskell a < a href = "http://www.cs.um.edu.mt/gordon.pace/Research/Papers/wict2010-01.pdf" rel = "nofollow noreferrer"> b
• NPCI (nano pseudo C interprété) a
• RoboTalk
• interprète certains langages de la machine (pourquoi s’agit-il du choix le moins populaire? Pour les bonnes raisons décrites ci-dessous).

Vous pouvez consulter Gamedev StackExchange, en particulier des questions telles que " Comment ajouter un langage de script à un jeu? ".

Vous pouvez vérifier certaines des questions ici sur StackOverflow marqué "langage incorporé" ; tel que "Sélection d'une langue intégrée" , " ce qui est un bon langage intégrable que je peux utiliser pour la création de scripts dans mon logiciel? & ; "Alternatives à Lua en tant que langage intégré?" "Quel langage de script de jeu est-il préférable d'utiliser : Lua ou Python? & ; , etc.

De nombreuses implémentations de ces langages utilisent une sorte de bytecode en interne. Souvent, deux implémentations différentes du même langage de programmation de haut niveau, telles que JavaScript, utilisent en interne deux langages de bytecode complètement différents ( a ). Souvent, plusieurs langages de programmation de haut niveau se compilent sous le même langage bytecode sous-jacent - par exemple, l'implémentation Jython de Python, l'implémentation Rhino de JavaScript, l'implémentation Jacl de Tcl, JScheme et plusieurs autres implémentations de Scheme et plusieurs implémentations Pascal; tous compiler dans le même bytecode JVM.

détails

Pourquoi utiliser un langage de script plutôt que d'interpréter un langage de machine?

Pourquoi " Autres couches rigides et souples " ? Gagner en simplicité et accélérer le développement.

développement plus rapide

Les gens travaillent généralement plus vite avec des langages de script plutôt que des langages compilés.

Il est généralement beaucoup plus rapide de faire fonctionner le prototype initial - l'interprète gère un tas de choses en coulisses que le langage machine vous oblige à écrire explicitement: définir les valeurs initiales des variables sur zéro, prologue et sous-programme -pilog code, malloc et realloc et des logiciels de gestion de la mémoire gratuits et connexes, en augmentant la taille des conteneurs lorsqu'ils sont pleins, etc.

Une fois que vous avez un prototype initial, l'ajout de nouvelles fonctionnalités est plus rapide: les langages de script ont des cycles rapides d'édition, d'exécution et de débogage, car ils évitent les options "compiler". étape des cycles édition-compilation-exécution-débogage des langages compilés.

simplicité

Nous souhaitons que le langage incorporé soit "simple". de deux manières:

• Si un utilisateur veut écrire un petit code qui accomplit une tâche conceptuellement triviale, nous ne voulons pas l'effrayer avec un langage complexe qui prend 20 livres de livres et des mois d'étude pour écrire un " Bonjour, $ USER " sans débordement de tampon.

• Puisque nous implémentons le langage, nous voulons quelque chose de facile à implémenter. Quelques instructions sous-jacentes simples peuvent nous permettre d’utiliser un interpréteur simple en un week-end, et peut-être une sorte de compilateur préexistant que nous pouvons réutiliser avec un minimum de peaufinage.

Lorsque des personnes construisent des processeurs, les restrictions matérielles finissent toujours par limiter le jeu d'instructions. Beaucoup conceptuellement " simple " opérations - choses que les gens utilisent tout le temps - finissent par nécessiter de nombreuses instructions en langage machine à mettre en œuvre.

Les langues incorporées n’ont pas ces restrictions matérielles, ce qui nous permet d’implémenter plus compliqué " instructions " qui font des choses qui (à un humain) semblent conceptuellement simples. Cela simplifie souvent le système pour les deux manières mentionnées ci-dessus:

• Les personnes qui écrivent directement dans la langue (ou celles qui écrivent des compilateurs pour la langue) finissent par écrire beaucoup moins de code, passant moins de temps à parcourir le code sans le déboguer, etc.

• Pour chacune de ces opérations de niveau supérieur, nous passons de la complexité du compilateur à la mise en oeuvre d'une instruction à l'intérieur de l'interpréteur. Plutôt que (vous écrivez du code dans) le compilateur divisant une opération de niveau supérieur en une boucle courte dans le langage intermédiaire (et en passant à plusieurs reprises dans cette boucle dans votre interprète au moment de l'exécution), le compilateur émet une instruction dans le langage intermédiaire (et vous écrivez la même série d'opérations dans la mise en œuvre par votre interprète de cette "instruction" intermédiaire). Avec tout le matériel gourmand en ressources implémenté dans votre langage compilé (instructions "internes"), des interprètes extrêmement simples sont souvent plus que rapides. (C’est-à-dire que vous évitez de passer beaucoup de temps à construire une EMI ou à essayer d’accélérer les choses autrement).

Pour ces raisons, entre autres, de nombreux programmeurs de jeux utilisent un "script". langue en tant que "langue intégrée".

(Je vois maintenant que Javier a déjà recommandé "d'utiliser un langage de script intégré", Cela est donc devenu une longue incursion sur pourquoi c'est une bonne alternative à l'interprétation d'un langage de machine matérielle et à la recherche d'alternatives lorsqu'un langage de script particulier ne semble pas adapté).