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 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 ?
Citer : Posté le 13/06/2014 21:29 | #
Sh3eb-elf-objcopy !
Coïncidence ? Je ne pense pas.
Citer : Posté le 13/06/2014 21:31 | #
Ah, merci.
Et je peux t'assurer que jusqu'ici, j'utilisais sh3eb-objcopy, comme j'ai vu parfois sh3eb-gcc... je change dans le tuto.
Ajouté le 14/06/2014 à 08:57 :
J'ai finalement automatisé la compilation avec un Makefile avec succès (pas tros compliqué
Toujours ce même problème de lancement sur l'émulateur. Comme voulu, j'ai essayé d'appeler la fonction initialize() de crt0.s, mais le compilateur m'a vulgairement insulté. Il a reconnu quand j'ai ramené la fonction dans mon main.c, mais rien ne s'est produit. Je vais tenter de désassembler INIT_ADDIN_APPLICATION() et de l'insérer dans mon code pour voir.
Ajouté le 14/06/2014 à 09:22 :
Bon, je reprends ce que j'avait dit plus tôt, sur les fonctions d'initialisation.
D3 03 7F FC 2F 51 65 F1 65 5D 43 2B 7F 04 00 00 00 30 0C A6
L'image est le résultat donné par le désassembleur du SDK. Déjà, on peut constater que les octets en hexadécimal ne sont pas les mêmes. Ça commence bien.
Voici le code donné par le désassembleur de Ziqumu pour la suite d'instructions du haut récupérée dans le g1a à partir du fichier map généré par le SDK :
000000 d303 mov.l @(h'c,pc), r3
000002 7ffc add #h'fc, r15
000004 2f51 mov.w r5, @r15
000006 65f1 mov.w @r15, r5
000008 655d extu.w r5, r5
00000a 432b jmp @r3
00000c 7f04
00000e 0000
000010 0030
000012 0ca6 mov.l r10, @(r0,r12)
Et enfin, voici le code donné dans crt0.s pour la compilation :
sts.l pr, @-r15
! set up TLB
mov.l Hmem_SetMMU, r3
mov.l address_one, r4 ! 0x8102000
mov.l address_two, r5 ! 0x8801E000
jsr @r3 ! _Hmem_SetMMU
mov #108, r6
! clear the BSS
mov.l bbss, r4 ! start
mov.l ebss, r5 ! end
bra L_check_bss
mov #0, r6
Il est facile de constater que celui de ctr0.s est bien celui donné par le désassembleur du SDK, mais j'aimerais comprendre pourquoi les octets en hexa n'ont pas donné le même résultat en étant passés par le désassembleur. De plus, ce code n'est pas présent dans crt0.s.
Une idée sur l'origine de la divergence entre ces codes ?
Citer : Posté le 14/06/2014 09:24 | #
D'accord, je n'aipas trop avancé de mon côté, il faut dire aussi qu'il y a pas mal d'orage chez moi depuis quelques jours et ma ligne électrique a une fâcheuse tendance à mal le supporter ^^.
Enfin, cool que tu t'y mettes aussi !
Finalement, tout le monde à l'air d'accord pour la non utilisation des syscalls pour les manipulations de chaînes, donc effectivement, moi je suis de toute manière favorable à une réécriture.
Je regarde ce que tu as mis en PJ, je suis curieux de voir à quoi ça peut ressembler une fois optimisé (jen'avais en tête qu'un truc basique). Après pour git, c'est pas une oligation que nous travaillons dessus, c'étaiit juste une idée car c'est bien pratique.
Citer : Posté le 14/06/2014 09:25 | #
Ce serait aussi une occasion pour moi de me familiariser avec ce système, car il est très utilisé et j'y aurai probablement affaire plus tard. Je pense que c'est plutôt une bonne idée, puisque c'est fait pour ça de toute manière.
Citer : Posté le 14/06/2014 09:30 | #
En la fonction initialize system sert simplement à jumper sur INIT_ADDIN_APPLICATION non ? Enfin, à la vue du code C c'est ce que je pense ^^. C'est plutôt à INIT_APPLICATION qu'il faut s'intéresser je pense. Après pour la divergence des codes, comme ça je ne saurai t'en dire plus :oops:...
Citer : Posté le 14/06/2014 09:35 | #
Oui, mais le désassembleur du SDK ne déassemble pas INIT_ADDIN_APPLICATION() (zone mémoire de ???) et si celui de Ziqumu ne donne pas le bon code, on va avoir du mal...
Je vais vérifier les valeurs hexa du g1a et celles données par le désassembleur du SDK, pour les deux fonctions.
Citer : Posté le 14/06/2014 09:44 | # |
Fichier joint
Je recommence le dump de la fonction InitializeSystem. On la connaît, on doit être sûr déjà que tout fonctionne avec.
Premier code trouvé dans le g1a :
Nouveau code trouvé dans le g1a :
Ancien code désassemblé par le SDK :
Nouveau code désassemblé par le SDK :
Cette fois, les octets correspondent. On est sur la bonne voie !
Le code est d'ailleurs identique à celui donné par le désassembleur de Ziqumu, il y avait donc une bêtise dans le premier code désassemblé par le SDK (peut-être que mon g1a et mon map n'étaient pas issus de la même compilation).
Citer : Posté le 14/06/2014 10:02 | # |
Fichier joint
Par ailleurs, le code de la fonction initialize() de crt0.s est le même que celui issu du premier désassemblage par le SDK -- et donc vraisemblement incorrect, puisqu'il est en déasaccord avec le fichier map est le désassembleur du Ziqumu.
Fonction initialize() à revoir.
Je vais donc réécrire cette fonction pour crt0.s (sous un autre nom).
De plus, la fonction saute à @r3 (432B jmp @r3), et cette valeur est celle de l'adresse hexadécimale 0x00300210, ce qui correspond pas à celle définie pour INIT_ADDIN_APPLICATION() dans FXADDINror.map. Celle-ci donne l'adresse 0x003002be.
À cette adresse, nous avons le code suivant :
Qui est désassemblé par le SDK (avec cette fois, correspondance de l'hexa) en :
Citer : Posté le 14/06/2014 10:05 | #
J'avais regardé un peu aussi, et il me semble que INIT_APPLICATION appelle aussi une autre routine (celle juste avant dans la map de l'addin). Enfin, c'était à la sortie du desassembleur de Ziqumu, donc peut être pas bon du coup.
Citer : Posté le 14/06/2014 10:07 | #
Non, je confirme que le déassembleur de Ziqumu a dit juste, c'est le premier désassemblage du SDK qui a foiré.
Mais du coup, comme la fonction initialize() de ctr0.s est faite de ce code, elle est peut-être incorrecte...
Citer : Posté le 14/06/2014 10:47 | #
Au passage, j'en profite pour dire que les fonctions de Kristaba concernant la lecture de fichiers ne sont pas du tout opérationnelles pour un usage "grand public" : il s'est basé sur la position des fichiers dans la mémoire, zone qui reste inchangée entre les G85 et G95 mais qui varie sur les G35++ et G75. Or, n'ayant que une G85 et une G95 sous la main, il n'a pu s'en rende compte.
On est en train de corriger ça, mais malheureusement fxRemote ne permet pas le backup des 4Mio de données de la mémoire et s'arrête automatiquement à 2Mio... Affaire à suivre donc.
Citer : Posté le 14/06/2014 11:17 | #
Bon, tant pis pour fxlib alors, on devra se la trimballer encore un temps. Par contre je pense qu'on pourra récupérer les fonctions intéressantes et réecrire le reste.
Ajouté le 14/06/2014 à 11:21 :
Bon, on va décortiquer la fonction InitializeSystem().
00300200 D303 mov.l @(H'00c,pc), r3 ;00300210
00300202 7FFC add #H'fffffffc, r15
00300204 2F51 mov.w r5, @r15
00300206 65F1 mov.w @r15, r5
00300208 655D extu.w r5, r5
0030020a 432B jmp @r3
0030020c 7F04 add #H'04, r15
0030020e 0000 ???
00300210 0030 ???
00300212 02BE mov.l @(r0,r11), r2
_AddIn_main:
00300214 000B rts
00300216 E001 mov #H'01, r0
Prenons tout ça point par point.
→ D'abord, on stocke l'adresse 0x00300210 dans le registre r3 en vue d'y sauter.
→ On soustrait 4 à r15, donc on monte dans la pile.
→ Ensuite on sauvegarde r5 dans la pile (2 octets).
→ Et on place l'adresse de la pile dans le registre r5.
Ici je ne comprends pas à quoi sert la commande.
→ extu.w r5, r5
→ On saute à l'adresse pointée par le registre r3, c.a.d 0x300210, donc on saute les instructions 7F04 et 0000.
→ À l'adresse 0x00300210, on ne sait pas ce qu'il se passe (peut-être une donnée ? 48).
La syntaxe de la commande suivante m'est inconnue.
mov.l @(r0,r11), r2
→ L'exécution continue sur un AddIn_main() vide, donc on a le rts
→ Puis la valeur de retour 1 dans le registre r0.
Pourriez-vous m'aider à éclaircir tout ça ?
Citer : Posté le 14/06/2014 11:23 | #
T'as RTFM ?
Celui du compilo de Renesas contenant toutes les fonctions ASM
Citer : Posté le 14/06/2014 11:49 | #
Tout ce qu'il y a dessus dans la doc de 392 pages est que c'est une opération arithmétique.
Citer : Posté le 14/06/2014 11:53 | #
mov.l @(r0,r11),r2 c'est comme si tu avais r2 = *(r0+r11).
Et extu.w c'est une "zéro extensionextension" de ton registre pour pouvoir le manipuler comme un word (là je ne suis pas sûr du tout, mais c'est décrit dans la d'oc, je vais regarder
Citer : Posté le 14/06/2014 11:55 | #
Seulement on ne fait rien de r2, et pourquoi aouter r0 (registre de retour) à r11 (qui n'a aucune valeur définie) pour ensuite aller chercher à l'adresse obtenue ?
Citer : Posté le 14/06/2014 13:42 | #
Sinon, si vous voulez, donnez moi vos identifiants gitorious si ça vous intéresse de bosser avec git.
Après, LePhenixNoir, tu peux peut être essayer d'écrire une fonction qui ne fait qu'en appeler une autre avec les arguments qu'on lui a donné et voir si le "schéma" est le même, ça peut peut-être aider à y voir plus clair (ou pas, mais bon
Citer : Posté le 14/06/2014 13:51 | #
Ça reste bizarre... je vais tenter de réimplémenter cette fonction ainsi que INIT_ADDIN_APPLICATION() avec gcc, mais je ne suis pas sûr que les adresses restent les mêmes... et on risque de devoir se retaper tous les pragma et compagnie.
M'enfin tout ça c'est secondaire, puisque ça fonctionne sur la calto.
Et peut-être aussi que le SDK refuse simplement de lancer des applications qu'il n'a pas lui-même compilé !
Citer : Posté le 14/06/2014 14:00 | #
Mouais, c'est sûr ^^. Après j'avais déjà une idée plus envisageable qu'un émulateur mais qui jouerait plus ou moins le même rôle tant que ça reste du haut-niveau pour une fois cette bibliothèque bien avancée voir finie (juste une idée et pour dans un moment de toute façon).
Bon, ben pour l'instant du coup, va falloir que je trouve une graph alors si je ne veux pas passer ma vie à coder à l'aveugle :p.
Citer : Posté le 14/06/2014 14:05 | #
Au fait, mon identifiant gitorious est "LePhenixNoir".
Sinon, je n'ai pas bien compris ce que tu cherches à faire...