Posté le 04/05/2018 17:43
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 136 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
Citer : Posté le 04/05/2018 17:52 | #
Ce tutoriel pourrait t'être utile : https://www.planet-casio.com/Fr/forums/topic12970-1-Compiler-sous-Linux-avec-un-cross-compilateur-gcc.html
Il faudrait voir si xcode génère du code pour sh3, sinon il pourra pas tourner sur la calto.
Sinon, ben une VM, ou tout simplement un dual boot mac/linux (apparemment c'est possible).
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 04/05/2018 17:55 | #
Ma calto n'est pas compatible SH3 il lui faut du SH4
Pour la VM c'est toujours possible en effet. De plus je crois que les Linux sont en "free download"
Citer : Posté le 04/05/2018 17:57 | #
Quand Zezombye disait SH3, il entendait SuperH en général, le tutoriel linké ci-dessus couvre les deux (SH3 et 4). C'est écrit sh3 partout, mais c'est normal et pas gênant.
Et oui, les distributions Linux sont gratuites, pour la plupart.
Citer : Posté le 04/05/2018 18:06 | #
Ok merci, mais x-code c'est juste un IDE comme Code::Block ou Visual Basic proInterface... ça me donne juste un fichier.c et c'est tout
Citer : Posté le 04/05/2018 18:32 | #
Xcode est vraiment bien fait pour gérer des projets d’app pour Mac ou iPhone. Pour éditer des fichiers C j’ai pas trouvé ça génial.
Je suis aussi sur Mac et je fonctionne avec parallel desktop, le top pour faire tourner Windows sur Mac selon moi.
Donc j’ai le SDK d’ouvert sur un bureau (VM Windows) et SublimText2 (Mac) sur un autre pour coder.
Il suffit que SumblimText travaille sur les mêmes fichiers que ceux du sdk et ça marche nickel.
Citer : Posté le 04/05/2018 19:22 | #
Heureusement les ingénieurs sont des gens sérieux, ils ont inventé la rétrocompatibilité. Tu n'as pas de souci à te faire avec les programmes SH3 !
Pour répondre un peu plus précisément à ta question :
Pour avoir une bonne compréhension du processus il faut se défaire de l'idée qu'on « met » un fichier dans un format. C'est une erreur commune qui arrive quand on passe trop de temps à convertir des fichiers entre des formats équivalents.
Passer d'une image png à une image gif ? Passer d'une vidéo dans un conteneur avi à une autre encodée en mp4 ? Convertir un fichier de musique du format mp3 au format ogg ? À quelques subtilités près ça revient juste à changer de format, c'est-à-dire changer la façon dont l'information est encodée. Mais ça ne change ou très peu pas l'information en elle-même.
Le processus qui permet d'obtenir un add-in binaire au format g1a en partant de sources C n'est pas de ce type-là. Il y a plusieurs étapes qui modifient complètement l'information en plus de la changer de format. On transforme des programmes et on ajoute ou retire de l'information. Si on appelle couramment ce processus compilation ça signifie que ce n'est pas une conversion. On ne peut donc pas « mettre » un fichier c en g1a, par contre on peut le compiler.
Donc, pour revenir au sujet.
1. On compile le fichier source en code objet (binaire).
2. Si on a plusieurs fichiers sources, on le fait pour tous.
3. On lie les fichiers objets ensemble pour obtenir un exécutable, souvent au format ELF.
4. On se débarrasse des infos ELF pour obtenir un binaire pur.
5. On fait passer un wrapper pour ajouter l'en-tête g1a.
Il y a plein de formats et plein d'informations très différentes dans ce paquet. On part d'un fichier texte qui contient du code C ; à la première étape, on obtient un fichier binaire qui contient de l'assembleur et des données au format ELF. Le programme assembleur fait la même chose que le programme C, mais on ne peut pas pour autant parler de conversion. Après l'édition des liens, on a un autre ELF mais d'un genre différent. Ensuite on se retrouve avec un binaire pur et plein d'informations ont été supprimées ; enfin on en remet dans l'en-tête g1a, avec l'icône de l'add-in par exemple.
J'en fait peut-être un paquet mais je voudrais que l'existence d'un processus de compilation, réencodage, ajout/suppression d'informations soit limpide. Cela n'a rien à voir avec une conversion. Et vous ne pourrez jamais revenir en arrière, ie. récupérer la source à partir du g1a.
Citer : Posté le 05/05/2018 17:58 | #
Ouais... ok... mais grâce à quel logiciel on arrive à faire cette "transformation" entre mon fichier de départ et mon add-in?
Citer : Posté le 05/05/2018 18:02 | #
Il faut tout simplement un compilateur tel que GCC, qui transforme un fichier .c en fichier binaire.
Il te faudra également un wrapper g1a, qui ajoute l'entête g1a. Cet outil est dans le tuto de Lephé que j'ai linké plus haut.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 05/05/2018 18:05 | #
ok merci beaucoup
Citer : Posté le 05/05/2018 18:25 | #
Qui compile.
Bordel. Zezombye, tu devrais pas dire ce genre de bêtises enfin.
Citer : Posté le 05/05/2018 18:30 | #