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 » Bibliothèque standard pour GCC
Nemhardy Hors ligne Grand maître des Traits d'Esprit Points: 1242 Défis: 54 Message

Bibliothèque standard pour GCC

Posté le 01/06/2014 19:50

Comme vous l'avez peut-être remarqué, LePhenixNoir nous a gratifié d'un tuto accessible afin de mettre en place GCC et donc une nouvelle manière de compiler des add-ins pour nos Casios.

Afin d'ouvrir le développement au libre, une bibliothèque C standard à vu le jour et avance petit à petit.
Un dépôt git est disponible ici.
L'objectif est, au final, d'avoir une bibliothèque dont on connaisse le contenu, qui soit maintenable et qui remplisse le rôle d'une librairie C standard à l'échelle de nos calculatrices, compatible SH4 et SH3, enfin un truc bien quoi !

Le code étant écrit par des membres de PC, depuis rien, le choix de la licence est ouvert, de mon côté, comme pour LePhenixNoir, placer celui-ci dans le domaine publique paraît intéressant, reste à voir avec les autres (notamment Dark Storm pour le moment ).
Message initial
Cliquer pour enrouler
Seulement, si le support de l'architecture SuperH est relativment "natif" pour GCC, le support des librairies et des parties spécifique aux calculatrices Casio l'est beaucoup moins. Ainsi, si il est possible de récupérer les fonctions correspondants à "fxlib.h" dans un format utilisable par GCC, la librairie C standard fournie par casio dans le SDK ne semble pas aussi simple à récupérer (voire irrécupérable ? ).

Le plus simple est je pense de "réecrire" une bibliothèque standard C.
A mon avis, il pourrait aussi être intéressant d'essayer de s'affranchir de la bibliothèque "fxlib" fournie par Casio, toujours en la réecrivant (c'est à dire simplement refaire les appels de Syscalls pour la plupart des fonctions, "fxlib" étant majoritairement basée sur les Syscalls), mais en travaillant sur certains points et avoir d'emblée une compatibilité SH4 par exemple. On "enlèverait" aussi la plupart du code propriétaire de Casio (bien qu'il reste les syscalls, mais bon... ).
Ce qui concerne "fxlib" n'est que mon point de vue étant donné qu'on peut très bien conserver le fichier de Casio, j'amorce juste une réflexion à ce niveau là ;).

Quoi qu'il en soit, ce topic est là pour permettre de réfléchir sur le projet ,c'est à dire la réimplémentation d'une bibliothèque C à peu près standard (en s'appuyant sur les syscalls déjà existants, va faloir sortir la doc ) pour fonctionner sur GCC de manière correcte, voire plus intéressante que sur le SDK de Casio (pourquoi pas implémenter des fopen(...) par exemple, là encore, simple suggestion à cogiter ).
C'est aussi pour voir si il y a des gens qui seraient intéressés pour travailler là dessus, et voir vos idées sur la manière de travailler dessus.

Je pense qu'à la longue, un dépot git (ou autre) sur gitorious ou quelque chose du même style pourrait servir, qu'en dites vous ? Enfin, le projet semble intéressant, d'autant plus qu'un GCC bien fonctionnel pour compiler des add-ins, ça serait cool ! :D.
Donc n'hésitez pas à mettre vos idées pour commencer et avancer !
[/spoiler]


1, 2, 3, 4 ··· 6, 7, 8 Suivante
Dark storm Hors ligne Labélisateur Points: 11631 Défis: 176 Message

Citer : Posté le 01/06/2014 19:53 | #


J'approuve, quand on voit la vitesse des fonctions de Casio, un peu de ménage ne ferai pas de mal
Par contre, ce qui serai bien serai soit de tout faire en C très optimisé, soit un bout en C et un bout en ASM
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 01/06/2014 20:24 | #


L'ASM, on y passera -- ou plus précisément, j'y passerai quoi que vous faisiez.
Il reste un problème avec fxlib, c'est... la gestion des fichiers. Comment comptes-tu t'y prendre pour aller lire dans la mémoire de stockage ou la carte SD ?
Ceci excepté, on pourra s'en passer de bout en bout.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Nemhardy Hors ligne Grand maître des Traits d'Esprit Points: 1242 Défis: 54 Message

Citer : Posté le 01/06/2014 20:24 | #


De plus avec GCC, il est assez simple de mélanger ASM et code C, donc c'est possible, d'autant plus que le code généré par GCC est par nature plus optimisé que celui du SDK : quand pour la fonction suivante
Fonction
Cliquer pour enrouler
int test()
{
    int bob;
    bob = 9;
    bob++;
    return bob;
}

Le SDK produit :
Code produit par le SDK
Cliquer pour enrouler
MOV #9,R4
ADD #1,R4
RTS
Mov r4,r0

GCC lui produit plutôt :
Code produit par GCC
Cliquer pour enrouler
RTS    
    MOV #10,r0

Il n'y a pas tellement photo (après, c'est peut être que le code est ultra court et sans intêret, mais bon, il y a quand même un problème avec le SDK ).

C'est vrai que pour tout ce qui est manipulation de mémoire ou autre, ça peut être sympa de voir si une réecriture peut conduire à de meilleurs résultats :).

Sinon, pour commencer, je pense qu'il faudrait faire une liste des fonctions que l'on veut réimplémenter, voir un peu les syscalls qui existent et réfléchir à partir de ça.
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 01/06/2014 20:26 | #


Je savais pour l'optimisation de gcc, mais que voulez-vous c'est du libre !
Sinon j'en profite pour reposer ma question ci-dessus pour pas qu'elle passe inaperçue.
Comment gères-tu les fichiers ?
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Nemhardy Hors ligne Grand maître des Traits d'Esprit Points: 1242 Défis: 54 Message

Citer : Posté le 01/06/2014 20:33 | #


"Remplacer" fxlib était juste une idée, et peut être pas une priorité.
Ensuite, il y a l'option Kristaba ( ), qui avait bossé sur le FileSystem, et qui avait réussi à avoir quelque chose de très (enfin beaucoup plus que les syscall) rapide il me semble, on peut voir de ce côté là.
La "priorité" pour l'instant à mon avis, est peut-être plus de gérer tout ce qui est fonctions comme malloc, free, etc... (en utilisant les syscalls).
Sinon, quand je disais "implémenter un fopen", c'est plutôt comme fournir des fonctions plus simples à utiliser reposant sur les syscalls (comme "Memory" en fait), mais dont le fonctionnement ressemblerait à du standard.

Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 01/06/2014 20:39 | #


Regarde dans la dernière partie de la doc sur les sycalls.
malloc(), free(), et autres existent bien en tant que syscalls.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Nemhardy Hors ligne Grand maître des Traits d'Esprit Points: 1242 Défis: 54 Message

Citer : Posté le 03/06/2014 23:32 | #


Donc, j'ai réfléchis surtout à la manière dont on pourrait organiser ça pour que l'on puisse s'y retrouver et que ce soit à peu près propre et finalement je me suis dit qu'un truc assez découpé pourrait convenir, avec les makefile qui vont bien ;).
Du style un dossier libc puis un dossier stdlib puis un fichier malloc.s par exemple. Je pense que découper chaque fonction en un fichier .c / .s pourrait être bien, mais je ne sais pas ce que vous en pensez.
Je mettrai demain en ligne une espèce de "démo" de ce à quoi j'ai pensé au niveau de l'organisation / build-system, histoire de proposer et voir ce que vous en dites :).

Eiyeron Hors ligne Ancien modérateur Points: 5525 Défis: 57 Message

Citer : Posté le 04/06/2014 09:50 | #


Sortez-moi un GCC Casio portable pour Windows avec un emu (prenez celui du SDK au pire) qui me permet le debug step par step et je migre vers l'ASM. J'ai dés idées d'optimisations.
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 04/06/2014 09:52 | #


Hmm... un gcc sous Windows ?
Désolé, là je ne peux pas t'aider. Rien que la ligne de commande est horrible.
Pourquoi tu n'utilises pas un émulateur ou un vm ?
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Eiyeron Hors ligne Ancien modérateur Points: 5525 Défis: 57 Message

Citer : Posté le 04/06/2014 09:55 | #


Parce que il existe le PrizmSDK pour Windows, alors je vois pas pourquoi ça ne marcherait pas sur Windows. ET puis j'ai ni la place pour une VM sur mon ordi, ni la possibilité d'y installer Linux depuis que mon ordi rejette systématiquement le kernel Linux au démarrage.
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 04/06/2014 09:57 | #


Alors il faut voir comment l'installation du PrizmSDK se fait. Là, Nemhardy pourra t'aider plus que moi.
Par contre je ne comprends pas, pourquoi tu veux installer gcc sous Windows alors que tu as déjà le SDK ?
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Eiyeron Hors ligne Ancien modérateur Points: 5525 Défis: 57 Message

Citer : Posté le 04/06/2014 09:59 | #


Lephenixnoir a écrit :
Par contre je ne comprends pas, pourquoi tu veux installer gcc sous Windows alors que tu as déjà le SDK ?

Parce que GCC est mieux fichu que le SDK? Il a l'air de mieux optimiser et de mieux gérer le C que Renesas, je me souviens encore des bugs du compilo que j'ai eu avec Boxed.
Alors il faut voir comment l'installation du PrizmSDK se fait.

C'est simple, je dézippe l'archive contenant le SDK que je trouve sur Cemetech.
Kristaba Hors ligne Membre Points: 614 Défis: 22 Message

Citer : Posté le 04/06/2014 11:12 | # | Fichier joint


Je passe là en coup de vent, mais ça me fait plaisir de voir des initiatives pour que les gens utilisent un compilo un peu plus propre, et encore plus quand il s'agit de faire des bibliothèques correctes

Cependant, j'avais déjà fait du boulot de ce côté là, en transformant la lib fournie par Casio en une lib statique compatible avec GCC, je ne me souviens plus de tout ce que j'avais fait pour en arriver là (un outil de chez Renesas pour convertir les lib, entre autre, et un poil de rétro-ingénieurie), et en effet il faut faire gaffe aux conventions d'appels qui peuvent être légèrement différentes entre GCC et le vieux compilo (y'a une option dans GCC pour utiliser les anciennes conventions d'appels, mais même sans ça ça tournait bien chez moi).

J'ai pas vraiment le temps de vous donner quelque chose de propre, donc voilà en vrac les dossiers d'include et les libs correspondantes que j'utilisais dans mes projet avec GCC (libsdk85.a est l'équivalent de fxlib).
Y'a d'autres bibliothèques dans le tas : RevolutionFX de Kucalc (que j'avais porté pour GCC et un poil modifié, j'ai les sources quelque part), libstdio.a qui correspond à mon implémentation assez crade de l'accès aux fichiers en lecture sur la SMEM (mais qui est largement plus rapide que les fonctions de l'OS...), et deux libs de dessin provenant de MonochromeLib, dont l'une adaptée au dessin en niveaux de gris.

Pour finir, je vous encourage à ne pas faire trop confiance à Fxlib, vraiment mal conçue, buguée et les "syscalls" sur lesquels la bibliothèque repose sont eux-même super mal foutus de mon point de vue...
Au moins, pour l'accès aux fichiers ça vaudrait le coup de tout reprendre un jour (pour la SMEM y'a du code un peu plus propre qui traine sur le git de FiXos, quelque part ici).
N'oubliez pas non plus que la SMEM est située sur de la mémoire Flash NOR, et que c'est bien chiant à effacer/écrire (blocs de 64kio sur le modèle des G85), et qu'en plus de cela l'OS de Casio est sur la même puce (donc faites gaffe si vous jouez avec, vraiment!). J'ai écris quelques trucs très basiques, pour gérer l'EEPROM, avoir des infos constructeur, etc... (toujours sur le git), mais je le répète, faites vraiment attention à ne pas effacer les premiers blocs qui permettent le recovery via USB >_<"
Pour la carte SD, j'ai fait pas mal de travail dessus, mais c'est de la pure rétro ingénieurie sans aucune documentation existante (la fonctionnalité au niveau du processeur est protégée par un accord de non-divulgation -_-').
Il me manque un tout petit morceau pour la faire fonctionner (réception des données de lecture d'un bloc), j'ai dû raté un morceau d'initialisation quelque part...

Il était vraiment temps que je change cette signature...
Intelligide Hors ligne Membre de CreativeCalc Points: 49 Défis: 5 Message

Citer : Posté le 04/06/2014 16:05 | #


comment on installe les bibliothèques?
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 04/06/2014 17:14 | #


Avec gcc ? On linke le .a en utilisant les options -L et -l.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Nemhardy Hors ligne Grand maître des Traits d'Esprit Points: 1242 Défis: 54 Message

Citer : Posté le 04/06/2014 19:03 | #


Je vous met un lien (un peu tard, mais j'ai passé ma journée à comprendre que j'avais mal nommé un fichier xD ) qui montrerait le système tel que je l'avais imaginé [url= http://repo.or.cz/w/graphlib.git/]ici[/url]. L'interface est un peu austère, mais je voulais pas forcément le mettre sur GitHub (je me suis rendu compte que ça devenait un peu le Facebook des hébergeurs de code... là c'est purement de l'hébergement d'un dépot, il n'y a rien autour, j'avais envie de tester ) (peut être que finalement, Gitorious est mieux, (au niveau de l'interface par exemple), mais bon, en faisant un git clone, on se retrouve à voir le code en local donc c'est mieux qu'une interface web de toute façon je pense ).

En gros, il y a un makefile à la racine qui, quand appelé, "redistribue" les taches de compilation. Au final, pour l'instant, on a 4 objets qui sont archivés dans un "libc.a". Mais là encore, c'était pour voir comment ça pourrait s'organiser.
Il faudrait aussi modifier les makefile au fur et à mesure de l'ajout des fichiers source, je ne sais pas si c'est mieux que de tout récupérer automatiquement, mais peut-être a t-on plus conscience de ce que l'on compile en ajoutant à la main (concept un peu inutile je vous l'accorde).
Je regarde aussi ce qu'a fait Kristaba, mais je pense que reprendre un peu tout ça que ce soit (un peu) plus propre serait bien.

Voila, après, je ne sais pas si vous avez réfléchi de votre côté ou commencé des trucs, histoire qu'à plusieurs on fasse un truc bien !

Ah oui, aussi, le nom de GraphLib est completement arbitraire, il fallait donner un nom au dépot provisoire, j'ai mis ça, mais je ne sais pas ce qu'on décide (qui fait le dépot (si on décide qu'il y a) et où par exemple) :p.
Eiyeron Hors ligne Ancien modérateur Points: 5525 Défis: 57 Message

Citer : Posté le 04/06/2014 19:07 | #


Le facebook des codeurs... T'as bitbucket ou gitorious comme bonnes alternatives
Dark storm Hors ligne Labélisateur Points: 11631 Défis: 176 Message

Citer : Posté le 04/06/2014 19:08 | #


Pour le développement du site, on utilise Bitbucket, ça fonctionne bien et c'est moins "Facebook"
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Nemhardy Hors ligne Grand maître des Traits d'Esprit Points: 1242 Défis: 54 Message

Citer : Posté le 04/06/2014 19:09 | #


Moi a écrit :
peut être que finalement, Gitorious est mieux


Je n'ai jamais dis que c'était le mal, au contraire :p.

Ajouté le 07/06/2014 à 18:00 :
D'ailleurs ce que je "critiquais" à propos de GitHub n'est pas tellement l'aspect très social de l'hébergeur, c'est pourquoi l'emploi de Facebook comme exemple n'était pas forcément le plus adapté, j'aurai plutôt du le qualifier de "Facebook des réseaux sociaux". C'est à dire que, un peu à le manière de Google aussi pour les moteurs de recherche ou de Facebook pour les réseaux sociaux, GitHub devient petit à petit une sorte de "géant" ou d'entreprise qui monopolise l'hébergement de projets (du moins de mon point de vue), ainsi, un dépot git devient de plus en plus souvent un dépot qui finit sur GitHub... Enfin, je ne "critique" pas le service en tant que service, car il n'est pas forcément mauvais d'ailleurs, mais un peu cet aspect central du service, qu'il est bon à mon goût de contourner quand on le peut et si on le veut.

Petit aparté à part, j'ai pas trop avancé depuis, mais je vais m'y mettre dans la soirée ;).

Ajouté le 08/06/2014 à 01:17 :
Donc, finalement, j'ai recorigé le système de compilation, car il ne marchait pas top () et pour que ce soit le plus souple possible (du style si on veut ajouter un fichier, en asm ou c, il n'y a qu'à éditer un makefile, et le reste suit normalement).
J'ai aussi fait un dépot sur Gitorious qui pourrait peut-être le dépot final, il y a juste pour l'instant les malloc/free/calloc/realloc (basés sur les syscalls), ainsi que deux fonctions (en C) de manipulation de chaînes , juste à des fins de tests pour l'instant (même si le code en lui même n'a pas été testé pour l'instant ^^'). Quoi qu'il en soit, ça devrait aller plus vite maintenant que "tout est prêt".

Si il y en a qui sont intéressé pour travailler là dessus, dites moi pour avoir les droits sur le dépot :). Il vous faudra aussi de quoi compiler pour sh3 (le tutoriel de LePhenixNoir vous permettra de mettre ça en place), sous Linux c'est (beaucoup) plus simple à mettre en oeuvre. Si vous avez GCC en "version" sh3eb-elf, il vous suffit de lancer "make" à la racine, et un (petit pour l'instant) libc.a se construira dans le dossier lib (si tout va bien ).
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 08/06/2014 08:33 | #


Pas mal, je vois que tu avances bien (contrairement à moi pour le tuto ).
Je crois qu'il manque pas mal de fonctions de string aux syscalls, mais elles sont assez faciles à écrire de manière très optimisée, donc ça devrait aller.
On risque de devoir zapper qsort() et bsearch()... le reste devrait pouvoir se faire.
Par contre, on risque d'avoir du boulot au niveau de sprintf() et surtout de sscanf(), mais j'ai déjà mon idée sur comment les reprogrammer.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
1, 2, 3, 4 ··· 6, 7, 8 Suivante

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 82 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