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 !
).
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
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.
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
{
int bob;
bob = 9;
bob++;
return bob;
}
Le SDK produit :
ADD #1,R4
RTS
Mov r4,r0
GCC lui produit plutôt :
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.
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 ?
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 (
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.
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.
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 :).
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.
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 ?
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.
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 ?
Citer : Posté le 04/06/2014 09:59 | #
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.
C'est simple, je dézippe l'archive contenant le SDK que je trouve sur Cemetech.
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...
Citer : Posté le 04/06/2014 16:05 | #
comment on installe les bibliothèques?
Citer : Posté le 04/06/2014 17:14 | #
Avec gcc ? On linke le .a en utilisant les options -L et -l.
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
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.
Citer : Posté le 04/06/2014 19:07 | #
Le facebook des codeurs...
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"
Citer : Posté le 04/06/2014 19:09 | #
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 (
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
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.