Bonjour tout le monde.
Ce forum n'est sûrement pas le plus approprié pour parler de ça, mais j'en ai franchement marre de tourner en rond sans savoir par où commencer. J'ai la sensation d'être une balle dans un flipper depuis un peu trop longtemps.
Pour ajouter un peu au contexte en parlant de moi : je suis un informaticien de formation, mais je n'ai en ce moment (et depuis longtemps) pas accès à internet pendant la journée, uniquement le soir.
Je transfert les fichiers qui m'intéressent (pdf, vidéo, page web, zip etc) sur une clef usb pour les utiliser une fois revenu chez moi. Notez aussi que lorsque j'ai accès à internet c'est sous un linux, et que lorsque je suis chez moi j'utilise un windows.

Ce qui suit s'adresse surtout aux personnes informaticiennes professionnelles, mais n'importe qui peut aider. Je ne vais pas particulière essayer d'être compréhensible par tout le monde (en partie en raison de l'heure), mais ça ne devrait pas être trop difficile de me comprendre.

Je travail (ok ok : je m'amuse) en ce moment sur un projet visant à créer une console virtuelle. Je ne veux pas dire par là "un terminal avec un fond noir et des lettres blanches", non je veux dire une console de jeux.
J'ai le bagage technique suffisant, surtout que comme elle est virtuelle, je m'autorise certaines largesses.

Précisons les choses : par "virtuelle" j'entends une console qui n'a jamais existé. Une console qui aurait pu exister si l'histoire avait été différentes, si certains évènements s'étaient produits.

Comme vous pouvez le voir, cela autorise des largesses.

Techniquement tout va bien, j'avance et je m'amuse. Mais je suis bloqué sur un problème depuis un moment et je galère dessus, sans trouver un début d'échappatoire. Disons que les chemins pour sortir semblent exister, mais que chacun d'eux semble passer par des montagnes aussi hautes que l’Everest.

Cette console utilise des cartouches.
Cela signifie qu'en plus du programme principal (disons "l'OS" de la console, son système d'exploitation, son SE, appelez ça comme vous voulez) il doit y avoir un petit programme supplémentaire venant se greffer dessus (le jeu).

Tout cela est développé en C (j'insiste. Et j'ai fais énormément de programmation objet dans ma vie, c'est par choix que je fais cela en C).
Pour le moment (et j'avais parfaitement conscience lorsque je l'ai fais que ça serait une solution temporaire) ces petits programmes externes sont représentés sous forme de dll. Le programme principale ouvre la dll, y cherche un point d'entrée (une fonction particulière) lui passe un paramètre vers une structure prédéfinie que le dll peuple etc.
Cela pose bien entendu plusieurs problèmes.
D'une part, s'il s'agit de DLL, cela fonctionne sur Windows et pas ailleurs. Je sais, il existe des fichiers équivalents sur Linux, mais alors ça ne fonctionnera pas sous Windows. En substance, une "rom" ne fonctionnera que sur un OS précis, ce qui est un peu idiot.
Ensuite, cela pose un problème de sécurité évident : comme c'est une dll, elle peut contenir n'importe quel appel fonction et s'exécute avec les mêmes droits que l'application principale. On peut plus ou moins patcher ce problème en lançant un programme intermédiaire chargé de s'occuper de la DLL et avec des droits réduits, mais ça reste compliqué et surtout très fragile et utopique (sur windows, avoir des droits aussi finement paramétrés ...)
Enfin, une rom doit pouvoir se modifier. Pour les plus jeunes qui ne le savent pas, il fut un temps où les jeux n'étaient pas sauvegardés dans le cloud, ni même dans la console, ni même dans des "cartouches de sauvegarde" achetées exprès pour, mais directement dans le jeu lui-même. Je veux garder ce comportement, or il n'est pas possible de modifier un dll en cours d'utilisation. Pire, je ne saurais pas comment le modifier (trouver à quelle adresse écrire des trucs), faut pas déconner non plus. Et, "pire", je ne VEUX pas le modifier. On a déjà évoqué le problème de la sécurité, mais si en plus la DLL peut être modifié, on oublie définitivement toute notion de signature dessus, et donc bienvenues les DLL modifiées avec virus.

Bref, cette solution était pratique pour tester rapidement des trucs au début, mais elle n'est définitivement pas tenable ni même souhaitable sur le long terme.

La solution vers laquelle je souhaiterais me diriger est la suivante : faire en sorte que les roms soient des fichiers bytecode (j'utilise le mot "bytecode" pour parler de n'importe quel langage bas-niveau exécuté sur une machine virtuelle et, potentiellement, réelle. Mais ça n'a pas à être strictement parlant du bytecode). pour une architecture virtuelle. Une machine virtuelle, qui se chargerait de faire les appels fonctions pour les fonctions externes à la rom, et qui donc pourrait vérifier que seules les fonctions autorisées sont appelées, et même que les paramètres sont valides etc.
Comme des professionnels vont peut-être me lire : oui, comme pour le lua, tout pareil. Mais je ne peux pas prendre le lua pour les raisons invoquées ci-dessous.

Il me faut donc pouvoir compiler les roms vers ce bytecode. L'architecture de la machine virtuelle associée au bytecode m'importe peu, dans le sens ou je n'exige pas (pas encore, un jour lointain peut-être, mais on s'en fout) qu'elle corresponde à quelque chose de précis.

Il faut que le code source soit en C. Déjà parce que j'ai du code "de jeu" écrit dans ce langage, et surtout parce que cette façon je pourrais utiliser les fichiers en-têtes de l'application principale. Si l'application principale définit un enum de valeur pour, par exemple, la résolution, que le jeu soit codé en C me permet d'inclure l'en-tête ou se trouve cet enum et d'utiliser ses valeurs directement. Il n'y a pas de recopie à faire, donc un gain de temps et on évite aussi les bugs associés au fait qu'on a mal/pas encore recopié.

Partant de ça, mes recherches m'ont guidé vers l'idée que je devrais créer un backend spécialisé pour gcc/llvm.
Sauf que llvm exige visual studio pour se compiler. Oui, il existe des binaires llvm, mais il n'y en a qu'une partie. Il n'y a pas, par exemple, llc ni lld.
Il existe aussi prétendument des binaires "compilé par quelqu'un dans son coin" pour ces fichiers, mais ce sont surtout des virus.
Et visual studio pèse 46 giga (oui, on se demande ... ) c'est-à-dire beaucoup plus que ce que peut contenir ma clef usb, et de toute façon beaucoup plus de budget mémoire disque dur que je ne souhaite accorder à ce sous-sous-sous-élément de mon projet. Pour la version linux, on est face à un rabbit hole de librairies exigeants d'autres librairies exigeant d'autres librairies. J'imagine que ça ne pose pas de problèmes que le processus est automatisé et que tout se fait via internet. Mais sans internet, c'est à chaque fois récupérer les trucs à la main, les installer à la main etc. Linux pose aussi le problème qu'alors je devrais passer par une machine virtuelle (via virtualbox) et que ça sera alors constamment lent.
Bref, idéalement il me faudrait un compilateur produisant un code assembleur (sous forme texte ou binaire) sans le boiler-plate spécifique à windows/linux. Si vous ne voyez pas de quoi je parle, compiler un "hello world" sur windows : le fichier source fera moins d'un ko, le fichier exe produit en fera 30 (ko), et ça c'était il y a quelques années, je pense que ça a encore augmenté. Je n'ai aucun problème avec cette taille, en soit, c'est surement plein de trucs utiles à windows et je tant que ça marche on s'en moque. Mais je rappel que le but est d'avoir un truc à exécuter sur une machine virtuelle. Je n'ai donc pas besoin de tout ce blabla en plus.

Pour gcc, la création d'un backend semble extraordinairement compliquée. Et il me semble que c'est surtout possible pour gcc (avec cygwin) pas pour mingw (que j'utilise).

Je sais utiliser les outils yacc/lex et dans l'absolu je pourrais me faire mon propre compilateur.

C'est approximativement les trois solutions (llvm/gcc/yacclex).
Sauf que ... elles me paraissent toutes trop compliquées pour ce que je cherche.
N'y aurait-il pas un petit truc déjà existant-clef-en-main produisant ce code bas-niveau que je recherche ?

Un truc genre MIPS et avec peu de cérémonie.
Enfin, je veux dire : je peux me contenter maintenant (et pour longtemps) d'une architecture machine existante que j'implémenterais. C'est juste de la plomberie, si beaucoup plus tard je change l'architecture bas-niveau il me suffira de recompiler les jeux dessus et ça ira tout seul.

Des idées, des avis ?

Merci d'avoir lu.

P.S : j'ai tout à fait conscience que concevoir une console de jeu implique de se pencher sur l'architecture matériel du processeur, et donc que je ne devrais pas me contenter de n'importe quoi.
Mais c'est un travail en couches. L'une d'elle (la plus basse) est celle-ci, mais au-dessus il y a aussi la communication entre les divers composants, le système d'exploitation, les fonctions exposées aux jeux etc.
Je vous rassure, il y a suffisamment à faire comme ça.
J'ai aussi pas mal de documents sur plein d'aspects techniques (ce n'est pas un nouveau projet), et même sur des aspects historiques (des anecdotes, des idées de publicités qui auraient été faites à l'époque, des jeux sortis dessus etc).
Il y a juste cet aspect qui m'embête pas mal.

(ouch, c'etait un peu long a lire.)

Des commentaires:

Regarde comment ca marche un emulateur de n'importe quoi: nes, supernes, whatever. Ca devrait repondre a beaucoup de tes questions. En particulier, il y a des gens qui ont fait des tool chains pour compiler de nouveau jeu pour ces architectures la.

Tu disais regarder comment implementer une nouvelle architecture et un nouveau back end pour un compilateur. Ca veut dire qu'il faut que tu commences par pondre l'architecture du processeur, pondre le jeu d'instruction, et apres pondre le back end du compilateur. Et tout ca, avant meme d'avoir commencer a bosser l'architecture de la console en elle meme.

Ca m'a l'air d'etre BEAUCOUP de travail pour pas grand chose. Pourquoi ne pas prendre une architecture processeur qui existe deja, une architecture de GPU (si tu as un truc comme ca dans ton archi) pour ne pas avoir a re-ecrire ces couches super basses.

Regarde une nintendo DS par exemple, bien que ca utilisent plein de composant different (2 processeur different par exemple), plein de DMA et de truc sur le port serie, ils n'ont pas reecrit leur propre archi processeur. C'est deja assez complique en partant de composant connu et teste pour ne pas avoir a rajouter des questions comme ca.

Le plus simple ça serait pas de juste abandonner le C pour l'écriture des jeux et le faire dans un langage assembleur spécial pour ta machine ? Du coup t'as ton problème d'include mais ça a l'air d'être le truc le moins dérangeant / le plus facile à corriger de tous les problèmes que tu cites, surtout qu'en vrai rien ne t'empêche d'utiliser tes enums de valeur dans ton assembleur directement, genre ta VM détecte une variable système (au pif un nom qui commence par un underscore) et la remplace par sa valeur et voilà.

Le 12 février 2019 à 07:47:17 lokilok a écrit :
Le plus simple ça serait pas de juste abandonner le C pour l'écriture des jeux et le faire dans un langage assembleur spécial pour ta machine ? Du coup t'as ton problème d'include mais ça a l'air d'être le truc le moins dérangeant / le plus facile à corriger de tous les problèmes que tu cites, surtout qu'en vrai rien ne t'empêche d'utiliser tes enums de valeur dans ton assembleur directement, genre ta VM détecte une variable système (au pif un nom qui commence par un underscore) et la remplace par sa valeur et voilà.

Bhein ça change rien, et c'est même complexe s'il faut qu'il définisse lui-même tout le jeu d'instruction.
Pour moi le mieux c'est de commencer par des jeux d'instruc. simples, genre chip8, de faire un ass puis un disass et après de commencer à implémenter les fonctions pour l'émulateur.
Il pourra tester simplement son emul en telechargeant des roms, pas besoin de les dev lui meme.

non mais définir le jeu d'instruction etc. ça ne pose pas un problème. J'ai déjà fait plusieurs vm dans ma vie, ça se fait à la fois rapidement et facilement. Ce qui serait compliqué c'est si je voulais avoir du garbage collector ou des trucs complexes, ce qui n'est pas du tout le cas.

Je peux définir un langage assembleur facilement. Mais il me manquera les outils pour produire ce code assembleur, pour ne pas avoir à écrire tout à la main, pour pouvoir passer par un haut niveau.

C'est pas qu'une histoire d'enum, c'est aussi une histoire de signature de fonction. Si l'API de l'OS propose une fonction "dessinerUnRectangle" (ça n'existe pas, c'est pour un exemple) qui prend les coordonnées et la couleur du rectangle, c'est déclaré dans le .h, compilé dans le .c qui va avec, et ça serait bien qu'un jeu décidant d'utiliser cette fonction ait accès à cette signature de fonction directement. Il incluerait le .h, le compilateur vérifierait que les appels à cette fonction ont le bon nombre de paramètres, des bons types etc.
Exactement comme ce qui se fait maintenant, en fait, sauf que la sortie de compilation ne serait pas du code "pour windows natif" mais "pour une architecture virtuelle".
L'intérêt de ne changer que le backend (c'est-à-dire la sortie) et pas le frontend (c'est-à-dire la partie qui décode le code source, vérifie les appels fonctions, résout le préprocesseur et j'en passe) c'est qu'on conserve toutes les optimisations et vérifications déjà existantes dans un compilateur déjà existant.

Puisque j'ai un peu de temps pour faire une réponse un peu plus longue et développer un peu plus:

j'ai déjà pensé à l'architecture basse de la console. Comment les composants physiques sont agencés et, surtout, comment ils communiques. Quelle puissance, quelles possibilités etc.
Au-dessus de cela il y a une couche logicielle. C'est-à-dire qu'au lieu d'aller "écouter le fil en attendant que personne ne l'utilise, puis émettre un signal disant qu'il est occupé, puis écrire l'adresse blablabla" il y a une couche qui ressemble à "envoyerMessageAComposant", prenant des informations de plus haut niveau et se chargeant des appels bas niveaux.
Encore au dessus de ça, il y a couche qui groupe les outils bas niveau en outils pour les tâches répétitives et un peu compliquées. Si on peut imaginer que la couche précédente demandait un "callback" qui ajouterait petit-à-petit les informations à envoyer, la couche plus haute peut proposer de tout "envoyer en un coup", en cachant le fait que l'envoie se fait petit à petit. Cette couche n'est pas clairement isolée de la première.
Disons que, par exemple, c'est ici qu'on retrouve les opérations de dessin.

Enfin, au-dessus de tout ça, il y a la "vue" de l'os, qui est en fait une application permettant de régler les settings de la console, les sauvegardes etc.

Mon but, dans tous ça, est de me limiter dans un premier temps aux dernières couches.
D'où le besoin faible, sinon inexistant, d'avoir mon propre jeu d'instruction assembleur. Je n'en ai besoin que pour les raisons que j'ai cité. Pour le moment.
Ce qui fait que ça se rapproche + d'un moteur que d'une console.
J'entends parfaitement que je suis un gros flemmard. Ce n'est pas exactement vrai, parce qu'en parallèle je développe les outils pour développer les jeux sur ce support (ce qui se rapproche de l'EDITEUR d'un moteur de jeu, sauf que c'est bien plus compliqué à faire qu'un "moteur" se contentant de "jouer" des données qui supposément existeraient par magie).
Je pourrais dire "voilà, c'est ce jeu d'instruction, débrouillez-vous". Mais ce n'est pas le but, parce que derrière je devrais développer les outils permettant de générer un programme dans ce jeu d'instruction. D'où le fait que je fasse profil bas sur le sujet, et que je sois prêt à m'accommoder d'un jeu d'instruction existant et d'une spécification machine allant avec, si cela me permet d'avoir à faible coût (en temps) le compilateur dans la popoche.

(Et j'y gagne un peu à utiliser une telle approche : la vitesse. Même si ce n'est pas le but recherché).

Si vous voulez je peux donner des specs plus détaillées, plus techniques, sur le nombre de sprites, la taille de ceux-ci, les différents modes graphiques. Même les formats de couleurs ou des specs plus précises pour chaque composants (par exemple la partie graphique est un hybride 16/32 bits, puisqu'elle utilise du 16bits en entrée mais produit une sortie 32bits. Et ce que ça signifie dépend des modes: palette/directcolor (qui n'est pas exactement du true color). Et cela est déjà implémenté, et avec déjà des outils pour s'occuper du boilerplate code entre "plein d'images png true color" et "format spécifique à la console un seul fichier etc".
J'ai même commencé à bosser sur un synthétiseur audio, avec des instruments "pré-existant" et quelques slots pour ajouter des instruments à base d'échantillons. Qui fonctionne (j'entends la musique) mais je suis en train de le travailler pour l'optimiser et, surtout, le faire travailler sur des entiers 16bits.

etc etc etc.

quand je dis que j'ai un problème, c'est que c'est un problème.

non mais définir le jeu d'instruction etc. ça ne pose pas un problème. J'ai déjà fait plusieurs vm dans ma vie, ça se fait à la fois rapidement et facilement. Ce qui serait compliqué c'est si je voulais avoir du garbage collector ou des trucs complexes, ce qui n'est pas du tout le cas.

Le garbage collector, c'est un probleme de langage pas d'architecture. Je ne comprends pas bien ce que tu veux.

Je peux définir un langage assembleur facilement. Mais il me manquera les outils pour produire ce code assembleur, pour ne pas avoir à écrire tout à la main, pour pouvoir passer par un haut niveau.

C'est pour ca que le probleme est deja assez complique sans avoir a reinventer un assembleur.

C'est pas qu'une histoire d'enum, c'est aussi une histoire de signature de fonction. Si l'API de l'OS propose une fonction "dessinerUnRectangle" (ça n'existe pas, c'est pour un exemple) qui prend les coordonnées et la couleur du rectangle, c'est déclaré dans le .h, compilé dans le .c qui va avec, et ça serait bien qu'un jeu décidant d'utiliser cette fonction ait accès à cette signature de fonction directement. Il incluerait le .h, le compilateur vérifierait que les appels à cette fonction ont le bon nombre de paramètres, des bons types etc.

C'est un probleme d'API ca, l'OS ou le platform dev kit, il te donne une lib statique (en l'occurence c'est qoi qui va l'ecrire) et la verification de signature est faite par le compilateur.

Exactement comme ce qui se fait maintenant, en fait, sauf que la sortie de compilation ne serait pas du code "pour windows natif" mais "pour une architecture virtuelle".

Le compilateur il s'en fout de la platform cible, lui il pond du code objet.

L'intérêt de ne changer que le backend (c'est-à-dire la sortie) et pas le frontend (c'est-à-dire la partie qui décode le code source, vérifie les appels fonctions, résout le préprocesseur et j'en passe) c'est qu'on conserve toutes les optimisations et vérifications déjà existantes dans un compilateur déjà existant.

Si tu change le langage assembleur, il faut reecirre toute la couche de generation d'assembleur. Et ca c'est bourre d'optimisation que tu n'as probablement pas envie de reecrire.

J'ai l'impression que tu confond compilateur et linker. A peu de chose pres, le compilateur se fout completement de l'OS qui tourne sur la machine. Le compilateur pond du code binaire avec un peu de decoration pour le linker. C'est le linker qui va pondre un fichier bien formater pour la platform. Si tu compile pour nintendo DS, ou android sur de l'arm le fichier objet qui sort du compilateur c'est le meme. Parceque l'archi, c'est de l'arm 9. (il y a eux arm dans la ds, mais bon.)

Le linker lui va changer et dependre du format de l'image qui faut que tu pondes a la fin. Mais tu peux probablement prendre un linker standard, linker le tout statiquement et faire demarer le code la ou le symbol _start est.

Typiquement pour faire causer les composants entre eux, tu as des interupt, des port series, et des controlleurs memoire. Je ne comprends pas bien ce que tu ne comprends pas.

Le 13 février 2019 à 04:30:26 godrik a écrit :
Le garbage collector, c'est un probleme de langage pas d'architecture. Je ne comprends pas bien ce que tu veux.

Non mais c'est parce qu'on parlait de vm.
Ce que je veux ?
Un programme gcc-like, tournant sur windows, qui me permette de produire un code assembleur (binaire ou texte, je peux me charger de text->binaire, on s'en fout) avec le minimum de cérémonie.
Le but : écrire une machine virtuelle qui prenne ce fichier en entrée et l'exécute, en résolvant elle-même les appels fonctions externes (c'est-à-dire les fonctions non présentes dans ce même fichier).
Gain : j'ai toute l'expressivité du C.
Gain : je n'ai pas à parser, je n'ai pas à vérifier le typage, je n'ai pas à convertir, je n'ai pas à écrire de préprocesseur, je n'ai pas à faire quoi que ce soit d'autre que des actions ultra-simples (je n'ai pas à gérer la pile d'appel, je n'ai pas à gérer la portée des variables ...)
Gain : je peux vérifier qu'aucune fonction illégale n'est appelée (fopen = niet).
Gain : je peux modifier le fichier dans des zones prévues à cet effet.
Gain : ça fonctionne sur toutes les plateformes (il faut recompiler la console, mais pas le jeu, comme pour une rom standard).

Pour le redire encore, je veux pouvoir écrire
gcc -c -o blabla.o blabla.c
gcc -c -o blibli.o blibli.c
...
gcc -o game main.c blabla.o blibli.o

Et hop j'obtiens un fichier "game" que je peux donner à manger à ma machine virtuelle qui ira chercher le/les point(s) d'entrée et l'exécutera.
Il faudrait que dans le fichier "game" il y ait une liste de toutes les fonctions ayant besoin d'être résolues (c'est-à-dire les fonctions non-présentes dans le fichier game lui-même). Genre si "game" utilise une fonction de l'API, il n'a pas le code de la fonction, juste l'en-tête. Cette fonction atterrit dans cette liste.
Au lancement, la machine parcours cette liste.
Chaque entrée ressemble à quelque chose comme
chaîne de caractère (=le nom de la fonction) -> un entier (initialement 0 partout).
Pour chaque entrée, la machine décide de
1/ rejeter le programme, si l'entrée est illégale (genre si c'est fopen).
2/ remplacer l'entier (si la fonction est valide).

Le programme utilisera ces numéros pour appeler les fonctions.

Ce genre de chose, et déjà je spécifie un peu trop, je n'exige rien de tout cela.
La seule chose dont j'ai besoin c'est de ce gcc-like.

C'est pour ca que le probleme est deja assez complique sans avoir a reinventer un assembleur.

C'est pour ça que je ne veux pas forcément en réinventer un. Si j'ai à le faire, je peux le faire, mais si je peux/dois m'en passer, c'est aussi bien.

C'est un probleme d'API ca, l'OS ou le platform dev kit, il te donne une lib statique (en l'occurence c'est qoi qui va l'ecrire) et la verification de signature est faite par le compilateur.

Oui, tu ne m'apprends rien.
Maintenant, comme tu l'a souligné c'est moi qui écrit le dev kit.
Et je préférerais éviter de recopier les valeurs des enum, les signatures de fonction etc.
Je voudrais que le dev kit puisse réutiliser les fichier d'entêtes utilisés par l'api elle-même.

En ce moment (la solution actuelle, complètement horrible dont je veux bouger) le "devkit" c'est mingw.
Il produit un dll (le fichier "game") et j'utilise dlopen et consort pour trouver le point d'entrée. Mais ça pose les problèmes que j'ai mentionné.

Si tu change le langage assembleur, il faut reecirre toute la couche de generation d'assembleur. Et ca c'est bourre d'optimisation que tu n'as probablement pas envie de reecrire.

Je n'ai pas envie de les réécrire. C'est une des raisons pour lesquelles l'approche yacc/lex ne me paraît pas bonne.

J'ai l'impression que tu confond compilateur et linker.

Je ne les confonds pas dans ma tête, mais c'est confondu dans le texte.
Maintenant, j'aimerais bien avoir un compilateur, je ne vois pas trop ce que je peux faire avec les fichiers objets.
(je ne suis même pas certain que les fichiers objets soient dans un format standard, pour le compte je n'y connais rien).

Tu proposes que ma machine virtuelle prenne en entrée des fichiers objets (c'est une vrai question) ?

Tu proposes que ma machine virtuelle prenne en entrée des fichiers objets (c'est une vrai question) ?

Je ne comprend pas ton probleme. Ca m'a l'air trivial.

Ok une solution simple.

1) Tu compile avec gcc pour l'archi de ton processeur.
2) Tu link contre une libstatique qui definit les fonctions du systeme. tu ne link contre la libc.
3) Toutes les fonctions de la lib ecrivent a une addresse qui correspond a un registre materiel de ton architecture.
4) Tu linkes en mettant en definissant ton propre entry point avec le parametre de map qui va bien qui dit ou les choses doivent aller.
5) Ton emulateur quand tu ecris a cette addresse la passe la main au bios/vm/ring0/whatever ton archi supporte qui sert a faire ca. Ce bios lis la pile pour savoir quels sont les parametres.

Le 14 février 2019 à 04:21:30 godrik a écrit :

Tu proposes que ma machine virtuelle prenne en entrée des fichiers objets (c'est une vrai question) ?

Je ne comprend pas ton probleme. Ca m'a l'air trivial.

Ok une solution simple.

1) Tu compile avec gcc pour l'archi de ton processeur.

Physique ou virtuel ? Parce que si c'est "virtuel", ta phrase revient à dire : "tu mets paris en bouteille".
Parce que justement, pour définir un nouveau "backend" à gcc, c'est-à-dire lui spécifier une architecture autre que celle qu'il utilise de base, c'est la croix et la bannière.
Et pour le faire avec llvm il faut le recompiler et pour ce faire il faut avoir visual studio.

Et si c'est "physique" alors ça devient dépendant de la machine.

2) Tu link contre une libstatique qui definit les fonctions du systeme. tu ne link contre la libc.
3) Toutes les fonctions de la lib ecrivent a une addresse qui correspond a un registre materiel de ton architecture.
4) Tu linkes en mettant en definissant ton propre entry point avec le parametre de map qui va bien qui dit ou les choses doivent aller.

Ca ça m'a l'air bien. Je vais chercher comment faire (il n'y a pas d'ironie). Mais c'est une toute petite brique de réponse.

5) Ton emulateur quand tu ecris a cette addresse la passe la main au bios/vm/ring0/whatever ton archi supporte qui sert a faire ca. Ce bios lis la pile pour savoir quels sont les parametres.

Oui, tout ça c'est gentil, ça suppose quand même la première étape.
Je t'accorde quand même un point : ça a l'air trivial.
Ca m'avait aussi l'air trivial quand je me suis lancé là-dedans.

Ensuite j'ai appris que les processeurs (physique) étaient semble-t-il livré avec des outils permettant aux compilateurs de produire du "bon" code.
Que pour faire que gcc produise du code pour l'architecture MIPS, il n'existait pas de solution standard (il existe un truc custom sur linux).

Et je doute fortement que les 24ko du fichier .exe associé au "printf("hello world");" soient le résultat de l'édition de lien seule.

J'apprécie tes interventions, mais j'ai l'impression que tu te fais des idées sur la complexité du bidule. Je sais qu'on dit "qui peut le plus peut le moins", mais en l'occurrence gcc (ou plutôt mingw) fait le plus mais c'est "sort ton bandeau de rambo et ta machette" pour faire le moins.

C'est même tellement vrai que c'est l'une des raisons à la création de llvm, avoir un compilateur qui soit plus facile à "retargeter", qui permette plus facilement de compiler vers différentes architectures.

Je ne comprends pas ce que tu dis. La cross compilation avec gcc, c'est super vieux. Du mips, c'est du mips (je ne connais pas bien mips, donc il y a peut etre des extensions comme ARM). Tu compile gcc avec les flags de crosscompile et ca te donne un gcc pour ta plateforme qui genere des objets pour la platforme cible.

C'est gros comme ca que fonction e toutes les chaines de compilation pour des consoles de jeu. Peut etre tu devrais regarder comment se passe la compilation pour gba par exemple, c'est super bien documente. Et c'est la chaine de compilation standard que tu utilise, recompile pour de l'arm7. (gcc, ld, et binutils)

Je t'ai lu, je ne pourrais pas répondre ce soir. Je comptais (et je compte) mettre la liste des recherches faite (pas complète, il s'agissait de donner des exemples) et les problèmes présents dans chaque résultat obtenu.

Cependant, en faisant cela (en recommençant encore à rechercher) je suis tombé sur le site "osdev"
https://wiki.osdev.org/Main_Page

Je ne sais pas s'ils pourront m'aider. Il me reste une petite heure pour leur faire un message ce soir.
Du coup, je ne peux pas répondre ce soir, mais je continue à être actif sur le sujet.

Bon, finalement je vais rédiger un truc chez moi et le poster demain, rien ne presse et ce soir l'anglais ne sort pas.
Du coup j'ai le temps de répondre à ce topic.

La cross compilation c'est super vieux sur gcc, mais pas vers des architectures custom.
Les recherche "gcc cross compilation" me renvoient des résultats sur comment compiler un programme pour Windows depuis Linux.
Si je rajoute "virtual/custom machine/architecture/os" ça ne renvoie rien de pertinent. On tombe alors sur des liens sur comment compiler gcc pour différentes architectures. Des trucs chelous.

La plupart des liens parlent aussi de gcc, pas de mingw.
On va généralement avoir en prérequis de tourner sur un linux et d'avoir une connexion internet (c'est-à-dire que les installations font des apt-get dans tous les sens).

Si tu ne me crois pas, fais la recherche
"create custom libc"

On ne peut plus clair, non ?
Eh bien ça va parler de tout, mais pas de ça. Ca va parler de comment "créer une librairie en C" (hors sujet) de comment compiler la libc (hors-sujet) de comment réduire la taille de la libc (gné ? hors sujet).
Au milieu de tout ça, un mec qui post
"How to compile gcc with a custom libc for a custom os?"

Fantastique !
...
Aucune réponse

La cross-compilation suppose toujours que les deux architectures (celle d'où l'on compile et celle vers qui on compile) existent déjà et que la question est "comment dire à gcc d'utiliser ce qu'il possède".

Parce que, que ce soit windows ou linux, un fichier compilé n'est jamais uniquement le code que tu as écrit. Il y a toujours un tas de blabla indispensable pour tourner sur tel ou tel os. Et comme c'est indispensable, c'est là par défaut dans le compilateur. Ne pas avoir ce blabla inutile n'est pas une option.

Lors de mes recherches initiales, j'étais tombé sur cette page
https://stackoverflow.com/questions/10617215/how-to-write-your-own-code-generator-backend-for-gcc

qui te dirige rapidement vers "gcc internals".
Un document qui au format pdf fait ni plus ni moins que 800 pages.

Et dans lequel on apprend que pour définir un backend, il faut définir ... un paquet de fonctions (vraiment vraiment beaucoup).

Du coup je me tourne vers llvm, et sa doc
https://llvm.org/docs/

Et là attentions pavé dans la gueule/mawashigeri derrière la nuque
https://llvm.org/docs/LangRef.html

Et pour rien, puisqu'il faut le visual studio.

Etc.
J'apprécie ton aide. Mais si tu prenais deux minutes pour faire les recherches, tu te rendrais compte que ce que tu penses être trivial ne l'est pas. C'est systématiquement l'usine à gaz, où si ce que tu veux faire c'est "compiler pour windows depuis linux" ça sera facile, mais si ce que tu veux faire sort des sentiers battus alors c'est la mort.

Les mos-clefs, j'en ai.
Commencer à avoir un bout de truc qui fonctionne duquel je pourrais développer le reste, pas moyen.
Et à chaque fois c'est des jours entiers de perdu, un projet qui n'avance pas et une motivation qui s'en va.

Il n'y a rien de plus "project-killer" que d'être bloqué sur un problème pendant des mois.

C'est pour ca que je te dis de prendre une architecture du processeur connu pour que tu n'ai pas a a reecrire un back end. apres tu peux faire l'archi de la machine comme tu veux. mais prend une archi processeur classique.

comme tu developpes sur la machine directement tu as juste besoin de code executable a passer dans le processeur. Tu met le code en memoire. tu pointes instruction pointeur la ou le code commence. et pan c'est parti.

Si tu inventes ton propre jeu d'instruction pour ton processeur, il va falloir écrire un backend gcc ou llvm, comme ça a été dit. Mais c'est un énorme boulot et c'est très peu (voire pas du tout) documenté, que ce soit du coté de gcc ou llvm.
C'est plus simple de choisir une architecture déjà supportée par gcc, comme godrik propose.

Après ça, en fin de compte ce que tu va faire, c'est une VM pour le processeur que tu auras choisi et tout le reste des périphériques qui composent ta console et un OS capable de charger des exécutables.
Pour l'OS et le sdk, t'as beaucoup de ressources sur osdev.org. Par exemple pour mon la libc de mon OS, j'ai choisi d'en porter une existante en suivant : https://wiki.osdev.org/Porting_Newlib
Et pour avoir le compilateur utilisé pour compiler les programmes utilisateur : https://wiki.osdev.org/OS_Specific_Toolchain

Le 16 février 2019 à 19:52:16 AtmelAVR a écrit :
Si tu inventes ton propre jeu d'instruction pour ton processeur, il va falloir écrire un backend gcc ou llvm, comme ça a été dit. Mais c'est un énorme boulot et c'est très peu (voire pas du tout) documenté, que ce soit du coté de gcc ou llvm.
C'est plus simple de choisir une architecture déjà supportée par gcc, comme godrik propose.

Oui, ok.
Je pense que c'est ce que je vais faire.
Un point d'entrée à ce domaine ? (genre : des mots-clef, des suggestions, des noms, des documents ?)

Là j'ai mit la main sur un pdf de 2700 pages sur l'arm. Comme toujours dans ce genre de cas, c'est un mélange d'excitation et de désespoir, de plaisir et de douleur XD.

J'ai aussi besoin d'un conseil : avez-vous un avis sur l'architecture que je devrais choisir ?
Pensez-vous qu'une architecture sera plus facile à implémenter qu'une autre ?
Tant qu'on y est : savez-vous s'il y a des brevets sur les implémentations ? C'est-à-dire ais-je le droit d'implémenter une architecture physique sachant qu'elle est probablement la propriété d'une entreprise ?

(ou est-il impossible de breveter un jeu d'instruction assembleur, si bien que je peux l'implémenter sans risquer de me faire striker mon travail par la suite, si bien que je peux l'implémenter et le diffuser sous une licence libre sans me prendre un procès).

Après ça, en fin de compte ce que tu va faire, c'est une VM pour le processeur que tu auras choisi et tout le reste des périphériques qui composent ta console et un OS capable de charger des exécutables.

Oui. C'est ce qui est prévu.
Et sachant que je me repose de toute façon sur une architecture physique bien réelle (c'est-à-dire que le programme de ma machine virtuelle tournera, lui, sur une machine et un os bien réelle) ça me dispense d'énormément de travail.

Pour l'OS et le sdk, t'as beaucoup de ressources sur osdev.org. Par exemple pour mon la libc de mon OS, j'ai choisi d'en porter une existante en suivant : https://wiki.osdev.org/Porting_Newlib
Et pour avoir le compilateur utilisé pour compiler les programmes utilisateur : https://wiki.osdev.org/OS_Specific_Toolchain

Ce que tu dis m'intéresse beaucoup. Parce que ça veut dire que ce que je veux faire est possible
Je vais regarder avec grand soin ces liens.

Et je vous remercie d'autant plus (tous les deux) qu'enfin j'ai quelque chose de concret, des noms, des liens
Là j'ai envie de mettre du jurassik park "les affaires reprennent".

Merci merci en tout cas. Et je pense que ce n'est pas finit (hélas pour vous ^_^)

disclaimer: je ne suis pas un avocat.

La question est complique. Mais en bref, Intel a foutu des proces a des tonnes de boites qui pondait des machines avec le meme jeu d'instructions. Il y a un cas similaire en justice aux USA maintenant entre oracle et google sur lapossibilite de breveter une API. (en l'occurence le cas entre google et oracle est logiciel, mais c'est suffisement proche pour que les implications legales puisse se porte de l'un a l'autre.)

Dans le monde du development materiel c'est risc-V qui a le vent en poupe et est de l'open hardware. J'ai des collegues qui vont acheter du risc-V/NVlink/NVidia. J'ai hate de mettre la main dessus!

Apres, je ne sais pas si j'utiliserais ca dans une console en vm. Je ferais du MIPS pour commencer parceque ca a l'air vachement plus simple.

Le 17 février 2019 à 05:48:16 godrik a écrit :
disclaimer: je ne suis pas un avocat.

La question est complique. Mais en bref, Intel a foutu des proces a des tonnes de boites qui pondait des machines avec le meme jeu d'instructions. Il y a un cas similaire en justice aux USA maintenant entre oracle et google sur lapossibilite de breveter une API. (en l'occurence le cas entre google et oracle est logiciel, mais c'est suffisement proche pour que les implications legales puisse se porte de l'un a l'autre.)

Dans le monde du development materiel c'est risc-V qui a le vent en poupe et est de l'open hardware. J'ai des collegues qui vont acheter du risc-V/NVlink/NVidia. J'ai hate de mettre la main dessus!

Apres, je ne sais pas si j'utiliserais ca dans une console en vm. Je ferais du MIPS pour commencer parceque ca a l'air vachement plus simple.

Ben oui le mips c'est ce que je voulais faire.
C'est en plus ce que j'ai appris à l'université (quand j'ai appris l'architecture des ordinateurs).
Mais je n'ai pas trouvé comment faire pour que mingw crache du mips :/

Mais tu aimes la douleur pour faire ca sous windows? Ce genre de truc, les tool chains sont en general pondu sur des systeme unix. Et porter a posteriori sur windows..

Cet article a l'air de bien decrire le process de bootstrap. https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
Il a publier les script bash qui vont bine pour faire tout ca.
Et je dirais que le target que tu veux est mips-unknown-elf si je devais parier. (Je suis entrain de compiler un binutils pour verifier que c'est possible)