Posté le 19/07/2017 19:46
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 271 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 19/07/2017 21:42 | #
Question principale : Je ne connais aucune raison valable de ne pas être compatible SH3. Alors quel est le problème ?
Je t'ai pas si t'as relu ton fichier doc/Manuel Renesas.txt, mais il y a un problème qui saute aux yeux dans le lien et encore plus en page 3 du pdf en question, c'est que c'est le manuel de groupe SH-3/SH-3E/SH-3DSP, pas SH4 !
Remarque préliminaire sur ton guide : le fournir en PDF ne coûterait rien et serait un poil mieux (plus facile à lire). Je vais commencer avec la lecture directe du manuel et tester le programme après pour te donner une idée des premières impressions que tu donnes !
Sur l'interface :
Je déconseille (sur des raisons parfaitement personnelles) de limiter la localisation des fichiers à un dossier particulier. Imagine que je veuille faire un dossier par projet, par exemple ? Impossible : la mémoire de stockage ne supporte pas les sous-dossiers. Je préférerais prendre le parti, comme l'application E-ACT, de laisser l'utilisateur chercher son fichier dans toute la mémoire, quitte à restreindre la liste des extensions autorisées (le nec plus ultra serait d'avoir un switch « fichiers .{s,src,asm} / tous les fichiers »).
Si tu ne sais pas pourquoi tu as choisi [x²], c'est peut-être qu'il existant un choix plus pertinent. [F↔D] évoque plus un changement de mode pour moi, mais c'est encore moyen. Le mieux serait sans doute une F-key avec une icône appropriée ! Ou intégrer ça dans les options, parce que je ne pense pas qu'on change ce paramètre toutes les deux minutes. Après, c'est toi qui vois sur le besoin d'avoir une option rapidement accessible. Et si ton attribution des caractères aux touches est non-triviale, mets le détail dans le manuel, comme ça quand j'aurai oublié, je pourrai au moins retrouver l'info sans tout tester ; surtout si c'est un peu random sur les bords !
Visiblement la compilation et les erreurs sont bien intégrées à l'éditeur, ça sent le bon boulot.
Sur l'assembleur en lui-même :
Pour les formes hexadécimales, il y en a pas mal qui existent déjà : 0x##, h'##, ##h. Je serais partisan de ##h, ou h## si c'est trop compliqué à implémenter (mais j'en doute), qui est plus compréhensible, et utilisé dans l'industrie et plein d'autres assembleurs (NASM). En puis je risquerai pas de confondre avec le contenu d'un zone mémoire, moi qui prends tout pour des pointeurs dès que ça commence par * !
La référence sur les labels ne pointe sur la bonne section ni du manuel linké dans le dossier doc (7.1.5), ni du manuel SH4 que je possède (« SH-4A Extended Functions Software Manual »). Il y a peut-être quelque chose à vérifier ici !
J'espère que le test de l'add-in sera intégré à l'application quand le linker sera terminé ! Quelques indications sur comment implémenter ça :
- Le linker génère le fichier g1a à la racine de la mémoire de stockage ;
- Il y a un syscall pour rafraîchir la liste des add-ins du système depuis la mémoire de stockage ;
- Localiser le nom de l'application ou autre signature appropriée pour lancer l'add-in, le must étant de vérifier un maximum de paramètres pour être sûr de toujours lancer le bon et ne pas avoir à demander à l'utilisateur de le choisir lui-même !
- Lancer l'add-in à l'aide du syscall approprié, j'ai uniquement un doute sur ce qui se passe quand l'add-in lancé se termine (retour à l'éditeur, ou pas).
Pour terminer sur le manuel, un texte justifié avec une police sans-serif, une vraie liste à puces et des titres mieux mis en valeur ferait très professionnel, enfin c'est du détail ! (J'aime juste aller au bout des choses quand je teste <3 )
Je vais tester l'add-in ensuite, je posterai des remarques dessus un peu plus tard.
Citer : Posté le 20/07/2017 08:16 | #
Salut, ça a l'air fort intéressant, mais je n'ai pas bien compris à quoi ça sert
Citer : Posté le 20/07/2017 11:22 | #
@Ninestars Yo, c'est un outil pour développer des addin en ASM depuis la calculatrice 8)
@Lephenixnoir Tout d'abord, merci pour tes premières impressions, j'en prends bien note !
Je pense ne sortir l'add-in que pour les caltos SH4 pour l'instant, car la plage de 256 ko pour le linking va être super importante. Ça sera la zone où l'add-in sera généré du coup. Y'a tellement de dépendances que tout faire tenir dans le heap va être très tricky sur SH3, mais ça peut se tenter si la version SH4 tourne comme je l'espère.
Ensuite, j'suis pas du tout à la page des nouveautés apportées par les procos SH4, c'est plus pour conserver un add-in compatible avec les caltos les plus récentes, dont la mienne, que je target cette déclinaison Ça va demander de réécrire un peu fxlib au passage, et y'a aussi moyen de tailler dans les tables d'optimisation, que je vais pas exploiter pour gagner de la place en mémoire.
Après, pour la restructuration des fichiers, ça viendra à la fin, et on devrait pouvoir créer un dossier par projet avec les sources + d'autres fichiers de config. Permettre à l'utilisateur de chercher dans toute la mémoire serait pas très ergonomique, à mon humble avis. (et je sais surtout pas comment récup tous les noms de fichier )
Un menu d'options serait bien aussi, en effet. Je pense aussi à intégrer une doc directement dans la calto, réservée à ceux qui ont la place pour ces bêtises.
Pour l'éditeur, va pour changer le signe d'une valeur hexa, je pensais à 'xVALUE'. Sinon toutes les autres syntaxes sont très répandues, mais sur calto c'est pas très fun à retaper
A propos de ma 'doc', en effet y'avait une erreur, les instructions branch sont en 7.1.5 et non en 7.1.4
Le test de l'add-in ne sera pas supporté par l'app. Je m'explique. Dans l'absolu, si on veut tester une app créée, il faudrait une VM avec de vrais outils de debug, mais sur calto ça me semble mort :/ Je préférais juste faire un syscall pour rafraîchir la liste des add-in (au passage je savais pas que ça se faisait ainsi, merci ^o^), et laisser l'utilisateur quitter proprement l'éditeur pour tester dans un environnement legit.
Pour la doc, lorsque le projet sera fini, y'aura un vrai pdf et tout, pas d'inquiétude
Citer : Posté le 20/07/2017 12:01 | #
Il se trouve que tout le code qu'on développe, pour SH3, est nativement compatible SH4, et pour ce que j'en sais, il n'y a quasiment aucune extension du SH4 qui ne possède vraiment d'applications complexes : il y a la paire MOVLI/MOVCO qui touche à l'atomique, mais la SH3/SH4 possède déjà TAS.B, donc peu d'intérêt ; seul MOVUA.L (Move Unaligned) pourrait être vraiment exploités à mon sens.
Dans tous les cas, on a des méthodes pour discerner les différentes gammes de MPU, en particulier les SH3 des SH4, et on sait donc créer des add-ins qui utilisent les spécificités de l'un ou de l'autre tout en restant compatibles avec les deux (au prix de se trimballer le code pour les deux, mais c'est généralement pas si lourd). C'est assez facile en assembleur, donc ce serait un plus de savoir assembler les deux archis !
Reste la question du runtime, et effectivement l'empreinte mémoire est un facteur important. Mais avec 48 ko de heap, voire un peu plus si tu es imaginatif (j'ai en tête 5 ko sur les buffers de SaveDisp() + 32 ko (SH3)/12 ko (SH4) qu'on utilise parfois sans demander, mais le système se plaint pas + ce qui te reste de RAM statique (8 ko moins la taille de tes sections B et R), y'a de quoi faire), c'est un bon défi technique et à mon sens parfaitement réalisable, surtout si tu es capable d'assembler les fichiers en une seule passe, et peut-être quelque chose de similaire pour le linker (je sais que c'est possible pour l'assemblage, pour le linkage je ne connais pas assez les détails pour l'affirmer).
Quant à la réécriture de fxlib, beaucoup moins que tu n'as l'air de le penser. C'est un gros fourre-tout à syscalls, et à part quelques parties délicates (mais pas critiques du point de vue de la compatibilité, comme sprintf()) qui me semblent être implémentées dans fxlib, y'a quasiment que des objets de 10 lignes. Et tu peux toujours fournir ta propre implémentation de fxlib en linkant les sycalls à la main sans t'embêter avec le format de Casio si jamais t'as de la chance. Tu peux aussi fournir un superset en ajoutant quelques syscalls à la main, c'est vraiment une affaire de lister dans un fichier des paires entier/nom de fonction si tu prépares un peu le terrain, donc c'est tout bénef'.
Pour chercher dans toute la mémoire, c'est vraiment rapide. Y'a qu'une racine et des dossiers dans cette racine. Les dossiers ne peuvent pas contenir de sous-dossiers, l'arbre ne fait que deux nœuds de hauteur. Et pour lister les fichiers, cherche du côté de Bfile_FindFirst() et Bfile_FindNext(). Fais *très* attention à bien fermer les handles de recherche, sinon tu peux dérégler le système (lol) : MEMORY/EACT ne trouvent plus rien dans la SMEM, plus d'add-ins, bref le gros bordel. Dans ce cas, OPTI (F5), puis transferts avec le PC, et si ça marche pas, t'es bon pour le reset complet.
Une aide dans la calto, bonne idée. Un truc aussi complet que ta doc PC n'est sans doute pas nécessaire, mais un résumé des commandes et la table de correspondance entre les touches et les caractères seraient utiles. Pour l'hexa, le h peut être obtenu juste en appuyant sur [F↔D], non ? T'es pas obligé de te conformer à ce qui existe déjà, mais c'est plus pratique pour les nouveaux utilisateurs. Après, x on comprend bien de quoi il s'agit.
Pour le test, je ne parlais guère que d'un raccourci dans l'interface pour lancer l'add-in, personne ne s'attendra à de vrais outils de debug. Quand on a beaucoup d'add-ins, devoir aller chercher le dernier à chaque fois peut être un peu longuet à force.
Citer : Posté le 27/09/2017 12:57 | #
Alors ca, ca m'interesse. Aucun moyen de le rendre compatible SH3?
PM Générateur
graph100+ bleue
Neuronix9302
2nde GT
Citer : Posté le 27/09/2017 13:01 | #
Les sh3 sont définitivement mortes avec le mode examen, donc je n'en vois pas trop l'intérêt.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 27/09/2017 13:02 | #
Bah, j'ai qu'une SH3 et pas de SH4, donc voila l'interet (ma SH4 est morte, et l'autre, les touches directionnels ne fonctionnent plus )
PM Générateur
graph100+ bleue
Neuronix9302
2nde GT
Citer : Posté le 27/09/2017 18:04 | #
Ça doit être faisable sans trop de difficultés. @FMC_ , si tu veux une quelconque info sur le portage, on peut te trouver la doc' appropriée.
Citer : Posté le 27/09/2017 18:25 | #
Peut etre avec ca, un compilo C on calc sera plus facile a implementer
Ok, je sors porte
Ajouté le 27/09/2017 à 19:07 :
@Lephe Je veux bien la doc pour essaye de le porter stp?
PM Générateur
graph100+ bleue
Neuronix9302
2nde GT
Citer : Posté le 27/09/2017 19:22 | #
Il n'y a pas vraiment de doc au sens de « tutoriel »... je parlais plutôt d'indications pour porter des points précis (certaines I/O foireuses, les trucs liés à la mémoire, ML qui est pas totalement compatible, etc) en cas de problème.
Citer : Posté le 27/09/2017 19:26 | #
Bah je veux bien que tu m'aides, mais apparement ce qui le rend non compatible, c'est qu'il utilise(ra?) les 256ko de memoire ram supplementaire des SH4
Si c'est possible, tu peux venir sur le chat stp?
PM Générateur
graph100+ bleue
Neuronix9302
2nde GT
Citer : Posté le 03/10/2017 14:32 | #
Je testerai ça ce soir