Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » FxLibC: La bibliothèque standard C pour les calculatrices
Yatis En ligne Membre Points: 580 Défis: 0 Message

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


Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 31/12/2021 10:45 | #


Nouvelle version : fxlibc 1.3.0

Release associée de gint : gint 2.7.0
Release associée du fxSDK : fxSDK 2.7.0

Cette release ajoute les fonctions du <time.h> C99, ainsi que les en-têtes <unistd.h>, <fcntl.h>, <dirent.h> et <sys/stat.h>. Pour ces derniers la fxlibc ne donne pas de code, c'est gint/vhex qui le fournit (gint 2.7.0 notamment).
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 06/01/2022 09:46 | #


Un petit mois et demi après la demande initiale de KikooDX d'avoir des fichiers standards (et d'autres suggestions autour du même moment), la fxlibc a maintenant une définition de FILE suffisante pour supporter le C99 et je suis en train d'écrire et tester les fonctions.

Pour ne mentir à personne c'est assez (très) chiant à faire, mais l'I/O à buffers est quand même sacrément utile.

Pour information, pour l'instant l'état de <stdio.h> est le suivant. S'il y a un tiret ("-") c'est que c'est fini, TEST c'est a priori fini et en cours de test, LDEPS il manque des sous-fonctions, et TODO il n'y a rien.

7.19 <stdio.h>
     7.19.1    Introduction                  TEST (no wide-oriented streams *)

     7.19.4.1  remove                        TEST
     7.19.4.2  rename                        TODO
     7.19.4.3  tmpfile                       TODO
     7.19.4.4  tmpnam                        TODO

     7.19.5.1  fclose                        TEST
     7.19.5.2  fflush                        TEST
     7.19.5.3  fopen                         TEST
     (EXT)     fdopen                        TEST
     7.19.5.4  freopen                       TEST
     7.19.5.5  setbuf                        TEST
     7.19.5.6  setvbuf                       TEST

     7.19.6.1  fprintf                       LDEPS(fwrite)
     7.19.6.2  fscanf                        TODO
     7.19.6.3  printf                        LDEPS(fwrite, stdout)
     7.19.6.4  scanf                         TODO
     7.19.6.5  snprintf                      -
     7.19.6.6  sprintf                       -
     7.19.6.7  sscanf                        TODO
     7.19.6.8  vfprintf                      LDEPS(fwrite)
     7.19.6.9  vfscanf                       TODO
     7.19.6.10 vprintf                       LDEPS(fwrite, stdout)
     7.19.6.11 vscanf                        TODO
     7.19.6.12 vsnprintf                     -
     7.19.6.13 vsprintf                      -
     7.19.6.14 vsscanf                       TODO
     (EXT)     asprintf                      -
     (EXT)     vasprintf                     -
     (EXT)     dprintf                       TEST
     (EXT)     vdprintf                      TEST

     7.19.7.1  fgetc                         TODO
     7.19.7.2  fgets                         TODO
     7.19.7.3  fputc                         TODO
     7.19.7.4  fputs                         TODO
     7.19.7.5  getc                          LDEPS(fgetc)
     7.19.7.6  getchar                       LDEPS(fgetc)
     7.19.7.7  gets                          LDEPS(fgets)
     7.19.7.8  putc                          LDPES(fputc)
     7.19.7.9  putchar                       LDEPS(fputc)
     7.19.7.10 puts                          LDEPS(fputs)
     7.19.7.11 ungetc                        TODO

     7.19.8.1  fread                         TEST
     7.19.8.2  fwrite                        TEST

     7.19.9.1  fgetpos                       TEST
     7.19.9.2  fseek                         TEST
     7.19.9.3  fsetpos                       TEST
     7.19.9.4  ftell                         TEST
     7.19.9.5  rewind                        TEST

     7.19.10.1 clearerr                      -
     7.19.10.2 feof                          -
     7.19.10.3 ferror                        -
     7.19.10.4 perror                        TODO

J'ai déjà des tests qui marchent pour fopen() et similaires, pour tout ce qui est gestion du buffer + fflush(), et pour fread(). Je sens venir la fin doucement, ce qui donnera clairement lieu à une nouvelle release.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt En ligne Maître du Puzzle Points: 2276 Défis: 17 Message

Citer : Posté le 06/01/2022 10:36 | #


Alors là Lephé, chapeau bas .

Pour être honnête, je voyais juste la partie émergée de l'iceberg.
J'avais pas conscience de tout ce que cela impliquait en terme de fonctions sous-jacentes.
Ca progresse vraiment bien, ca fait rudement plaisir. Et bravo à toi pour ce super boulot !!
Donc si je lis entre les lignes, stdio.h aura une implémentation complète (car ce qui est absent actuellement est en TODO).

Juste une petite question : à quoi correspondent les numéros en début de ligne (genre 7.19.6.4 pour scanf ) ? idem pour (EXT) devant fdopen ?

Ciao

Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 06/01/2022 10:38 | #


Merci. Actuellement il n'y a que la famille de scanf() qui n'est pas à l'ordre du jour ; le TODO sous-entend "plus tard".

Juste une petite question : à quoi correspondent les numéros en début de ligne (genre 7.19.6.4 pour scanf ) ? idem pour (EXT) devant fdopen ?

C'est les références aux numéros de sections/paragraphes du standard C99 (ISO/IEC 9899:1999). Pour EXT c'est des extensions hors du standard, souvent POSIX.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt En ligne Maître du Puzzle Points: 2276 Défis: 17 Message

Citer : Posté le 06/01/2022 10:47 | #


Ok merci Lephe, je vais me coucher moins bête ce soir (je t'avoue que ce n'est pas le genre de literature que je lis, le standard C99 ).
C'est une sacrée avancée pour le SDK en tout cas.

Vous avez une roadmap concernant le développement de gint/fxsdk ? par exemple les attendus pour la 2.8.0 puis la 2.9.0 ...
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 06/01/2022 10:48 | #


Pas de roadmap, je fais un peu au besoin ; mais les grandes lignes sont dans ce fichier TODO. Comme tu peux le voir, y'a plus tant de choses que ça dans "Future directions".
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt En ligne Maître du Puzzle Points: 2276 Défis: 17 Message

Citer : Posté le 06/01/2022 11:01 | #


Oui, peut être pas en nombre de lignes, certes, mais par contre ce sont de belles additions.

J'avoue que j'ai pas trop suivi l'avancement de B. Parisse pendant les congés, mais un unlock de la barre des 2Mo en "standard" pourrait être un truc cool aussi.

Puis le support de la STL full pour le C++.

Quoi ?!? Ca se voit que je fais ma liste de courses
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 06/01/2022 11:06 | #


Ha ha, tu as bien raison : en général il faut me bouger un peu pour que je lance les parties un peu compliquées, et le fs en standard t'as joué une bonne partie notamment avec l'argument de la compatibilité Nspire.

Note au passage : je viens de voir que BFile_Read() sur Graph 35+E II / Graph 90+E ne s'arrête pas à EOF (il s'arrête probablement qu'à la fin du secteur de 4096 octets) ce qui veut dire que je vais avoir besoin de la position courante sur tous les modèles. Je vais devoir la suivre à la main du coup (ce que je fais dans <stdio.h>, c'est pas dramatique, ça fera juste des bugs plus subtils en cas d'erreur de lecture/écriture).

J'avoue que j'ai pas trop suivi l'avancement de B. Parisse pendant les congés, mais un unlock de la barre des 2Mo en "standard" pourrait être un truc cool aussi.

Alors ça, c'est pas gagné. Je juge le procédé expérimental, et encore KhiCAS ne l'implémente pas pour l'instant. Pour être honnête je ne vois pas trop comment tu pourrais atteindre 2 Mo sauf à porter des gros logiciels comme KhiCAS.

Puis le support de la STL full pour le C++.

Oui uSTL est sur la liste de courses. Initialement je voulais utiliser la libstdc++-v3 qui est fournie avec g++, mais plus j'y pense plus je crois que c'est plus lourd et plus compliqué à supporter, donc moins ça paraît intéressant. En plus le processus pour la compiler implique de revenir dans le dossier de build de GCC après avoir installé la fxlibc, ce qui est casse-pieds avec le processus actuel d'installation.

Avec tout ça en place je pense que je serai assez proche, peut-être plus loin par endroits, que le niveau de compatibilité standard du PrizmSDK, ce qui est un des facteurs encore limitants pour gint.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt En ligne Maître du Puzzle Points: 2276 Défis: 17 Message

Citer : Posté le 06/01/2022 11:23 | #


Lephenixnoir a écrit :
Ha ha, tu as bien raison : en général il faut me bouger un peu pour que je lance les parties un peu compliquées, et le fs en standard t'as joué une bonne partie notamment avec l'argument de la compatibilité Nspire.


C'est clair que lorsque le standard est supporté, c'est hyper simple de faire des portages, tu as juste à faire quelques interfaces pour supporter localement le matériel différent.

Alors ça, c'est pas gagné. Je juge le procédé expérimental, et encore KhiCAS ne l'implémente pas pour l'instant. Pour être honnête je ne vois pas trop comment tu pourrais atteindre 2 Mo sauf à porter des gros logiciels comme KhiCAS.


Avec l'implémentation du système de fichiers plus souple c'est en effet moins utile car il sera beaucoup plus aisé de "splitter" code et ressources.
Le problème que je voyais étais actuellement l'incorporation des ressources, par exemples les images dans le code de l'Add-Ins. On a vite fait d'avoir des exécutables balaises. Note : il y a aussi la taille du heap/stack à prendre en compte car on pourra pas tout faire en allocations dynamiques donc très certainement un compromis à trouver entre ressources "externes" et "internes" au code.

Oui uSTL est sur la liste de courses. Initialement je voulais utiliser la libstdc++-v3 qui est fournie avec g++, mais plus j'y pense plus je crois que c'est plus lourd et plus compliqué à supporter, donc moins ça paraît intéressant. En plus le processus pour la compiler implique de revenir dans le dossier de build de GCC après avoir installé la fxlibc, ce qui est casse-pieds avec le processus actuel d'installation.


Franchement, la uSTL me paraît bien suffisante, car l'intérêt principale de la STL, c'est la gestion des containers (vectors/lists/maps/...) et des strings. La uSTL en donne une implémentation sans avoir une lib hyper lourde. Faudrait regarder dans le détail ce qui n'est pas couvert par la uSTL, mais ca doit être des trucs relativement marginaux que peu de monde utilise, donc autant ne pas s'embêter avec ça.
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 06/01/2022 13:06 | #


Avec l'implémentation du système de fichiers plus souple c'est en effet moins utile car il sera beaucoup plus aisé de "splitter" code et ressources.
Le problème que je voyais étais actuellement l'incorporation des ressources, par exemples les images dans le code de l'Add-Ins. On a vite fait d'avoir des exécutables balaises. Note : il y a aussi la taille du heap/stack à prendre en compte car on pourra pas tout faire en allocations dynamiques donc très certainement un compromis à trouver entre ressources "externes" et "internes" au code.

Note quand même deux choses. D'une part le système de fichiers reste, de loin, la plus grande faiblesse de la Graph 35+E II et de la Graph 90+E. Si tu en brickes une des deux à divers degrés, tu peux être sûr que c'est le système de fichiers ; 9 fois sur 10 ce sera ça.

Donc même si l'API est raisonnable, je ne conseillerai pas d'implémenter des accès complexes aux fichiers, d'ouvrir plusieurs fichiers en même temps, ou d'en créer de très grandes quantités. Mon soupçon sur les bricks c'est que des erreurs (mémoire pleine, FAT pleine, ou que sais-je) passent inaperçues et que les appels suivants cassent tout. Plus on pousse plus on risque d'en rencontrer, et la surcouche d'API n'aidera probablement pas à les attraper de façon transparente.

Charger des ressources n'est pas un accès complexe, mais je préfère prévenir.

Pour ce qui est des ressources à proprement parler, tu t'exposes à des réductions de perf si tu les charges depuis des fichiers, non seulement parce que le fs est vachement lent, mais aussi à cause de la pression ajoutée sur le cache de données (qui contient déjà la pile). Dans la mesure du possible tu y gagnerais probablement à avoir une version compressée dans l'add-in et ensuite décompresser dans la RAM sans implique le fs.

Franchement, la uSTL me paraît bien suffisante, car l'intérêt principale de la STL, c'est la gestion des containers (vectors/lists/maps/...) et des strings. La uSTL en donne une implémentation sans avoir une lib hyper lourde. Faudrait regarder dans le détail ce qui n'est pas couvert par la uSTL, mais ca doit être des trucs relativement marginaux que peu de monde utilise, donc autant ne pas s'embêter avec ça.

Ce serait déjà pas mal ouais, et ça m'empêchera pas de revenir vers libstdc++-v3 un jour si quelqu'un veut porter des programmes C++ qui ne passent pas avec uSTL.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt En ligne Maître du Puzzle Points: 2276 Défis: 17 Message

Citer : Posté le 06/01/2022 13:35 | #


Lephenixnoir a écrit :

Note quand même deux choses. D'une part le système de fichiers reste, de loin, la plus grande faiblesse de la Graph 35+E II et de la Graph 90+E. Si tu en brickes une des deux à divers degrés, tu peux être sûr que c'est le système de fichiers ; 9 fois sur 10 ce sera ça.
Donc même si l'API est raisonnable, je ne conseillerai pas d'implémenter des accès complexes aux fichiers, d'ouvrir plusieurs fichiers en même temps, ou d'en créer de très grandes quantités. Mon soupçon sur les bricks c'est que des erreurs (mémoire pleine, FAT pleine, ou que sais-je) passent inaperçues et que les appels suivants cassent tout. Plus on pousse plus on risque d'en rencontrer, et la surcouche d'API n'aidera probablement pas à les attraper de façon transparente.


Effectivement, il vaut mieux ne pas trop jouer avec le feu si les fondations sont fragiles. Je suis d'accord, plus tu t'approcheras de la limite, plus tu as de risque de passer du mauvais coté et de tout planter. Et un brick n'est jamais sympa.

Charger des ressources n'est pas un accès complexe, mais je préfère prévenir.
Pour ce qui est des ressources à proprement parler, tu t'exposes à des réductions de perf si tu les charges depuis des fichiers, non seulement parce que le fs est vachement lent, mais aussi à cause de la pression ajoutée sur le cache de données (qui contient déjà la pile). Dans la mesure du possible tu y gagnerais probablement à avoir une version compressée dans l'add-in et ensuite décompresser dans la RAM sans implique le fs.


Oui effectivement ça c'est un point très intéressant que je n'ai jamais vraiment exploré. Je me souviens de ma jeunesse et de la "demo scene" qui faisait des prouesses techniques. Quand on voyait ce que les mecs faisaient tenir dans 64Ko ou même 4Ko, c'était vraiment dément ... Tout y passait : génération procédurale, compression de données, gestion de palettes, superposition de textures pour en obtenir de nouvelles, ... D'ailleurs un article sur ce genre de techniques pourrait être vraiment cool, car ce sont des points que les gens ne maitrisent pas/plus trop, vu l'abondance de RAM/espace disk qui est devenue un peu la norme désormais. Mais pour de l'embedded comme les caltos, c'est génial à développer et c'est en plus hyper chiadé techniquement.

Ce serait déjà pas mal ouais, et ça m'empêchera pas de revenir vers libstdc++-v3 un jour si quelqu'un veut porter des programmes C++ qui ne passent pas avec uSTL.


Oui sachant que pour le programmeur, si tous les appels sont propres via un std::vector ou std::string (ou autre ...) ce sera complètement transparent, il n'y aura rien à réécrire. Bernard Parisse a déjà bossé sur la uSTL, si ça se trouve, il n'y a peut être plus rien à faire, tout est peut être déjà en place.
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 06/01/2022 13:43 | #


Oui effectivement ça c'est un point très intéressant que je n'ai jamais vraiment exploré. Je me souviens de ma jeunesse et de la "demo scene" qui faisait des prouesses techniques. Quand on voyait ce que les mecs faisaient tenir dans 64Ko ou même 4Ko, c'était vraiment dément ... Tout y passait : génération procédurale, compression de données, gestion de palettes, superposition de textures pour en obtenir de nouvelles, ... D'ailleurs un article sur ce genre de techniques pourrait être vraiment cool, car ce sont des points que les gens ne maitrisent pas/plus trop, vu l'abondance de RAM/espace disk qui est devenue un peu la norme désormais. Mais pour de l'embedded comme les caltos, c'est génial à développer et c'est en plus hyper chiadé techniquement.

Oui c'est un domaine que je connais mal mais qui est, assurément, hyper stylé.

Pour être honnête gint n'est pas très bon pour ça, vu que tu te balades le kernel... ! Les add-ins même les petits font généralement dans les 70 kio - 80 kio une fois tout le de code utile de gint ajouté. Pour ma défense il y a déjà 27 kio pour l'en-tête g3a avec les deux icônes 16-bits massives !

Mais ça pourrait être marrant de faire une petite compétition comme ça, en partant d'un add-in commun à tout le monde et en retirant le poids "initial".

Oui sachant que pour le programmeur, si tous les appels sont propres via un std::vector ou std::string (ou autre ...) ce sera complètement transparent, il n'y aura rien à réécrire. Bernard Parisse a déjà bossé sur la uSTL, si ça se trouve, il n'y a peut être plus rien à faire, tout est peut être déjà en place.

Bernard Parisse est du côté PrizmSDK donc c'est pas tout à fait le même système, mais oui ça devrait être tout à fait abordable. C'est probablement plus une question d'investissement/temps que de technique.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt En ligne Maître du Puzzle Points: 2276 Défis: 17 Message

Citer : Posté le 06/01/2022 13:51 | #


Ah oui ca pourrait être vraiment cool comme concours un peu comme la 1kBasicJam, mais en C avec gint.
Effectivement on peut soustraire le poids d'un Add-ins de base.
Et si certains font mieux en gagnant sur la base, et bien tant mieux pour eux, ils sont avantagés
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 10/01/2022 18:06 | #


Les versions basiques de fread() et fwrite() fonctionnent (ie. quand on mélange pas les deux), ce qui est un un très bon signe... c'est assez rapide aussi en comparaison avec l'API Unix directe puisqu'il y a un buffer en RAM qui permet de faire moins de lectures/écritures (c'est un peu le but de cette API).
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt En ligne Maître du Puzzle Points: 2276 Défis: 17 Message

Citer : Posté le 10/01/2022 18:27 | #


Cool.
Par contre tu entends quoi par "basique" ?
L'API gint "file" (je sais pas comment l'appeler, correspondant à <stdio.h>) permettra t elle d'avoir plusieurs FILE* à un instant "t" ?
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 10/01/2022 18:33 | #


Basique c'est le fait que pour l'instant pour fread() je n'ai fait qu'ouvrir le fichier et lire (avec des fseek() interposés quand même), et pour fwrite() pareil dans l'autre sens. Je teste la logique du buffering. J'ai pas encore testé les flux en update (eg. r+) et pas testé le line buffering notamment.

Oui l'API permettra d'avoir plusieurs fichiers ouverts en même temps (un FILE n'est qu'un wrapper autour d'un descripteur de fichiers), mais du point de vue de BFile en-dessous il est impossible d'ouvrir le même fichier deux fois, et je recommande toujours d'éviter les gourouteries quand c'est possible. Si ce n'est pas nécessaire un seul fichier à la fois sera mieux.

Cela dit il n'y aura aucun inconvénient à avoir un FILE ouvert sur un fichier BFile, un sur le port USB, et un vers la RAM ou que sais-je.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt En ligne Maître du Puzzle Points: 2276 Défis: 17 Message

Citer : Posté le 10/01/2022 18:42 | #


Le cas auquel je pensais est un FILE sur un fichier à lire et un FILE sur un fichier à écrire.
On lit dans le premier fichier, on fait les traitements nécessaires "à la volée" et on rebalance direct dans le fichier en écriture.
Cela dit, on peut tout lire, temporiser en RAM et tout écrire quand le fichier à lire est fermé. afin de n'avoir qu'un FILE à la fois.

Comment ca tu veux pas ouvrir le même fichier 2 fois en paralèle, une fois en lecture seule et une fois en écriture seule en même temps. Tu es pas joueur


There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 10/01/2022 19:01 | #


Slyvtt a écrit :
Le cas auquel je pensais est un FILE sur un fichier à lire et un FILE sur un fichier à écrire.
On lit dans le premier fichier, on fait les traitements nécessaires "à la volée" et on rebalance direct dans le fichier en écriture.
Cela dit, on peut tout lire, temporiser en RAM et tout écrire quand le fichier à lire est fermé. afin de n'avoir qu'un FILE à la fois.

Tu peux le faire je suppose ; en théorie ça doit marcher. Mais si tu peux charger la totalité du premier fichier avant de générer l'autre c'est plus safe je suppose. (Bon ça relève un peu de la paranoïa mais de toute façon quand c'est moi qui donne les conseils on a ce qu'on a...)

Comment ca tu veux pas ouvrir le même fichier 2 fois en paralèle, une fois en lecture seule et une fois en écriture seule en même temps. Tu es pas joueur

Ah non ça c'est impossible avec Fugue, je parle des modes lectures/écriture genre r+.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 11/01/2022 21:32 | #


Les accès en lecture/écriture r+, w+ fonctionnent, et ungetc() fonctionne aussi. (Faut un modèle un peu solide pour celle-là !)

L'implémentation de ungetc() est sérieuse. Dans les situations favorables c'est en temps constant (juste repousser le caractère dans le buffer). S'il y a des données déjà lues depuis le descripteur, elles sont conservées dans le buffer sauf si le buffer est plein. Dans le cas où des données sont sacrifiées/déplacées dans le buffer, le maximum de place est fait pour que les appels suivants soient rapides. On peut faire autant de ungetc() que la taille du buffer, même si plus d'un à la suite c'est pas portable. Si le flux est sans buffer (_IONBF), alors je colle temporairement un buffer.

En bref, c'est clean. Avec des buffers un peu gros (eg. 4 kio) on devrait alléger assez largement le coût de Bfile dans son ensemble. (... ou alors un jour quand j'aurai codé les fichiers en RAM on fera tout en RAM et pouf).

Voilà voilà, le support des fichiers dans <stdio.h> entre dans sa phase finale™
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 14/01/2022 18:58 | #


Le support des fichiers est maintenant fini... ou en tous cas pour l'instant ; il n'y a pas toutes les fonctions, mais pas loin, et il est temps que je passe à autre chose. Voici donc le résumé de ce qui sera dans la prochaine release !

La fxlibc supporte maintenant la majorité de <stdio.h>, y compris les accès aux fichiers (dans gint, il faut juste penser à faire un world switch) :

  • Les flux standards stdin, stdout et stderr sont supportés, c'est-à-dire qu'on peut maintenant faire printf() dessus. Dans gint, par défaut le texte part dans le vide ; mais on peut spécifier des fonctions à appeler au cas où des données sont demandées via stdin ou reçues sur stdout/stderr, et l'add-in peut alors afficher ou logger le texte où ça l'arrange. J'en reparlerai côté gint.
  • On peut ouvrir des fichiers avec fopen() ou freopen() (mémoire de stockage), ou des descripteurs de fichiers directement avec fdopen() ; cette dernière est très utile pour utiliser les fonctions de <stdio.h> sur des "pseudo-fichiers" (genre le port USB dans le futur). Bien sûr fclose() aussi.
  • Contrôle du buffer avec setbuf(), setvbuf() et fflush(). Le standard autorise uniquement à changer de buffer immédiatement après l'ouverture, mais dans cette implémentation on peut changer de buffer quand on veut.
  • Les fonctions d'I/O de base fread() et fwrite().
  • Les fonctions d'I/O par caractères fgetc(), getc(), getchar(), fputc(), putc(), putchar().
  • Les fonctions d'I/O par chaînes de caractères fgets(), fputs() et puts(), plus l'obsolète et dangereuse gets().
  • La fonction pour "annuler" la lecture d'un caractère, ungetc(). C'est utile dans les lexers. Le standard ne garantit que l'annulation d'un caractère lu, mais cette implémentation garantit autant que la taille du buffer (quand il y en a un).
  • Les préférées de toute le monde : printf(), vprintf(), fprintf(), vfprintf(), mais aussi les version pour écrire directement dans un descripteur de fichiers, dprintf() et vdprintf().
  • Les outils de positionnement fgetpos(), fsetpos(), fseek(), rewind() et ftell().
  • La gestion des erreurs avec clearerr(), feof(), ferror() et perror().
  • La fonction de suppression de fichiers ou de dossiers vides, remove().

Les fonctionnalités manquantes pour l'instant sont les suivantes :

  • Il n'y a pas de flux "wide" avec les encodages exotiques. La lib ne les supporte pas du tout actuellement, et c'est pas sur la roadmap.
  • Les fonctions rename(), tmpfile() et tmpnam() ne sont pour l'instant pas disponibles. C'est pas une grosse affaire, à part pour rename() pour laquelle on n'a pas d'autre choix que de faire une copie, ce qui est un peu con d'ailleurs.
  • fflush(NULL) n'est pas supporté parce qu'on ne traque pas les fichiers ouverts.
  • Les fichiers ne sont pas automatiquement fermés à la fin de l'add-in, pour la même raison.
  • Les fonctions scanf(), vscanf(), fscanf() et vfscanf() ; l'algorithme de scanf n'est pas encore implémenté.

En gros, il y a quasiment tout... ce qui manque est accessible ; le seul gros morceau c'est scanf().

Tout ça arrivera avec la prochaine release... cela dit, s'il y a des gens intéressés pour tester un peu, ce serait pas de refus. J'ai très confiance en la stabilité de ce support parce que j'ai debuggé pas mal de choses, mais ça ne tue pas d'être prudent.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt En ligne Maître du Puzzle Points: 2276 Défis: 17 Message

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é
There are only 10 types of people in the world: Those who understand binary, and those who don't ...

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 108 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd