µSTL pour Casio Graph 90+E avec fxsdk gint
Posté le 24/02/2022 12:44
Hello,
j'essaie (tant bien que mal) de faire fonctionner la µSTL (v 2.1 pour le moment, on verra par la suite si on peut tendre vers la v 3.0 qui vient de sortir) avec le fxSDK/Gint.
Je suis partie de l'implémentation de Pavel et ai modifié qq petits trucs pour que ça compile sur Gint, mais relativement peux de choses étaient à reprendre (principalement dans fstream.cc) ou un syscall à BFile_GetFileSize a du etre remplacé par BFile_Size de gint/bfile.h et la definition de deux constantes de errno.h absentes EINTR et EAGAIN (j'ai repris les valeurs adhoc d'une implémentation sur PC de manière un peu arbitraire, juste pour que ca passe).
Avec ces quelques modifs, la compilation de la libustl.a passe (avec -std=c++11).
Je copie donc la libustl.a dans le compilo (gcc.11.1.0 à coté de libc.a et libgcc.a ...) et les headers dans le dossier include du compilo
Là ou ça se complique c'est lors de la création d'un Addins de test
un coup de
fxsdk new testustl
pour créer le projet
Je renomme le "main.c" en "main.cc" pour que le compilo passe en C++ (juste au cas où, a priori pas nécessaire, mais sait on jamais)
un coup d'edition de CmakeLists.txt (je joins la version light, focalisée sur la CG50) ouù j'édite la ligne de compilation et de linkage :
target_compile_options(myaddin PRIVATE -Wall -Wextra -Os -std=c++11)
target_link_libraries(myaddin Gint::Gint -lustl -lc)
et là c'est le drame :
erreur de linkage : reference indéfinie vers "_stderr" dans la fonction ___assert_fail de la libc.
sylvain@SlyPC:~/Programmes/Casio/testustl$ fxsdk build-cg VERBOSE=1
-- The C compiler identification is GNU 11.1.0
-- The CXX compiler identification is GNU 11.1.0
-- Check for working C compiler: /home/sylvain/.local/bin/sh-elf-gcc
-- Check for working C compiler: /home/sylvain/.local/bin/sh-elf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/sylvain/.local/bin/sh-elf-g++
-- Check for working CXX compiler: /home/sylvain/.local/bin/sh-elf-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Gint: TRUE (found suitable version "2.7.0", minimum required is "2.1")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/sylvain/Programmes/Casio/testustl/build-cg
/usr/bin/cmake -S/home/sylvain/Programmes/Casio/testustl -B/home/sylvain/Programmes/Casio/testustl/build-cg --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/sylvain/Programmes/Casio/testustl/build-cg/CMakeFiles /home/sylvain/Programmes/Casio/testustl/build-cg/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make -f CMakeFiles/myaddin.dir/build.make CMakeFiles/myaddin.dir/depend
cd /home/sylvain/Programmes/Casio/testustl/build-cg && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/sylvain/Programmes/Casio/testustl /home/sylvain/Programmes/Casio/testustl /home/sylvain/Programmes/Casio/testustl/build-cg /home/sylvain/Programmes/Casio/testustl/build-cg /home/sylvain/Programmes/Casio/testustl/build-cg/CMakeFiles/myaddin.dir/DependInfo.cmake --color=
Dependee "/home/sylvain/Programmes/Casio/testustl/build-cg/CMakeFiles/myaddin.dir/DependInfo.cmake" is newer than depender "/home/sylvain/Programmes/Casio/testustl/build-cg/CMakeFiles/myaddin.dir/depend.internal".
Dependee "/home/sylvain/Programmes/Casio/testustl/build-cg/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/home/sylvain/Programmes/Casio/testustl/build-cg/CMakeFiles/myaddin.dir/depend.internal".
Scanning dependencies of target myaddin
make -f CMakeFiles/myaddin.dir/build.make CMakeFiles/myaddin.dir/build
[ 33%] Building CXX object CMakeFiles/myaddin.dir/src/main.cc.obj
/home/sylvain/.local/bin/sh-elf-g++ -DFXCG50 -DTARGET_FXCG50 -isystem /home/sylvain/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/./include/openlibm -m4-nofpu -mb -ffreestanding -nostdlib -Wa,--dsp -Wall -Wextra -Os -std=c++11 -fstrict-volatile-bitfields -o CMakeFiles/myaddin.dir/src/main.cc.obj -c /home/sylvain/Programmes/Casio/testustl/src/main.cc
[ 66%] Building FXCONV object CMakeFiles/myaddin.dir/assets-cg/example.png
fxconv /home/sylvain/Programmes/Casio/testustl/assets-cg/example.png -o CMakeFiles/myaddin.dir/assets-cg/example.png --toolchain=sh-elf --cg
[100%] Linking CXX executable myaddin
/usr/bin/cmake -E cmake_link_script CMakeFiles/myaddin.dir/link.txt --verbose=1
/home/sylvain/.local/bin/sh-elf-g++ -nostdlib -T fxcg50.ld -lgcc CMakeFiles/myaddin.dir/src/main.cc.obj CMakeFiles/myaddin.dir/assets-cg/example.png -o myaddin -lgcc -lgcc /home/sylvain/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/libgint-cg.a -lustl -lc /home/sylvain/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/libc.a /home/sylvain/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/libgint-cg.a /home/sylvain/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/libc.a -lopenlibm -lgcc
/home/sylvain/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld : /home/sylvain/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/libc.a(assert.c.obj) : dans la fonction « ___assert_fail » :
assert.c:(.text+0x1c) : référence indéfinie vers « _stderr »
collect2: erreur: ld a retourné le statut de sortie 1
make[2]: *** [CMakeFiles/myaddin.dir/build.make:98 : myaddin] Erreur 1
make[1]: *** [CMakeFiles/Makefile2:76 : CMakeFiles/myaddin.dir/all] Erreur 2
make: *** [Makefile:84 : all] Erreur 2
sylvain@SlyPC:~/Programmes/Casio/testustl$
Une idée sur la cause du problème ?
Citer : Posté le 24/02/2022 12:50 | #
Merci. Pour errno.h les valeurs habituelles sur PC interfèrent avec les codes de la fxlibc, j'ai poussé un truc compatible.
stderr est bien défini par la fxlibc, mais sur la branche dev actuellement (je pense que c'est mûr, je publierai une nouvelle version dès que j'aurai le temps). Tu as bien la version dev ?
Citer : Posté le 24/02/2022 12:55 | #
je viens de faire un
puis un
La fxlibc apparait en master et en dev, mais la branche master est en "blanc" et la dev en "gris foncé" dans la liste, je pense donc que c'est pas la version utilisée.
Citer : Posté le 24/02/2022 12:56 | #
C'est pas :dev mais @dev pour la branche ; le : c'est pour sélectionner des options particulières. Les deux spécifications sont indépendantes
Citer : Posté le 24/02/2022 12:58 | #
oups :-)
effectivement il se passe beaucoup plus de trucs
je retente
Ajouté le 24/02/2022 à 13:00 :
ca compile et ca link
voyons voir si ca marche
Citer : Posté le 24/02/2022 13:01 | #
Hey, c'est une bonne nouvelle ! Moi qui voulais porter la µSTL dans le futur on dirait que es en train de faire mon job à ma place
Citer : Posté le 24/02/2022 13:10 | #
Yep, ca marche
Un petit programme avec un vector<int> tourne bien.
Bon faut tester plus en avant, mais c'est très encourageant.
Citer : Posté le 24/02/2022 13:16 | # | Fichier joint
Capture en PJ : ( bon c'est un programme de base )
Citer : Posté le 24/02/2022 13:16 | #
Let's goo
Tu vois c'était pas si dur x3
Citer : Posté le 24/02/2022 13:23 | #
Bon il faut rendre à César ce qui appartient à César, Pavel avait fait le gros du boulot. J'ai juste rendu compatible son implémentation avec Gint.
J'ai aussi pas mal regardé ce qu'avait fait Bernard Parisse, donc en combinant les deux approches, ça donne un truc qui fonctionne (a priori).
Je vais faire quelques tests sur les containers principaux (list/vectors) et sur les string, car c'est sur cela que la STL est la plus intéressante.
Cela dit, si l'envie te prends de bosser sur la µSTL 3.0, ne te gène pas il y a eu pas mal d'ajouts, par contre là j'ai rien réussi à sortir.
Ajouté le 24/02/2022 à 13:48 :
Bon bein ça à l'air de tourner pas mal :
Visiblement Vector/List/String fonctionnent pour les fonctions de base.
Citer : Posté le 24/02/2022 13:58 | #
Ça j'aime bien ça. Pas de crash/erreur/résultat stupide, que du fonctionnel, parfait
Citer : Posté le 24/02/2022 14:04 | #
moi aussi j'aime bien quand ça fonctionne comme ça.
Par contre, à terme faudra rendre ça propre car là c'est de l'artisanat (très manuel) pour que ça marche sur ma machine, c'est tout sauf portable ...
du genre faire un dépot gitea pour que d'autres puissent l'utiliser si besoin.
Truc intéressant : l'Addins pèse seulement 95,2Ko avec <string><vector><list>.
Vraiment pas certain que la STL fasse aussi bien.
Citer : Posté le 24/02/2022 14:05 | #
La libstdc++ est certainement plus grosse oui. Après c'est dur à juger en lisant juste les sources, il y a plein de magie à l'intérieur du compilo.
Tu peux voir le fichier map pour savoir qui prend la place, gint est probablement le plus gros. Une fois que tu as enlevé les ~27 ko (IIRC) de header G3A.
Citer : Posté le 24/02/2022 14:09 | #
Tu le génère comment le fichier map il est produit en standard ou tu as une commande a ajouter à la compilation ?
Comme tu peux le voir, je suis pas là dans ma zone de confort mais au moins j'apprends plein de choses.
Citer : Posté le 24/02/2022 14:18 | #
Tu peux ajouter -Wl,-Map=map aux options de link (target_link_options(myaddin ...)) et ensuite consulter build-cg/map après avoir recompilé.
C'est un peu difficile à lire, mais ce que tu peux voir c'est qu'à côté de chaque section incluses tu as une taille. Pour donner un exemple à la con pris dans gintctl :
0x00000000003026d8 _gintctl_gint_dump
Ici la section .text de src/gint/dump.c a été incluse à l'adresse 00302604, et sa taille est 0x3ac = 940 octets. En-dessous tu as les noms des symboles (variables/fonctions) publiques de ce fichier.
Tu peux parcourir le fichier pour voir ce qui prend le plus de place ; il suffit de chercher les grosses tailles dans la liste. Pour info .text et .rodata c'est en ROM ; .data et .bss en RAM, si jamais un jour tu veux regarder plus précisément l'un ou l'autre.
Citer : Posté le 24/02/2022 14:20 | #
Ok merci, forcement je mettais l'option -Map dans target_compile_options()
ca risquait pas de fonctionner
Ajouté le 24/02/2022 à 14:26 :
ca veut pas, ca me jette :
sylvain@SlyPC:~/Programmes/Casio/testustl$ fxsdk build-cg VERBOSE=1
-- The C compiler identification is GNU 11.1.0
-- The CXX compiler identification is GNU 11.1.0
-- Check for working C compiler: /home/sylvain/.local/bin/sh-elf-gcc
-- Check for working C compiler: /home/sylvain/.local/bin/sh-elf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/sylvain/.local/bin/sh-elf-g++
-- Check for working CXX compiler: /home/sylvain/.local/bin/sh-elf-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Gint: TRUE (found suitable version "2.7.0", minimum required is "2.1")
CMake Error at CMakeLists.txt:26 (target_link_options):
target_link_options called with invalid arguments
-- Configuring incomplete, errors occurred!
See also "/home/sylvain/Programmes/Casio/testustl/build-cg/CMakeFiles/CMakeOutput.log".
See also "/home/sylvain/Programmes/Casio/testustl/build-cg/CMakeFiles/CMakeError.log".
avec ça dans le CMakeLists.txt
add_executable(myaddin ${SOURCES} ${ASSETS_${FXSDK_PLATFORM}})
target_compile_options(myaddin PRIVATE -Wall -Wextra -Os -std=c++11 -c )
target_link_options(myaddin -Wl,-Map=map)
target_link_libraries(myaddin Gint::Gint -lustl -lc)
Citer : Posté le 24/02/2022 14:28 | #
Ah oui pardon j'ai oublié de préciser qu'en deuxième argument il faut mettre soit PUBLIC, soit PRIVATE, soit INTERFACE :
PRIVATE : les flags s'appliquent à la compilation de ton addin
INTERFACE : les flags s'appliquent à la compilation des programmes utilisant ton add-in [pertinent pour les libs, ici bof]
PUBLIC : les deux
Tu peux mettre target_link_options(myaddin PRIVATE -Wl,-Map=map). Il y a aussi une introduction décente à CMake sur ce topic si tu veux te familiariser un peu sans y passer des heures.
Citer : Posté le 24/02/2022 14:32 | #
C bon, la vache, la gueule du fichier map ... y'a du monde dedans
bon va falloir chercher maintenant
Ajouté le 24/02/2022 à 14:43 :
Sauf erreur de ma part (ce qui est fort possible):
le point d'entrée de copie de la STL est 0x3081D0 (=3178960)
et ca s'étend jusqu'à 0x30a8f2 (=3188978)
soit 10018 octets soit ~9,8Ko
je trouve pas que ca fasse beaucoup (bon c'est tout de meme 10% de l'Addins).
En meme temps j'ai pas beaucoup de réferences pour comparer
Citer : Posté le 24/02/2022 14:45 | #
Si tu utilises juste deux spécialisations de vector/list et string, c'est possible oui. Vérifie que dans cet intervalle tu as bien toutes les fonctions pertinentes (tu peux passer le fichier à c++filt pour décoder les noms de symboles en prototypes de fonctions), mais sinon c'est pas délirant. µSTL est assez simple.
Citer : Posté le 24/02/2022 14:49 | #
oui ca a l'air d'etre bon, je retrouve les différents .o qui servent (memlink, sostream ...)
Ajouté le 24/02/2022 à 23:47 :
J'ai pu conduire quelques tests complémentaires et globalement j'ai pas trouvé de gros problèmes.
L'implémentation de la STL n'est pas complète mais le plus gros est implémenté dans la uSTL. Ajouter ce qui manque se fait assez facilement. Par exemple dans le std::array les méthodes front() et back() sont absentes dans la version 2.1 mais en 2 minutes j’ai pu les ajouter.
Je pense faire un inventaire de ce qui est présent (ou pas) et compléter quelques éléments faciles à coder sur la base existante si besoin.
@+
Sly
C’est pas très sexy comme sujet mais ça mérite sûrement un @RDP
Citer : Posté le 25/02/2022 14:06 | #
Ca serait en effet tres bien d'avoir une version propre de la uSTL, celle que j'utilise a ete faite a l'arrache.
Si ma memoire est bonne, j'ai eu des problemes avec reverse (et peut-etre aussi avec sort), mais peut-etre dus a des bugs dans la libfxcg que j'utilise.