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 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.
Citer : Posté le 08/06/2014 08:44 | #
Le qsort est pas très compliqué lorsque l'on sais comment ça fonctionne. Bon, de là à aller faire un truc hyper optimisé, je dis pas x)
Citer : Posté le 08/06/2014 08:49 | #
Il faut que ce soit irréprochable, un truc digne de gcc
De même, le bsearch() est simple dès qu'on sait que c'est dichotomique. Mais de même, il faut optimiser.
Au passage, je pense qu'on devrait pas mettre du tri rapide, mais plutôt du tri fusion. Le qsort est linéarithmique au mieux et quadratique au pire, alors que le mergesort est en O(n log n) tout le temps.
En revanche, je n'ai réussi à le coder qu'avec une complexité spatiale assez gênante (à la fin il faut allouer un tableau de la même taille que le premier), donc si on ne peut pas le corriger autant utiliser un algorithme linéaire.
Enfin, on verra quand on y sera.
Citer : Posté le 08/06/2014 19:09 | #
Enfin, "j'avance bien", c'est tout relatif ^^. (Hier, je n'ai fait qu'écrire et corriger des Makefile en fait
Quoi qu'il en soit, tu parlais des syscalls qui existaient par rapport aux manipulation de chaînes, c'est le genre de fonction que l'on peut se permettre assez aisément de réecrire même si elles existent déjà pour s'affranchir des syscalls, en plus des fonctions manquantes au niveau des syscalls.
En fait, au final, je pense qu'on pourra arriver à un stade où il ne restera que les malloc & cie (pas simple à réimplémenter) et des fonctions par rapport à la gestion des fichiers (encore que pour la lecture, il faut voir si on peut récupérer une partie du travail de Kristaba, et l'adapter) sous forme de syscalls, le reste "refait à la main".
Citer : Posté le 08/06/2014 19:10 | #
Mais je ne comprends pas.
Les malloc() et cie sont des syscalls.
Citer : Posté le 08/06/2014 19:13 | #
C'est ce que je dis, les seuls syscall qu'on utilisent seraient ceux des malloc & cie. Tout ce qui relève de la manipulation de chaîne / mémoire ferait mieux de ne pas se baser sur ces derniers à mon avis ;).
C'est peut-être moi qui suis un peu confus dans mes messages en fait
(Je parle beaucoup pour dire peu en fait aussi
Citer : Posté le 08/06/2014 19:16 | #
Ok, mais les syscalls prennent de la place en mémoire, alors si désassemblés ils sont optimisés je ne vois pas l'intérêt d'en rajouter en plus.
Citer : Posté le 08/06/2014 19:17 | #
Tu veux directement modifier les syscalls dans l'OS ?!
Coïncidence ? Je ne pense pas.
Citer : Posté le 08/06/2014 19:18 | #
Casio != optimisé
Citer : Posté le 08/06/2014 19:21 | #
@Drac0300 : Non, je disais juste que au lieu d'appeler les syscall memset, on pourrait réecrire la fonction memset par exemple...
Après, c'est vrai que je n'avais pas trop réfléchi à la question de la taille :-/, donc si les syscall sont optimisés, pas de raison de ne pas les garder c'est vrai :).
Citer : Posté le 08/06/2014 19:24 | #
Oui, ça j'avais compris mais je parlais de ce que proposait lePhé dans le message précédant
Coïncidence ? Je ne pense pas.
Citer : Posté le 08/06/2014 20:17 | #
Mais non.
Si les sycalls déjà présents dans l'OS sont optimisés, autant les utiliser car programmer nos propres fonctions prendrait plus de place. On pourrait aisément modifier les sycalls de l'OS, mais comme tout le monde n'en profiterait pas -- la majorité en fait -- les programmes seraient plus lents sur certaines machines, ce qui serait regrettable.
Citer : Posté le 08/06/2014 22:23 | #
Mais non.
Si les sycalls déjà présents dans l'OS sont optimisés, autant les utiliser
Casio != optimisé
Je crois que tout est dit
Coïncidence ? Je ne pense pas.
Citer : Posté le 08/06/2014 22:29 | #
J'ai compris, on les refera en Assembleur.
Citer : Posté le 08/06/2014 23:03 | #
Pour l'instant, j'ai utilisé les syscalls correspondants aux fonctions de manipulation de chaînes. J'ai aussi ajouté un début de support de "time.h" et les fonctions rand() / srand(). Rien n'est testé sur calculatrice pour l'instant (j'imagine que ça doit à peu près marcher, mais aucune certitude donc
Citer : Posté le 09/06/2014 07:19 | #
J'en sais plus.
La fonction INIT_ADDIN_APPLICATION() ne fait pas partie de fxlib. Ma solution, qui a fonctionné sur la calculatrice... est de virer tout le joyeux bazar avec leurs #pragma et leur _BR_size.
De plus, je pense que vous faites le lien entre le nom de cette variable et l'erreur (invariable, elle
"The size of B&R section should be 0x2000 bytes or less".
Ce qui signifie que gcc passe outre cette erreur, donc plus de limitations de mémoire. Faites donc attention à la RAM qui pourrait ne pas survivre au choc.
Pour rand() et srand(), je t'invite à vérifier mathématiquement que ton algo n'est périodique au pire que sur une grande longueur, car les transformations affines (souvent utilisées) ne sont pas infaillibles.
Citer : Posté le 09/06/2014 07:34 | #
En fait mon problème est le suivant : l'add-in est reconnu et apparaît dans le menu de l'émulateur, mais au moment de le lancer, ce dernier me dit quelque chose comme : " Impossible de lancer ça sur l'émulateur" ou "programme non disponible sur émulateur" (je ne me rappelle plus de l.intitulé exact, mais la même erreur que lorsque l'on veut lancer "Run-Mat" par exemple).
Ensuite pour le rand, j'ai honteusement pompé la fonction dans la doc de Sim'Lo, je ferai une série de tests dans la journée :).
Citer : Posté le 09/06/2014 07:37 | #
Je vais tester mon add-in (compilé avec gcc) sur l'émulateur, je t'en dirai des nouvelles.
Ajouté le 09/06/2014 à 07:40 :
Alors ça c'est intéressant...
Bon, transfère-le sur la calculatrice, ça devrait fonctionner.
En revanche, je pense savoir comment obtenir le code d'INIT_ADDIN_APPLICATION().
Ajouté le 09/06/2014 à 07:45 :
J'ai réussi à trouver quelque chose.
Quand on y réfléchit, cette fonction est constante, donc si on arrive à en récupérer le code on le désassemble et l'insère au début de tout programme à compiler.
Voici donc la fonction InitializeSystem() qui est appelé au milieu des #pragma.
Ajouté le 09/06/2014 à 07:48 :
J'ai aussi la fonction INIT_ADDIN_APPLICATION().
Il faudrait qu'on voie avec le désassembleur...
Heureusement que les messages sont fusionnés
Citer : Posté le 09/06/2014 07:48 | #
Ah oui, pas bête
En plus je suis plutôt curieux de voir leur action réelle :).
Citer : Posté le 09/06/2014 07:55 | # |
Fichier joint
Voilà la fonction InitializeSystem().
Citer : Posté le 13/06/2014 21:09 | # |
Fichier joint
Bon, je me mets aussi à ce projet.
Es-tu sûr néanmoins qu'il faille utiliser les syscalls pour tout ce qui est string ? Je ne suis pas sûr qu'il soient optimisés, si tu vois ce que je veux dire...
Sinon, j'ai moi-même mes propres fonctions pour ça. Comme git m'est encore totalement étranger, je joins.
D'ailleur par chance, on dirait qu'il y en a que vous n'avez pas déjà.
N'hésitez pas à me donner votre avis, je les optimise à l'octet près.
C'est aussi un bon moyen de travailler ses pointeurs.
Ajouté le 13/06/2014 à 21:25 :
Je crois que j'ai un énorme problème.
Mon terminal ne reconnaît plus la commande sh3eb-objcopy. J'ai tenté de réinstaller certains composants, mais rien n'y fait... et la commande "find * |fgrep sh3eb-objcopy" n'a rien trouvé depuis /.
Du coup, impossible de compiler quoi que ce soit... une idée ?