FxLibC: La bibliothèque standard C pour les calculatrices
Posté le 22/10/2020 17:39
Salut à toi jeune développeur !
FxLibC est une bibliothèque standard C basé sur l'interface que propose GLIBC, la "vrai" bibliothèque standard.
Alors, je sais, ce n'est pas la première fois qu'une telle initiative est prise mais j'ai de bonnes raisons de le faire :
L'OS de Casio n'est pas adapté pour oser faire un portage de la Glibc original car trop de mécanismes sont manquants et la plupart des abstractions fournies par Casio sont, au mieux, bancales. C'est pourquoi j'ai décidé de refaire une librairie de 0 qui permettra de tirer toute la puissance des OS et permettra d'avoir une interface commune pour les OS Casio monochrome/couleur et des noyaux custom comme Vhex.
Pour l'instant, c'est juste un "proof of concept" où la lib peut être compilée, installée et désinstallée en fonction de l'OS et du format* mais en matière de fonctionnalité, il n'y pas grand-chose d'incroyable, seules quelques fonctions basiques y sont implémenté. Je continuerai de l'améliorer au fur et à mesure de mes expérimentations / projets qui, je l'espère, arriverons bientôt.
Pour pas oublier, voici le lien vers le dépôt Git :
> Lien vers le dépôt Gitea, Vhex-Kernel-Core/fxlibc <
Mes prévisions pour la bibliothèque :
Changement de la gestion des versions
C'est une des choses que je n'ai jamais vraiment regardées mais je vois de plus en plus d'intérêt à avoir une gestion des versions correctes si on veut avoir quelque chose de maintenable dans le temps. Actuellement, la version est obtenable uniquement avec
make version et elle est mise a la main dans le makefile. J'avais pensé a une gestion automatique des versions basées sur le git: je cherche le dernier commit avec un tag (tag qui contiendra le major.minor (ex: 2.6)) et le nombre de commit après le tag indique la version des patchs. Mais je ne sais pas s’il y a moyen plus simple et plus "automatisant"(?)
Abstraction de Bfile (l'interface mise en place par Casio pour gérer les fichiers)
Comme je vais devoir implémenter les "appels système"
open(), lseek(), close(), etc ; Je me suis dit que j'aurais tout intérêt à faire une vraie abstraction de Bfile car elle apporte trop de contrainte (par exemple, on doit spécifier la taille du fichier qu'on veut créer, il y a quelque subtilité avec l'écriture, c'est lent, ...) Donc j'hésite entre :
1) faire juste des wrappers autour des appels système Bfile: le plus simple mais on aura la plupart des contraintes imposées par le Bfile.
2) faire une plus grosse abstraction sur le Bfile: mais ça implique de "monter" le système de fichier au début du programme, potentiellement plus rapide mais on n'échappera pas aux limitations de création et d'écriture dans un fichier).
3) embarquer un système de fichiers custom en RAM et enregistré les informations uniquement quand l'addins retourne au menu : mais ça pose beaucoup de problèmes organisationnel et architectural car je trouve qu'un FS n'a pas sa place dans une bibliothèque standard. Est-ce qu'il faudrait faire un projet à part ? Si oui alors : comment on relit les deux projets ensemble sans que ce sois infernal pour les développeurs ? Sur quel type de format on part ? Comment l'installer proprement en RAM et où ? Comment et quand installer le FS ? Comment on y accède si le système est isolé de la librairie ?
Personnellement je suis plus pour la 3ᵉ options car elle permettra d'avoir un vrai abstraction sur le FS de Casio et on pourrait implémenter beaucoup plus de fonctions pour la manipulation et la sécurité des fichiers (en plus de gagner en performance(?)) mais ça pose beaucoup de problèmes. À méditer.
Abstraction de la gestion de la mémoire
Est-ce qu'on continue d'utiliser des wrappers autour des appels système pour la gestion de la mémoire (malloc, calloc, free, ...) ? Ou est-ce qu'il faudrait mieux refaire cette partie dans la lib ? Actuellement, j'utilise l'ABI de Casio et Vhex pour la gestion de la mémoire car du côté de Casio c'est flou et du côté de Vhex je n'ai pas le choix car l'entièreté de l'environnement (processus, kernel, FS, ...) est en RAM et je n'ai pas le MMU à disposition. Donc est-ce que ça vaut vraiment le coup d'implementer un tas custom, sachant qu'on aura surement rien de commun entre les différents OS ?
Écriture de la documentation
C'est une des parties cruciales si on veut avoir quelque chose d'utilisable et d'améliorable, seulement je ne sais encore sur quel médium faire la documentation : sur le wiki, faire un topic, générer une documentation HTML / PDF ? D'ailleurs, ça me fait penser, es-ce que la v5 de planet-casio améliore cette partie ? J'entends par là, est-ce qu'il y aura un moyen de synchroniser la bible, le wiki du Gitea et le topic en même temps ? Ça pourrait être extrêmement intéressant de centraliser les projets ainsi que leurs documentations / topics.
Support des librairies dynamique pour Vhex
C'est une des fonctionnalités cruciale pour Vhex car la version 2.0 repose entièrement sur le mécanisme de pouvoir relocaliser / charger des fonctions à la volée. Mais malheureusement, GCC semble ignorer les flags pour la génération des bibliothèques (pourtant on peut créer des exécutables en PIE !). Bref, j'avais envoyé
un mail à GCC pour avoir des informations mais je n'ai toujours pas eu de réponse.
Optimisation des fonctions
Hé oui, l'intérêt d'avoir une lib complètement indépendante des OS et communautaire, c'est qu'on va pouvoir optimiser la plupart des fonctions basique ! Attention toute fois, s’il vous prend l'envie de participer, évitez d'écrire du code utilisant des modules hardware pouvant générer des interruptions (comme le DMA et le SPU) a moins d'être absolument certain que le système d'exploitation est capable de les gérer. Mais n'oubliez pas que le but de la lib est d'être la plus indépendante possible vis-a-vis des OS pour faciliter son portage.
Actuellement, rien n'est optimisé et rien n'est garantie de fonctionner comme il est décrit dans la norme POSIX ou dans la documentation de la glibc mais à l'avenir, j'espère pouvoir les respecter le plus fidèlement possible.
D'ailleurs, si vous voulez participer au projet n'hésitez pas ! J'ai besoin de pas mal de retour pour que la bibliothèque puisse être un jour utilisable par d'autre personnes que moi
Citer : Posté le 14/01/2022 20:49 | #
Que dire; whoua !!!
Effectivement c'est un gros gros morceau que tu nous lâches aujourd'hui.
Je suis d'accord avec toi, mis à part scanf et cie, le reste est anecdotique.
C'est sur le canal "Dev", ça passe en "Master" quand ?
Je ferai qq tests et te dirai ce qu'il en est.
+99 pour Lephé
Le monde est dangereux à vivre ! Non pas tant à cause de ceux qui font le mal, mais à cause de ceux qui regardent et laissent faire.
-------------------------------------------------------------------
Albert Einstein
Mathématicien, Physicien, Scientifique (1879 - 1955)
Citer : Posté le 14/01/2022 21:17 | #
Merci, en effet c'est un gros morceau ! Pour être honnête j'en ai un peu marre des fichiers maintenant, j'espère que ça tiendra comme ça pendant un petit moment.
De préférence quand ce sera un peu plus testé, même si honnêtement je pourrais le publier n'importe quand.
Note : si tu testes récupère bien gint dev aussi, il y a un fix d'un crash potentiel durant les écritures que je n'ai pas encore intégré à une release.
Citer : Posté le 19/03/2022 21:36 | #
Release associée de gint : gint 2.7.1
Release associée du fxSDK : fxSDK 2.7.1
Voici une grosse nouvelle version avec principalement le support des fichiers dans <stdio.h>.
Liste des fonctions supportées
Pour rappel, il faut utiliser gint_world_switch() avant de manipuler des fichiers !
Fonctionnalités manquantes pour l'instant
En gros, il y a quasiment tout... ce qui manque est accessible ; le seul gros morceau c'est scanf().
Citer : Posté le 19/03/2022 21:46 | #
Merci Lephe,
big update. Franchement on a vraiment beaucoup de choses là.
Avec un fscanf, on sera au top
Beau boulot
Le monde est dangereux à vivre ! Non pas tant à cause de ceux qui font le mal, mais à cause de ceux qui regardent et laissent faire.
-------------------------------------------------------------------
Albert Einstein
Mathématicien, Physicien, Scientifique (1879 - 1955)
Citer : Posté le 17/05/2022 19:52 | #
Release associée de gint : gint 2.8.0
Release associée du fxSDK : fxSDK 2.8.0
Absolument rien de majeur :
Citer : Posté le 21/08/2022 22:21 | #
Release associée de gint : gint 2.9.0
Release associée du fxSDK : fxSDK 2.9.0
Cette version contient rien de très passionnant, juste quelques bugs et le support nécessaire pour compiler la bibliothèque C++ dans le fxSDK.