Nous sommes actuellement le 14 Décembre 2018, 07:31

KGC-DSKY

Discutez des add-ons, ce que vous en faites, des trouvailles etc...

KGC-DSKY

Message par Mahzel » 06 Octobre 2013, 22:48

Bonsoir!

Voilà comme j'en ai déjà un peu parlé sur d'autres forums, je travaille sur un plugin d'émulation de l'AGC (Apollo Guidance Computer) et du DSKY (DiSplay and KeYboard).
Vous l'avez sans doute tous déjà vu, soit dans des films, soit dans des documentaires, ou au moins entendus parler. Pour les quelques réfractaires, voiçi une photo du DSKY :
[Reveal] Spoiler: DSKY
Image

Une photo de l'AGC a peu d'intérêt vu que c'était beaucoup de filasse dans des boites en métal. Je redirige les curieux vers le wikipédia, qui s'en sort pas trop mal sur le sujet. AGC/DSKY

Le truc c'était donc pas mal de filasse, et des specification digne d'une calculatrice de bureau.
-Système 16bits
-2048 mots de mémoire RAM (1 mot : 2 octets... Ca fait.... 4096 octets de RAM. Sacré barrette, hein?)
-36864 mots de mémoire ROM (l'équivalent de nos CD-R, non réinscriptible, mais en version ultra-slim. 73 728 octets)
-Un cycle machine de 12ms (85Hz, ca c'est du "CPU")

Bon et avec tout ça fallait faire voler une fusée. C'est un peu le défi que je me propose, et que je vous proposerai, donc, quand le plugin sera finalisé.
A l'intérieur, rien de précoder, le plugin sera livré avec un compilateur (KYUL, sans jeu de mots, l'original s'appellait YUL, et si je remplace le Y par K, c'est trop... 'fin voilà.). Enfin je dit compilateur, en fait c'est un assembleur.
Un petit exemple avec la portion de code du Luminary (le programme du LEM) qui sert à poser le machin sur la lune.
The Luminary Lunar Landing

J'en suis pour l'instant à la phase plugin brute (c'est à dire que j'ai besoin d'un truc qui marche déjà en ligne de commande), et c'est vraiment le tout début.

un début de wiki est dispo (pour l'instant plus technique que plugin) en français(02/11/2013)
Wiki gitHub

Sur le github, le code est normalement a peu près commenté, si y'en qui s'intéressent à la source. Mais c'est en anglais (et non, désolé, celui-là je le passerai pas en français.) J'ai encore pas mal de précision à apporter sur le fonctionnement interne de certaines fonctions (notemment celles qui manipulent les registres dans l'AGC et YUL, mais c'est du WIP.)

Avancée du truc : 07/11/2013
[Reveal] Spoiler:
Changelog :
    07/11/2013
    -API : Gestion des valeurs négatives.
    -AGC : Opcode TC (Transfer control)
    -YUL : gestion des operands relatif (+x / -x)

    06/11/2013
    -Refactoring du code pour plus de clareté et lisibilité.
    -Recodage de fonctions de l'AGC_SUPPORT, YUL et AGC pour optimiser certains appels.
    -Renommage des fichiers de YUL_GUI pour clarifier le truc.
    -Un fichier "AGC_Test.agc" est inclus à l'application de test en CLI de l'AGC pour voir ce que ça donne.
    -Gestions des erreurs dans YUL, qui est maintenant opérationnel (soit via le GUI, soit en CLI via une application codée).
    -Doc de YUL en cours de rédaction.

    03/11/2013
      YUL : YUL fonctionne et devrait compiler le code AGC normalement. Le code interprété n'est pas encore géré.
      YUL GUI : c'est moche, mais ça fait ce qu'on lui demande. Je le laisse en état pour l'instant, c'est pas ma priorité, ça tient lieu de placeholder pour un futur debugger.
      Wiki GitHub : Ce qui avait été tapé est maintenant traduit en français. Maintenant faut que je le continue.
      AGC :
        Les premiers opcodes sont implémentés (TS CA AD).
        Du coup j'ai réussi à gérer les accès en mémoire fixe qui auparavant provoquait une réecriture des registres de l'AGC. Plus dur au codage, mais plus simple à l'utilisation maintenant : on dispose de banques méméoires accessibles de n'importe où, n'importe quand :)
        Pas mal d'optimisations dans les classes de support. Plus les opérations intra-cycles seront courtes, meilleur sera le timing pour avoir un temps d'exécution réaliste.

    08/10/2013 :
      YUL: Résolutions des labels Reconnaissance des OPCODEs Changement de bank. TODO : Implémentation des instructions de compilation

    06/10/2013 :
      Accès mémoire et fichier mémoire : DONE (Bank class)
      Manipulation de mots de 16 bits : DONE (sWord class)
      Emulation d'horloge : TODO (placeholder CLOCK class)
      AGC : TBC
Dernière édition par Mahzel le 07 Novembre 2013, 23:46, édité 9 fois.
Avatar de l’utilisateur
Message(s) : 42
Inscription : 21 Décembre 2012, 17:04
Localisation : Non renseignée

Re: KGC-DSKY

Message par Granolat » 07 Octobre 2013, 08:25

Je ne pense pas que ça aide beaucoup, mais à tout hasard...
http://stanetdam.com/exclusif-le-code-s ... apollo-11/
Avatar de l’utilisateur
Message(s) : 606
Inscription : 30 Janvier 2013, 09:04
Localisation : Non renseignée

Re: KGC-DSKY

Message par Hitman458 » 13 Octobre 2013, 01:40

C'est un gros gros projet ça !!! Mais j'adore !

Je m'étais intéressé à l'AGC il y a quelques temps pour en fabriquer un.
Il y a un addon pour Orbiter NASSP qui utilise un émulateur d'AGC Virtual AGC, il y avait pas moyen de repartir de l'émulateur existant pour l'interfacer avec KSP ?
Github KSP des membres du forum https://github.com/kerbalspaceprogram-fr
Avatar de l’utilisateur
Message(s) : 113
Inscription : 15 Septembre 2013, 04:49
Localisation : France

Re: KGC-DSKY

Message par Mahzel » 14 Octobre 2013, 10:57

Bah plusieurs choses :
La première c'est que je simule l'AGC et le DSKY mais aucun des équipements d'à côté (IMU, Star tracker, les radars), donc j'ai pas besoin de certaines fonctions d'interface.
La deuxième c'est que j'aime comprendre avec quoi je travaille et que je trouve la source de vAGC assez mal documentée. En plus c'est en C et certaines portions de code sont largement optimisables grace aux objets.
Tertio, je compte modifier un (tout petit) peu le langage d'assemblage pour simplifier la création de fonctions (revoir le fonctionnement de certains opcodes, en supprimer ou en ajouter...)
Quarto : l'AGC est dimensionné pour comprendre des valeurs type terre-lune. Je dois me débrouiller pour manipuler des valeurs a l'échelle d'un système solaire, ça va peut être causer quelques soucis (c'est pas certains mais je préfère m'y attendre) .
Enfin, je veux coder ce truc de A a Z :p

L'assembleur est bientôt terminé en langage de base. J'ajouterais les fonctions de l'interpréteur ultérieurement. Une fois que je pourrais avoir un code binaire correct pour travailler, j'attaque l'AGC en profondeur. J'espère d'ici la fin de la semaine.
Avatar de l’utilisateur
Message(s) : 42
Inscription : 21 Décembre 2012, 17:04
Localisation : Non renseignée

Re: KGC-DSKY

Message par Hitman458 » 14 Octobre 2013, 19:08

C'est énorme,

Je comprend le besoin de "coder ce truc de A a Z", j'aurai fait pareil xD
J'ai codé une fois un émulateur d'ordinateur à relais Harry Porter's Relay Computer, pour simuler le fonctionnement des registres, de l'ALU, chaque lignes d'écriture ou de lecture des registres sur les différents BUS. C'était plus pour apprendre comment fonctionne un ordinateur que de faire un truc utile xD.

Au lieu de coder en dure la "logique cablée" j'ai utilisé un technique inspirée de l'AGC de John Pultorack qui consiste à "microprogrammer" la logique dans des EEPROM.

J'ai du code sur github, j'ai pas osé le regarder depuis mais il doit bien être dégueulasse, il date d'une époque ancestrale où je n'avais encore jamais eu cours de prog' (genre architecture dégueux, et pire, je codais en Franglais xD).

Emulateur en C++/Qt
Generateur d'EEPROM pour les microcodes

Si je comprend bien dans un premier temps tu te limites à l'assembleur ? Et après tu proposeras des scripts interprétés ? Coder un pilote automatique en assembleur ça va être.... heu... ignoble xD

Je me demande comment tu vas gérer l’interfaçage entre l'AGC et KSP pour "piloter" la fusée. J’imagine ça un peu comme avec les microcontrôleurs, des adresses mémoires de configurations pour piloter les "périphériques".

Edit ::
Tu utilises quoi comme doc ?
Github KSP des membres du forum https://github.com/kerbalspaceprogram-fr
Avatar de l’utilisateur
Message(s) : 113
Inscription : 15 Septembre 2013, 04:49
Localisation : France

Re: KGC-DSKY

Message par Mahzel » 15 Octobre 2013, 09:56

Alors pour le codage,non je ne coderais pas en dur le câblage. Je reproduis l'architecture "interne" du truc. Sa façon de gérer la même, les cycles machines, mais vu qu'on a peu de schémas clairs et complets de l'AGC dur d'aller plus loin.
Pour les programmes ils sont purs assembleurs. Le langage interprété de l'AGC l'était par un interpreteur codé en YUL dans l'AGC. Au lieu de bloquer la mêmoire, l'interpreteur sera une classe a part appellée lors d'un saut vers un emplacement défini.
Code : Tout sélectionner
TC INTP
#CHARGER LA CLASSE DE L'INTERPRETEUR ET CHARGER LES REGISTRES
#AGC SI BESOIN
#PUIS REVENIR A TC+1 ET EXECUTER LE CODE INTERPRETE
-CODE INTERPRETE-
EXIT
#SAUTE VERS LES INSTRUCTIONS DE DECHARGE DE L'INTERPRETEUR
#DECHARGE LA CLASSE
TC EXIT+1


Voila en gros le truc. L'interpreteur servait juste a étendre le jeu d'instructions de l'AGC notamment avec des trucs mathématiques. C'est exactement ce qu'il fera mais même le langage interprété reste de L'assembleur. Et oui je coderais un pilote auto comme ca.

Pour ce qui est de l'interface avec KSP, j'ai plusieurs solutions mais la plus évidente et la plus proche de la réalité est d'écrire dans la memoires de l'AGC les dites données (dans le fichier binaire). Ma peur c'est les conflits d'accès au fichier. Du coup je vais peut être tout bêtement faire une classe / thread pour l'interface. Je verrais ce que ça donne. La première solution me plaît mieux, car plus proche d'un fonctionnement reel de l'AGC.

More question ?
Avatar de l’utilisateur
Message(s) : 42
Inscription : 21 Décembre 2012, 17:04
Localisation : Non renseignée

Re: KGC-DSKY

Message par Hitman458 » 15 Octobre 2013, 17:55

Ok je vois c'est plus un simulateur qu'un émulateur alors, ah et je connaissais pas l'interpréteur de l'AGC. Faudrait que je regarde, j'ai un livre écrit par Eldon C. Hall (le papa de l'AGC) qui explique le fonctionnement de sont petit bébé xD

Mahzel a écrit :Pour ce qui est de l'interface avec KSP, j'ai plusieurs solutions mais la plus évidente et la plus proche de la réalité est d'écrire dans la memoires de l'AGC les dites données (dans le fichier binaire).


Ouais c'est une bonne idée, c'est ce qui se fait de manière naturelle pour coder des drivers ou des trucs proches du matériel, on écrit directement à l’adresse mémoire qui est mappée sur les registres des périphériques.

Mahzel a écrit :[...] (dans le fichier binaire). Ma peur c'est les conflits d'accès au fichier.


Heu je comprend peut être mal ce que tu imagines par là xD , un "fichier" pour interfacer la mémoire de l'AGC avec KSP ? oO
Si l'AGC s’exécute dans KSP, il y a pas de raison d'utiliser un "fichier", un objet C# qui contient les données binaires suffirait, du genre l'instance de la classe Memory de l'AGC.

Pour les conflits d'accès, je suppose qu'en C# on peut retrouver comme en Java le principe des Mutex avec des Semaphores. Je pense que vouloir créer un autre Thread pour gérer les accès concurrentiels est une erreur, les Thread sont justement la source de ces problèmes :(

Et puis avec un Pattern Listener sur les opérations d'écriture/lecture dans la mémoire de l'AGC, ça serait puissant comme interfaçage entre KSP et l'AGC pour contrôler la fusée (pitch, yaw, roll, thrust, autostaging) et récupérer les informations numérique (altitude, speed, PeA, ApA, etc) on peut carrément imaginer des interruptions du processeur sur les événements de KSP.
Github KSP des membres du forum https://github.com/kerbalspaceprogram-fr
Avatar de l’utilisateur
Message(s) : 113
Inscription : 15 Septembre 2013, 04:49
Localisation : France

Re: KGC-DSKY

Message par Mahzel » 15 Octobre 2013, 22:38

Oui c'est plus un simulateur qu'un émulateur. A la base ça devait être un émulateur, mais c'était beaucoup de complexite pas necessaire pour un plugin. Un peu ce pourquoi j'ai choisi de recoder l'AGC plutôt que de prendre vAGC qui est beaucoup plus proche du fonctionnement d'origine.

Pour la mémoire, je passe par le fichier binaire. Je m'explique : l'AGC dispose de sa RAM et de sa ROM, le tout formant 36ko de mémoire à adressage non-linéaire. Quand je compile un programme, je crée une "image" de la mémoire qui va me servir de base de travail. L'AGC est divisé en banques de données (256 mots par banque effacable et 1024 par banque morte). Pour accéder à une banque, je dispose de deux registres FB et EB pour pointer la banque voulue. Ca permettait à l'époque de déclarer des adresses de 16b avec 12b seulements, puisqu'il suffisait de les compléter par le marquer EB/FB approprié.
Ce qui est pratique puisque j'ai au mieux trois banques utilisées en permancence: une effacable pointée par le registre EB, et une morte pointée par FB et la banque vive 0 qui contient les registres et les canaux I/O. Donc plutôt que maintenir une mémoire complète de l'AGC dans une classe, j'instancie la dite banque. Je fait mes manips et je la réecrie dans le fichier en l'état. Le fichier devient une image permanente de l'AGC et permettra un dump en cas de soucis avec le code. Le code programme étant en mémoire morte il n'y a aucun risque d'altération, et la ram sera systématiquement remise à 0 au démarrage.

D'où mon potentiel problème d'accès au fichier. L'EB0 est la banque qui contient les registres, mais aussi les canaux I/O. En gros j'ai l'AGC qui va lire/écrire dedans quasiment à chaque MCT, mais KSP devra écrire aussi dedans les données. J'y ai un peu réfléchi suite à mon post précédent, et je pense que je rafraichirai les données seulement lors du chargement de l'EB0. 1 MCT prend 12ms, j'ai donc largement le temps de me permettre quelques manips supplémentaires du genre, et surtout ça m'évitera de devoir constamment écrire les données de KSP si elles sont inutilisées. Pour l'instant je pense plutôt bien gérer mes accès fichier, mais j'ai pas encore d'interface avec KSP (qui viendra avec le DSKY), c'est là qu'il est possible que ça cafouille.

Pour l'interpréteur, voici la source de l'Interpreteur du Colossus :
INTPRET
pour déclarer une bloc interpréter, il suffisait de TC INTPRET pour initialiser la routine.
Les opcodes interprétés étaient regroupés par deux, suivis de leurs opérandes respectifs, ce qui permettait de compacter le code. Comme tu peux le voir dans la source, c'est surtout des opérations mathématiques, mais ils ont aussi implémentés une espèce de stack etc...

J'ai peut être mal répondu, ou oublié des choses :p hésite pas :)
Avatar de l’utilisateur
Message(s) : 42
Inscription : 21 Décembre 2012, 17:04
Localisation : Non renseignée

Re: KGC-DSKY

Message par Mahzel » 30 Octobre 2013, 16:22

Petit point sur l'avancée du projet même si le code a pas forcément suivi sur github.
-le compilateur fonctionne. J'etendrais le jeu d'instruction ulterieurement. Il est doté d'un debut d'interface graphique qui me sert de placeholder pour un futur debugger. Je travaille sur une doc succinte afin de sortir KYUL "en l'état" pour ceux qui voudraient jouer avec.
-l'agc avance bien (même très bien), je code les différents opcodes, j'ai eu quelques soucis avec la gestion des codes speciaux et des extracodes, mais c'est en passe d'être règlé.

Petite question pour hitman si tu lis ca:
Pour l'interface ksp-agc-dsky, j'ai implémenté une classe "Chanel" que je passe en argument a mes constructeurs agc-dsky. Elle contient un tableau dont les index sont restreints. Tout le monde peux lire où il veux, mais chacun ne peux ecrire que dans ses channels reservés. Ça évite l'accès au fichier, et d'après mes tests je devrais pas avoir de conflit d'accès vu que chaque emplacement même ne peux être écrit que par un distinct. Donc :
-est ce que je vais avoir des conflits d'ecriture, genre ça verrouille le tableau, voir l'objet et pas seulement l'index pointé ?
-je commence a faire joujou avec les delegates du coup, ca marche nickel, mais la encore, est ce que ça peux poser soucis ?
J'ai vu pour un lock de la portion écriture, mais l'inconvénient c'est que j'ai de la perte a la lecture du tableau du coup. C'est nécessaire ?

J'ai jeté un oeil aux sémaphores et mutex, j'ai un peu du mal a bien saisir le truc, en tout cas appliquer a mon cas, les seuls exemples que j'ai trouvé étant gérés dans des threads secondaires appelés par un thread principal au sein d'une même classe.... Bref....

Bonne soirée !
Avatar de l’utilisateur
Message(s) : 42
Inscription : 21 Décembre 2012, 17:04
Localisation : Non renseignée

Re: KGC-DSKY

Message par Hitman458 » 30 Octobre 2013, 19:17

Excellent, j’attendais des nouvelles :)

Ah ouais c'est quand même une architecture assez balèze. Je ne suis pas expert en C#, mais les fonctionnements et les architectures étant les mêmes quelques soient les langages, je me base sur mes connaissances en Java et C/C++ pour répondre.

Donc tu fais du multithreadé là ? Si tu vois un moyen de t'en passer fait le xD. Si tu es en monothread tu n'auras aucun problème.

est ce que je vais avoir des conflits d'ecriture, genre ça verrouille le tableau, voir l'objet et pas seulement l'index pointé ?


Si c'est un tableau tout con genre "int[] array" je ne pense pas que ça pose de problème de verrouillage d'accès. C'est pas le langage qui verrouille ce genre d'accès, (c'est au développeur de le faire en utilisant des semaphores/mutex).

Si c'est un tableau genre "List<int>" ou un truc similaire, là ça pourrait poser problème. Dans ce cas particulier, il existe des versions thread safe et non thread safe des classes pour faire des tableaux, c'est au développeur de choisir quel techno utiliser, (thread safe, c'est bien mais gourmand en performance et c'est plus lent). Les versions thread safe implémentent les verrouillages pour être sur que les modifications ne puissent pas avoir lieu pendant une lecture.

d'après mes tests je devrais pas avoir de conflit d'accès vu que chaque emplacement même ne peux être écrit que par un distinct.


Tu n'auras pas de conflit d'accès, le seul danger c'est la cohérence des données, et qu'un thread utilise une valeur qui ne soit pas à jour par exemple juste le temps de faire un calcul dans une fonction. Il y a des tas de cas où ça ne pourrait pas poser de problème, et il y a des tas de cas où ça poserait de gros problèmes, alors c'est pas facile à dire. Ça dépend de comment tu structures les données, de leur manipulation, de l'atomicité des opérations.

Je prend un exemple à la con, ça va te parler. Comme tu codes de l'assembleur tu imagines bien comment ça peut se passer à très bas niveau, sans les abstractions des langages de haut niveau.

Afficher une chaine de texte en assembleur "Mon texte$" (le $ étant le caractère de fin de chaine pour MS-DOS).
Tu as le thread n°1 qui va écrire "Mon texte$' dans la RAM, l'opération n'est pas atomique :
Le thread n°1 a le temps d'écrire "Mon te".
L'ordonnanceur swap le contexte et donne du temps processeur au thread n°2.
Le thread n°2 va lire cette chaine de caractère pour l'afficher à l'écran.
Il affiche "Mon te@&2°0973...." et 50 kilo octets (donc 50000 caractères) plus tard, il tombe par hasard sur un $ et termine la chaine.
Si tu as de la chance, tu fais pas planter le programme, et tu vas avoir un bug.
Ensuite,
Le thread 1 reprend du temps processeur et termine d'écrire "xte$"
Le thread 2 revient et affiche la chaine "Mon texte" sans bug.

Si tu as moins de chance tu fais planter tout le programme en BAD_ACCESS_MEMORY ou un truc du genre car le thread 2 ira lire dans une mémoire qui n'appartient plus au programme.
Si tu as encore moins de chance tu fais planter que un seul thread et tu vas mettre 5h à comprendre pourquoi le programme ne marche qu'à moitié.

je commence a faire joujou avec les delegates du coup, ca marche nickel, mais la encore, est ce que ça peux poser soucis ?
J'ai vu pour un lock de la portion écriture, mais l'inconvénient c'est que j'ai de la perte a la lecture du tableau du coup. C'est nécessaire ?


J'avoue, je ne connais pas les delegates. Après une recherche sur internet, ça me semble juste un nouveau concept pour écrire du code. Si il y peut y avoir des problèmes sans delegates, alors utiliser des delegates ne ferait que déplacer le problème sans pour autant en rajouter ou en enlever (je pense mais je ne sais pas).

Peut être que ton problème de lock reprend un peu l'exemple au dessus. Tu perds des données car les opérations d'écriture/lecture ne sont pas atomiques ? En java on joue avec le mot clé synchronized, c'est quasi obligé que C# propose une technologie similaire.

Pour C#, Google sort un truc du genre:
Code : Tout sélectionner
[MethodImpl(MethodImplOptions.Synchronized)]
public void SomeMethod() {/* code */}


Mais à ce que je vois, c'est encore plus restrictif que lock().

J'ai jeté un oeil aux sémaphores et mutex, j'ai un peu du mal a bien saisir le truc


Oui c'est vrais que c'est pas évident du tout. Disons que c'est au développeur de choisir une stratégie d'accès, et il y a des algos qu'on peut implémenter pour chacune de ces stratégies. On parle de "producteur" et "consommateur". On utilise des compteurs pour connaitre les nombres de producteurs ou de consommateurs qui utilisent la ressources.
Par exemple on décide de s'autoriser N lecteurs sur la ressource et 1 écrivain. Un thread qui arrive pour écrire peut prendre la ressource, il la verrouille et peut écrire dedans et la modifier.
N thread pourront venir lire la ressource sans problème.
Le thread N+1 qui voudra lire la ressources devra attendre qu'un thread lecteur ait terminé sa lecture.
Les thread qui voudront écrire sur la ressource ne pourront pas prendre le verrous, et devront tout simplement attendre que le thread écrivain libère la ressource.
Dans certains cas, selon la stratégie choisie ou avec un algo bugé, on peut avoir des problèmes d'exclusion mutuelle des threads, et le programme plante car plus aucun thread n'a le droit de continuer son fil d’exécution car la ressource est inaccessible.
C'est au développeur d'implémenter ce comportement, au cas par cas, mais les algos restent toujours les mêmes en suivant les grands principes.


Voilà j'espère que ça a un peu éclairci les problèmes d'accès concurrentiels.
Github KSP des membres du forum https://github.com/kerbalspaceprogram-fr
Avatar de l’utilisateur
Message(s) : 113
Inscription : 15 Septembre 2013, 04:49
Localisation : France

Suivant

Retour vers Les add-ons en général

Qui est en ligne ?

Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit