Triceraprog
La programmation depuis le Crétacé

  • Utilisation de z88dk pour le VG5000 ()

    Encore ?! Oui... encore. Une nouvelle manière de gérer la construction d'un programme VG5000µ. Après la version Sublime Text et z80asm en 2018, puis la version Visual Studio Code et sjasmplus en 2020, je voulais essayer autre chose.

    J'avais laissé de côté Sublime Text et z80asm pour deux raisons : le changement de license de Sublime Text que je n'avais pas apprécié, et le côté très simpliste de z80asm, dont je touchais des limites.

    Pour un nouveau projet, je voulais utiliser z88dk, un kit de développement pour machines Z80, avec du support C et ASM, ainsi que des bibliothèques standards. Je voulais aussi approfondir ma connaissance du support de toolchains avec CMake.

    Alors oui, cmake pour un tout petit projet pour des machines des années 80, ça fait un peu surdimensionné... Je le concède. Et ça n'enlève en rien mon envie de fouiller de ce côté.

    Un exemple, qui peut servir de base, est disponibles sur GitLab et GitHub. Il y a quelques limitations quand à l'environnement supporté, car je n'ai testé que sur mon ordinateur de développement.

    Mais l'essentiel est là, et peut éviter des heures de recherches entre la documentation de CMake et StackOverflow, la première était connue pour son aridité et le second pour, en ce qui concerne CMake, ses 99% de réponses fausses, ou tout du moins obsolètes.

    Par la suite, je vais décrire les différents éléments qui forment le projet CMake.

    CMakeLists.txt

    Tout projet cmake a pour point d'entrée un fichier CMakeLists.txt.

    cmake_minimum_required(VERSION 3.20)
    

    Tout d'abord, on indique la version minimale de cmake à utiliser. Il est toujours préférable de mettre celle sur laquelle on a validé le fonctionnement, car cmake évolue souvent et tenter d'en mettre une plus ancienne est acrobatique.

    list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/")
    

    Je vais avoir besoin d'ajouter des scripts de description de machine et de compilateur localement, car non reconnus nativement, du moins aujourd'hui, par cmake. J'indique donc que certains scripts se trouvent dans le répertoire locale cmake/, en modifiant la variable CMAKE_MODULE_PATH.

    project(vg_tests C ASM)
    

    Je déclare ensuite le nom du projet vg_tests, ainsi que les langages de programmation supportés.

    # If need for cmake debug, the next line can help
    # set(CMAKE_VERBOSE_MAKEFILE 1)
    

    Comme indiqué, mettre la variable CMAKE_VERBOSE_MAKEFILE à 1 permet d'avoir des informations sur les actions qui sont faites lors de la génération du projet. Très pratique pour comprendre quelles sont les lignes de commandes générées, avec leurs options. Essentiel pour mettre au point quand on tâtonne.

    set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ../output)
    

    La variable CMAKE_RUNTIME_OUTPUT_DIRECTORY indique où sont les artefacts de sortie. Dans notre cas, c'est là que se trouveront les .k7 utilisables pour le vg5000µ (ou les .wav, si vous le désirez).

    set(SOURCE_FILES src/main.c src/auxiliary.asm)
    

    SOURCE_FILES est une variable interne à ce script. C'est une habitude que de passer par une variable intermédiaire pour spécifier la liste des fichiers sources. Dans certains cas, on peut avoir besoin de la réutiliser.

    Ici, je vais compiler et assembler un fichier C et un fichier assembleur.

    add_executable(${PROJECT_NAME} ${SOURCE_FILES})
    target_compile_options(${PROJECT_NAME} PRIVATE -I$ENV{Z88DK_HOME}/include -Isrc/ -vn -m)
    target_link_options(${PROJECT_NAME} PRIVATE -m -create-app -subtype=default)
    

    La déclaration de l'exécutable utilise la variable PROJECT_NAME, qui prend le nom spécifié dans project() au tout début, et y associe la liste des fichiers sources.

    Puis sont définies les options de compilations et les options pour l'éditeur de liens. La nature des options ne sont pas du domaine de cet article. Elles seront transmises à zcc, qui est la commande générique pour toutes les opérations de construction dans z88dk.

    # Fixes the k7 format for old z88dk versions.
    set(INPUT_FOR_FIX ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${PROJECT_NAME}.k7)
    set(ZERO_FILE ${CMAKE_SOURCE_DIR}/zero-file)
    set(OUTPUT_FOR_FIX ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${PROJECT_NAME}.fix.k7)
    
    add_custom_command(OUTPUT k7_fix
            DEPENDS ${PROJECT_NAME}
            COMMAND ${CMAKE_COMMAND} -E cat ${INPUT_FOR_FIX} ${ZERO_FILE} > ${OUTPUT_FOR_FIX}
            )
    
    add_custom_target(${PROJECT_NAME}-fix ALL DEPENDS k7_fix)
    

    La version actuelle de z88dk a un bug au niveau de la génération des données du VG5000µ. Il manque des octets à la fin, qui sont attendues par la ROM pour valider la fin du fichier.

    J'ai soumis un fix, qui a été accepté, mais le temps que cela soit déployé partout, j'ajoute cette custom_target, qui utilise une custom_command. Le fichier zero-file est le fichier nécessaire à l'ajustement, et ne contient que des 0.

    Compilation croisée

    Lancer cmake tel quel ne va pas fonctionner, car par défaut, cela utilisera les outils de compilation de la machine hôte. Il faut donc spécifier une environnement de compilation croisée, c'est-à-dire les outils pour compiler pour une machine cible, et non la machine hôte.

    Pour cela, cmake a un mécanisme de déclaration de compilation croisée. Lors de l'initialisation de cmake, il faut spécifier la variable CMAKE_TOOLCHAIN_FILE. Ici, cmake -DCMAKE_TOOLCHAIN_FILE=z88dk-vg5000.cmake.

    Ici, on entre un peu dans le tâtonnement. Ce que j'expliquer fonctionne, mais est-ce que c'est carré ? C'est une bonne question.

    Voici l'explication du fichier z88dk-vg5000.cmake.

    set(CMAKE_SYSTEM_NAME vg5000)
    set(CMAKE_SYSTEM_PROCESSOR Z80)
    set(CMAKE_C_COMPILER_ID z88dk)
    set(CMAKE_ASM_COMPILER_ID z88dk)
    

    En premier lieu, on fourni des valeurs à des variables internes de cmake indiquant le nom du système, le processeur, et des identifiants du compilateur et de l'assembleur. Ces variables seront utilisées par cmake pour déterminer quels fichiers de description il doit chercher.

    Il n'est pas toujours très clair de savoir quelle variable influe sur quoi. Il faut se fier aux messages d'erreurs lorsqu'un fichier n'est pas trouvé...

    set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
    

    Cette variable indique à cmake si, pour valider le fonctionnement de la chaîne de compilation, un essai se fera sur une bibliothèque ou sur un exécutable. L'exécutable, pour être validé, doit être lancé. Comme je ne définie pas de moyen de lancer l'exécutable, je demande à ne faire l'essai de compilation que sur une bibliothèque, ce qui est en fait le défaut lors d'une compilation croisée.

    set(TOOLCHAIN_PREFIX z88dk)
    set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}.zcc)
    set(CMAKE_ASM_COMPILER ${TOOLCHAIN_PREFIX}.zcc)
    

    Ici, j'indique le nom des compilateurs et assembleur. Pour cmake, tout ce qui prend une source et sort un fichier objet est un compiler. Pour z88dk, je passe par le frontend zcc plutôt que les exécutable eux-mêmes, ce qui semble être préféré dans la documentation (et dans la façon dont est construit le paquetage).

    set(CMAKE_DEPENDS_USE_COMPILER True)
    

    J'indique aussi à cmake d'utiliser le compilateur pour trouver les dépendances entre les fichiers.

    set(CMAKE_C_COMPILE_OBJECT  "<CMAKE_C_COMPILER> +vg5k <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>")
    set(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> +vg5k <FLAGS> <OBJECTS> -o <TARGET> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>")
    
    set(CMAKE_ASM_COMPILE_OBJECT  "<CMAKE_C_COMPILER> +vg5k <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>")
    

    On y est presque. Dans un cas classique où le compilateur se comporte de manière classique (disons comme un gcc, un clang ou autre), on pourrait se passer de ces lignes. Mais zcc à besoin comme premier paramètre de la plateforme cible (+vg5k ici).

    J'indique donc à cmake comment générer la ligne de commande pour les fichiers C et ASM, avec une syntaxe de template.

    set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
    set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY NEVER)
    set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE NEVER)
    

    Et enfin, je demande à cmake de ne pas chercher à résoudre les commandes find_library, que je n'utiliserai pas.

    Et ce n'est pas fini !

    Le fichier de compilation croisée indique que l'on compile pour VG5000µ. Mais cmake ne connait pas cette plateforme, et va donc chercher un script qui lui en dirait plus.

    Ce que j'ai fait n'est probablement pas entièrement correct, car j'associe la plateforme avec la chaîne de compilation. Et je fais ça dans le fichier cmake/Platform/vg5000.cmake.

    set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)
    

    z88dk ne supporte pas un systmème de bibliothèque dynamiques (style DLL, so ou dynlib).

    set(CMAKE_C_OUTPUT_EXTENSION .o)
    

    z88dk ne reconnaît que l'extension .o comme fichiers objets. On indique donc à cmake de produire des fichiers objets avec cette extension.

    set(CMAKE_SYSTEM_INCLUDE_PATH $ENV{Z88DK_HOME}/include)
    set(CMAKE_SYSTEM_LIBRARY_PATH $ENV{Z88DK_HOME}/lib)
    set(CMAKE_SYSTEM_PROGRAM_PATH $ENV{Z88DK_HOME}/bin)
    

    Ces variables ont l'air d'être les pendants des CMAKE_FIND_ROOT_PATH_MODE_* indiqués dans le fichier de compilation croisée. Le fonctionnement n'est pas hyper clair.

    Voilà, à présent cmake sait compiler un fichier C avec z88dk pour VG5000µ.

    Et l'assembleur ?

    Pour une raison que je n'ai pas creusé, mais probablement concernant la séparation des plateformes des compilateurs, le support d'un assembleur nécessite un autre fichier, différent du précédent vg5000.cmake.

    C'est dans cmake/Compiler/z88dk-ASM.cmake que cmake va chercher l'outil pour traiter l'ASM pour z88dk. Ce qui se tient. Pourquoi est-ce qu'il ne va pas chercher z88dk-C.cmake au même endroit, cela m'échappe...

    Le contenu est strictement identique à celui du fichier vg5000.cmake, puisque l'on s'adresse au même outil zcc.

    Et la cerise optionnelle

    Le fichier z88dk-clion.yaml est un fichier qui ajoute un support de z88dk (assez succin) à Clion. Par défaut, lors de la génération de cmake, l'IDE va essayer de trouver un certain nombre d'information en interrogeant le compilateur. Les #define par exemple, ou les répertoires d'inclusion par défaut.

    Mais zcc ne réagissant par bien à la question, Clion affiche un warning. Il est cependant possible de lui indiquer manuellement les informations recherchées, et c'est le but de ce fichier. Cependant, sa description tombe hors du sujet de cet article.

    Conclusion

    Ça a été une aventure, comme à chaque fois que l'on sort des sentiers battus avec cmake. J'y ai appris un peu plus de choses, ce qui était probablement l'objectif initial. Et j'ai une façon de générer un programme VG5000µ à partir de tout outil qui utilise cmake, ce qui couvre aussi Visual Studio Code.


  • Apprendre l'assembleur... mais comment ? ()

    Il y a peu, j'ai eu une discussion à propos de l'apprentissage de l'assembleur. La discussion était partie de l'envie d'une personne de créer un jeu sur MSX, mais directement au niveau de la machine, plutôt que de passer par un langage de haut niveau, comme le BASIC natif. Et pourquoi pas. Une donnée importante : la personne en question connaît déjà la programmation, c'est donc un abord de nouveau langage dont on parle, et non des concepts généraux du développement d'un programme.

    Lorsque l'on aborde un langage de plus haut niveau, que ce soit BASIC ou Pascal, on va se concentrer sur la manière d'exprimer des concepts dans ce langage en particulier. Lorsque l'on connaît déjà un autre langage de même famille (large), il s'agit même souvent de comprendre quelle sont les particularité du langage appris.

    Lorsque l'on aborde une machine en particulier dans un langage de haut niveau, il s'agit en suite de connaître les bons appels, les bonnes fonctions, particulières à cette machine.

    Mais comment démarrer en assembleur ? Avec l'assembleur, toute la couche d'abstraction est retirée, il n'y a plus de concept de variables, de fonctions, de structures de données, on se retrouve face à face à la machine. Cela implique en premier lieu qu'apprendre l'assembleur, c'est apprendre le fonctionnement particulier de cette machine, et même pas seulement du fonctionnement du processeur.

    Quand on regarde les ressources qui enseignent l'assembleur, que ce soit pour une machine ou seulement un processeur, on se retrouve avec une structure assez similaire où il est d'abord expliqué l'arithmétique et la logique binaire, la représentation des entiers, puis sont abordés les registres et globalement l'architecture du processeur. Ce sont des dizaines de pages à comprendre, suivre... et la plupart du temps sans exercice pratique, sans mise en application. Cela semble sous-entendre que pour démarrer la moindre opération, il faut lire une centaine de pages.

    Lorsque l'on a déjà des connaissances sur d'autres machines et processeurs similaire, cela peut aller vite. Mais lorsque c'est le premier abord du mode du bas niveau, c'est beaucoup à ingurgiter et probablement très démotivant.

    Je me suis posé la question de comment pourrait être abordé la question, j'ai pris quelques notes et je vais m'essayer à l'exercice dans des articles qui suivront. Mon objectif est de pouvoir construire de la connaissance sur la programmation en assembleur pour des personnages qui n'en n'auraient jamais fait.

    Voyons ce que cela donne...


  • Baisse de régime... en apparence. ()

    Après une grosse activité sur le VG5000µ principalement, il y a eu bien moins d'article sur Triceraprog, et la troisième vidéo sur les langages de programmation qui est prévue depuis deux ans n'est toujours pas là. Mais que se passe-t-il ?

    En Janvier 2021, l'association M05.COM m'a proposé de travailler sur le projet de restauration et de documentation d'un « Micral N ». Toute l'année 2021, avec d'autres membres de l'association, nous nous sommes plongé dans la compréhension de cette machine historique, ainsi que dans la création d'une version virtuelle qui a permis d'en comprendre les détails.

    C'est une activité passionnante, j'ai appris énormément de choses et j'ai même pu écrire (ou porter) une poignée de logiciels pour cette machine. Forcément, mes autres sujets en ont pâti et le VG5000µ est un peu en pause. Mais il est toujours sur mon bureau prêt à reprendre du service.

    La communication des avancées sur le « Micral N » ayant besoin d'être coordonnée avec l'association, je ne parle pas des avancées sur Triceraprog. En tout cas pas pour le moment, à part la petite présentation du 8008 que j'ai écrite il y a quelques mois.

    Un live Twitch est visible où nous présentons la machine. Malheureusement un peu gâché par des problèmes de micros.

    J'ai hâte de pouvoir parler de cette machine plus en détails.


  • Récréation 3D, Apple II ()

    L'un des tout premiers micro ordinateurs de très grande popularité, particulièrement aux États-Unis. L'Apple II.

    Voici une recréation en synthèse, avec un moniteur ambre posé lui-même sur une paire de lecteurs Disk II.

    Apple II


  • Récréation 3D, CDC 6400 ()

    Le langage Pascal, nommé ainsi en référence à Blaise Pascal, concepteur de la Pascaline, a été développé sur une machine nommée CDC 6400. C'est une machine de type mainframe, un gros truc, même si la version 6400 est une version allégée d'une autre de la gamme, et dont l'unité de mémoire adressée a une largeur de 60 bits.

    Voici une recréation en synthèse, où l'on voit en premier lieu la console avec ses deux écrans ronds, hérités des écrans de RADARs. Les calculs sont fait dans les grosses armoires que je n'ai pas détaillées.

    CDC6400


Page 1 / 17 (suivant) »