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]


Précédente 1, 2, 3, 4, 5, 6, 7, 8 Suivante
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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 ?
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Drac0300 Hors ligne Membre Points: 839 Défis: 39 Message

Citer : Posté le 13/06/2014 21:29 | #


Sh3eb-elf-objcopy ! (d'ailleurs,il paraît que tu as aussi fait l'erreur dans ton tuto !)
Dans Z/1Z, 42==666
Coïncidence ? Je ne pense pas.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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.

_InitializeSystem:
D3 03 7F FC 2F 51 65 F1 65 5D 43 2B 7F 04 00 00 00 30 0C A6


[/quote]
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 :

_InitializeSystem:
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 :

_InitializeSystem:
        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 ?
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 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.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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.
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 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:...
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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 :
D3 03 7F FC 2F 51 65 F1 65 5D 43 2B 7F 04 00 00 00 30 0C A6

Nouveau code trouvé dans le g1a :
D3 03 7F FC 2F 51 65 F1 65 5D 43 2B 7F 04 00 00 00 30 [red]02 BE[/red]
Deux octets changent.


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).

Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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 :
60 53 4F 22 7F F8 2F 42 BF D6 81 F2 E6 01 D2 15 65 63 42 0B E4 00 D4 14 D3 15 43 0B 00 09 85 F2 65 03 64 F2 65 5D D3 12 7F 08 43 2B 4F 26 08 10 00 04 00 30 03 34 00 30 03 44 00 30 03 74 00 30 03 54 88 01 E0 00 08 10 20 00 00 30 03 94 00 30 03 A4 00 30 03 A8 00 30 03 B0 00 30 03 AC 00 30 03 B4 08 10 00 00 00 30 03 84 00 30 02 22 00 30 03 64 00 30 02 14

Qui est désassemblé par le SDK (avec cette fois, correspondance de l'hexa) en :

L'image
Cliquer pour enrouler

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 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.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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...
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Dark storm Hors ligne Labélisateur Points: 11631 Défis: 176 Message

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.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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().

_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 ?
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Dark storm Hors ligne Labélisateur Points: 11631 Défis: 176 Message

Citer : Posté le 14/06/2014 11:23 | #


T'as RTFM ?
Celui du compilo de Renesas contenant toutes les fonctions ASM
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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.
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 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 ).
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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 ?
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 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 ).
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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é !
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 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.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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...
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Précédente 1, 2, 3, 4, 5, 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 97 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