Casio_asm, assembleur et VM sur calculatrice et PC
Posté le 28/06/2018 12:04
Bonjour à tous (ou bonsoir, ou bonne nuit, je sais pas à quelle heure vous lisez ça)!
En développement depuis aproximativement un mois, j'ai l'honneur de vous présenter mon dernier joujou, Casio_asm!
Il s'agit d'une VM (ou plus exactement, un processur virtuel custom équipé d'un stack, une MMU et d'autres petits trucs sympa) et de l'assembleur qui va avec, avec pour objectif de tourner le plus vite possible, aussi bien sur calculatrice que sur PC. La "chose" a accès aux fichiers (de la mémoire de stockage sur casio, de n'importe où sur PC), à la VRAM, au clavier et (bientot), aux timers.
L'add-in est intégralement écrit en C (je ne suis pas encore super bon en assembleur Super-H, mais j'apprend), et devrait tourner aussi bien sur SH3 que sur SH4, bien que je n'aie pas accès à une SH3 pour faire de tests. Il se compile grâce à une toolchain GCC+Binutils (perso, j'utilise 8.1.0+2.30, mais ça devrait aussi marcher avec des versions plus anciennes) sur Linux (mais Cygwin devrait aussi aller). Il
NE COMPILE PAS sur le SDK de Casio, car le code n'est pas compatible C89. La version PC nécessite la présence des paquets dev de la libsdl2 et tourne sur Linux. Il devrait être simple de la faire tourner sur Windows si quelqu'un connaît l'API WIN32 (ce n'est pas mon cas, malheureusement), il ne manque que les fonctions de gestion des fichiers (et truncate est important).
Le langage en lui même est une sorte d'assembleur, c'est-à-dire que chaque ligne se traduit directement en une instruction processeur. Du coup, le langage est plus difficile à apprendre et à maîtriser, mais il est en contrepartie beaucoup plus rapide et optimisable que du C si on écrit bien.
Ce qui m'a inspiré ce langage est la VM Java, le langage est donc basé sur le stack plus que sur les registres.
L'add-in lit les scripts depuis la mémoire de stockage. Il est aussi capable de les assembler, mais n'essayez pas d'executer un script non assemblé, assemblez-le PUIS executez-le. Pour les éditer depuis la calculatrice, je vous conseille Edit qui a accès à un presse-papiers, ce qui est toujours pratique. Sur PC, laissez tomber les colorateurs syntaxiques, aucun ne reconnait le format.
Le projet
N'EST PAS fini. Il peut donc y avoir de nombreux bugs/crash. De plus, la ToDo list n'est absolument pas vide, il manque donc de nombreuses fonctionnalités. Il est probable que le passage à la version 1.0 ou à des mises à jours casse la compatibilité des programmes, mais il devrait dans la plupart des cas suffir de ré-assembler ou de faire des modifications mineures... En revanche, le programme fonctionne dans la plupart des cas, et les fonctions principales sont opérationnelles.
Page de DL de l'add-in
Repo GitLab du projet
Si quiconque a une idée de fonctionnalité à ajouter, un bug à réparer ou toute autre chose, n'hésitez pas à répondre à ce post ou à créer un ticket sur le GitLab (quand le code y sera).
Sur ce, bonne journée à tous
Citer : Posté le 28/06/2018 12:06 | #
Je t'encourage vivement à proposer un article pour la revue des projets : le lien est ici
Citer : Posté le 28/06/2018 12:12 | #
Euh, je suis supposé mettre quoi dedans? Et même si le projet est toujours en dev, avant même la première release stable? C'est la première fois qu'un de mes projets suscite de l'attention, je n'ai aucune idée de comment gérer ça
Citer : Posté le 28/06/2018 12:15 | #
C'est très simple : ce que tu as mis ici. Tu présentes le projet, tu indiques où il en est. Qu'il soit en dev ou pas, on s'en fiche, au contraire, tu pourrais faire d'autres articles à la RDP pour présenter l'avancement quand tu avanceras.
Et n'attends pas qu'on s'intéresse à ton projet pour le mettre dans la RDP
Citer : Posté le 28/06/2018 12:42 | #
Exactement : si tu as d'autre projet il faut que tu le dise : on peut d'aider à les faire avancer
Citer : Posté le 28/06/2018 13:51 | #
Wait, il y a un MMU ?
Je me considère capable d'écrire du code assembleur de bonne qualité en SuperH, mais GCC est tellement meilleur que moi... ! Ne perds pas ton temps à faire de l'assembleur à part pour utiliser les fonctionnalités inaccessibles depuis le C et optimiser des sections très courtes et très critiques, ça n'en vaut pas la peine
La deuxième assertion est vraie, mais pour les humains, c'est difficile de concourir avec les machins. Est-ce que tu sais que tu peux gagner un cycle si tu places les instructions d'accès mémoire sur des adresses multiples de 4 ? Le compilo le sait et il fait attention à chaque fois !
Je t'invite aussi à essayer d'écrire la fonction suivante en assembleur et de comparer avec le code généré par GCC toutes optimisations comprises. C'est sur cet exemple que j'ai compris que je ne faisais pas le poids... x)
{
return (x < 0) && (y < 0);
}
Enfin ton lien vers le programme est dans un tout petit « ici » facile à rater. Pour plus de visibilité on opte généralement pour des présentations plus imposantes.
Citer : Posté le 28/06/2018 19:04 | #
Je plussoie Lephe pour le compilo. En cours de computer architecture, on fait quelques expériences, ben je te garantis qu'un code C fait intelligemment est beaucoup plus rapide et mieux compilé que la même chose faite à la main en Asm. Surtout en ce qui concerne les probabilités de saut et le loop unrolling par exemple.
Sinon, très beau projet. De ce que j'ai compris ça permettrait surtout de pouvoir développer des trucs sur le PC, tester sur le PC via la VM associée, et d'être sûr que le programme fonctionnera tout pareil oncalc ?
Si je me plante pas, c'est une belle avancée, y'a plus qu'à faire un PoC qui soit classe pour que ça lance le truc
Tu peux en parler dans la boite à idées
Citer : Posté le 28/06/2018 20:21 | #
Wait, il y a un MMU ?
Oui, on a effectivement des pertes de performances, mais c'est la solution la plus simple que j'ai trouvée pour pouvoir adresser des fichiers, le stack, la VRAM ou la RAM avec une interface commune... Et les accès au stack normaux ne passent pas par la MMU, seulement les accès mémoire explicites et la lecture des instructions.
La deuxième assertion est vraie, mais pour les humains, c'est difficile de concourir avec les machins. Est-ce que tu sais que tu peux gagner un cycle si tu places les instructions d'accès mémoire sur des adresses multiples de 4 ? Le compilo le sait et il fait attention à chaque fois !
Je t'invite aussi à essayer d'écrire la fonction suivante en assembleur et de comparer avec le code généré par GCC toutes optimisations comprises. C'est sur cet exemple que j'ai compris que je ne faisais pas le poids... x)
{
return (x < 0) && (y < 0);
}
Enfin ton lien vers le programme est dans un tout petit « ici » facile à rater. Pour plus de visibilité on opte généralement pour des présentations plus imposantes.
J'aurais vraiment dû mieux m'exprimer... Le langage en lequel est écrit mon add-in est uniquement le C, sans la moindre trace d'assembler (c'est d'ailleurs pour ça qu'il est cross-platform); c'est le langage qu'il lit qui est un assembleur. Je ne prétend absolument pas être capable de rivaliser avec GCC, je ne suis même pas décent en asm Super-H. En revanche, je suis certain que GCC ne compile pas pour ma VM, et étant donné que je n'ai pas la moindre idée des durées des instructions ni de comment il peut gérer une architecture basée sur le stack et pas les registres, ça doit être difficile de faire une back-end potable...
Sinon, très beau projet. De ce que j'ai compris ça permettrait surtout de pouvoir développer des trucs sur le PC, tester sur le PC via la VM associée, et d'être sûr que le programme fonctionnera tout pareil oncalc ?
Si je me plante pas, c'est une belle avancée, y'a plus qu'à faire un PoC qui soit classe pour que ça lance le truc
Tu peux en parler dans la boite à idées
Oui, on peut se servir de la VM du PC pour développer, par exemple si on compile avec le flag -DDEBUG, ça affiche les instructions et le stack au fil du programme, au prix de la performance. Mais on peut aussi (et c'était important pour moi) programmer depuis la calculatrice. Les deux VM sont identiques, la seule différence est liée à la SDL et tout ce qui est les différences de hardware. Le code s'exécute pareil dessus, avec à peu près la même vitesse.
Niveau Proof of Concept, j'ai seulement l'algo de calcul de suite de Fibonacci, il faudrait que j'essaye de faire un Game of Life et voir ce que ça donne par rapport à ma version en C