Posté le 15/07/2018 12:09
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 146 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/09/2022 17:01 | #
L'allocation freeslot ne marche toujours pas, mais je laisse tomber pour le moment, la fuite memoire etant rebouchee, kmalloc fait parfaitement l'affaire.
Ca progresse oui, mais j'ai encore des erreurs inexpliquees sur mon calcul d'integrale, je veux dire que ca marche dans certains cas et ca renvoie une erreur dans d'autres cas, un peu comme l'overclock! Pour l'overclock, j'ai rajoute une boite de dialogue en debut d'addin, ce qui laissera la possibilite aux gens de choisir et si ca crashe en overclocke, ils pourront quand meme utiliser xcas.
Citer : Posté le 04/09/2022 22:59 | # |
Fichier joint
mais ca n'a pas l'air de fonctionner quand je fais call g.dbgprint()
J'ai un peu expérimenté avec la commande call de gdb et elle me semble très instable. Arrêter un programme pour appeler une fonction complètement différente est quelque chose de très complexe, il faut donc que le programme soit dans un état "parfait". De plus elle a été designé pour des environnements plus "traditionnels" : gdb ne s’attend pas à debugger à la fois l'OS et le programme utilisateur, quand on fait un syscall, dans la plupart des cas, cela apparaît comme une seule instruction "instantanée" pour l'espace utilisateur. Je ne suis pas certain à 100% que ce soit la raison de son instabilité mais ça ne me semble pas complètement impossible comme situation.
J'avais testé que brièvement cette feature car je ne l'utilise pas (je fais plus de reverse-engineering que de "vrai debug" avec gdb) et je ne suis pas vraiment en capacité de plus investiguer que ça car la rentrée va être plutôt chargée pour moi. J'essayerai de revenir dessus (si je m'en rappelle) quand je pourrai.
En attendant tu peux essayer d'appeler dbgprint depuis KhiCAS lui-même, je ne sais pas si ça casse beaucoup ton workflow mais ça peut être un compromis fonctionnel.
Fait attention, le print via le port série sera sur le stderr de l'émulateur, pas du debuggeur. Si tu veux être sur de ne pas te mélanger, lance l'émulateur dans un terminal séparé et redirige son stdout vers /dev/null, cela permettra de cacher les messages de fxCG50gdb et ne garder que la sortie série (et les quelques warnings de wine).
J'ai joint un G3A de test de la sortie série (similaire au code d'exemple de mon post sur le topic de fxCG50gdb) si tu veux vérifier que cela fonctionne.
Le projet stagne depuis presque un an et demi donc ça m'étonnerai que tu n'ai pas une version à jour. Si tu veux en être sûr tu peux la télécharger dans les releases GitHub. (les versions msvc et mingw devraient se comporter de manière identique même si la version "officielle" est la mingw).
Citer : Posté le 05/09/2022 09:53 | #
En fait le call finit par crasher.
L'appel a dbgprint() depuis KhiCAS fonctionne bien.
Ajouter des dbgprint() dans le code est un plus par rapport a faire des affichages directement sur l'emulateur, parce qu'on peut en faire beaucoup, mais c'est beaucoup moins pratique que de pouvoir voir le contenu d'une variable a la volee, parce qu'il faut prevoir quelle variable on veut afficher pendant le debug et surtout parce qu'il faut environ 1/4 d'heure pour charger l'addin dans la memoire de l'emulateur (ca fait environ 4.5M a charger a chaque changement), je ne comprends d'ailleurs pas pourquoi c'est si lent (si vous avez une methode pour accelerer je suis preneur!).
Bon ce serait un confort supplementaire si ca marchait, mais le debugger est deja un formidable outil de mise au point, pouvoir tracer l'execution pas a pas et afficher les valeurs de variables de type standard C c'est extremement pratique, encore merci!
Citer : Posté le 18/09/2022 18:21 | #
Je suis en train de regarder s'il y aurait de la mémoire disponible pour KhiCAS et où sur les Casio, en particulier sur la 35eii et du coup la taille et la position du tas utilisé par le MicroPython de Casio m'intéresse, car c'est un candidat.
Sur la 90, il y a un truc pas clair du tout pour la position en mémoire En effet, l'instruction id en Python est censée donner l'adresse d'un objet Python. Si on tape hex(id(1.2)) on obtient 0x8c1e5710 chez Casio (contre 0x812ef00 en RAM statique pour KhiCAS) ou quelque chose d'approchant. Or cette adresse est dans la zone de memoire allouee pour le tas de malloc pour les addins, et ce tas est de 128K, loin du 1M mesuré par le programme de critor. Alors peut-etre que l'appli intégrée Python n'a pas le même memory layout qu'un addin?
Citer : Posté le 18/09/2022 18:49 | #
Pour autant que je sache, le tas des add-ins fait 90 ko sur la Graph 35+E II, et Python n'a que 90 ko. Le chiffre de 1 Mo me paraît très douteux puisque la puce RAM ne fait que 512 ko.
Citer : Posté le 18/09/2022 19:22 | #
Le 1M c'est sur les graph 90, critor donne 100 432 octets pour la graph 35eii.
Une hypothese serait que Casio n'utilisent pas le GC de MicroPython mais directement leur malloc, et qu'ils ont defini l'adresse de fin du tas malloc en 0x8c2fffff au lieu de 0x8c1fffff lorsque l'appli Python s'execute (donc un tas d'un peu plus de 1M). Autrement dit la zone utilisée est une partie de celle où je charge l'overlay de KhiCAS.
Demain je teste avec ma graph 35eii qui est à la fac, on verra si hex(id()) est toujours dans le tas ou pas, la taille de 90K n'est pas très éloignée de la mesure de critor mais avec un petit plus quand même, ça laisse un espoir... Car sur les 512Ko de la puce, c'est ballot d'être limité à 90K de tas et 32K de stack+ram statique, ça ne fait qu'un quart de la RAM utilisable!
Citer : Posté le 18/09/2022 21:29 | #
Pardon j'ai mal compris en première lecture.
Pour ce qui est de la RAM à partir 0x8c20000, comme tu le sais il y a 6 Mo jusqu'à la fin de la puce. Quand j'ai commencé à jouer avec la zone j'ai fait des backups pour voir ce qu'il y avait dedans. J'ai trouvé que les 3 premiers Mo étaient inutilisés (tout zéro), mais les 3 derniers contenaient des données. Ce n'est pas sans rappeler le fait que la version initiale de la Graph 90+E en démo à la tournée pédagogique avait un tas de 3 Mo, que j'ai toujours considéré destiné à Python. (La Graph 90+E une fois en production est repassée à 128 ko.)
En tous cas, si MicroPython utilise du tas supplémentaire, c'est probablement plutôt à la fin de la RAM.
As-tu essayé de faire le test de l'id mais après avoir créé assez de variables pour remplir le tas de 128 ko ? Il n'est pas exclu que l'hypothétique zone de 1 Mo ne soit utilisée qu'une fois le tas plein.
Quant à la Graph 35+E II, ce n'est pas un quart de la RAM utilisable non. 512 ko c'est la puce toute entière, qui contient aussi ta pile, la mémoire principale, les données de l'OS, et plus. S'il reste 128 ko de non utilisés sur la puce c'est un maximum à mon avis.
Citer : Posté le 18/09/2022 22:27 | #
Oui, c'est possible qu'il y ait plusieurs arènes comme tu le fais dans kmalloc, mais d'un autre coté pourquoi se fatiguer si on a une zone contigue de mémoire entre 0x8c1e0000 et 0x8c2fffff? Bon faut que je teste... Et pour les addins normaux, on conserverait un tas de 128K peut-etre pour assurer la compatibilité avec toutes les Prizm (qui sauf erreur de ma part ne propose justement pas Python).
Pour la 35eii, elle a 512K de ram, c'est 2 fois plus que la Numworks quand meme, où on arrive à libérer presque 100K de tas+32K de stack (et 32K de mémoire pour le scriptstore, ce qui doit être l'équivalent de la mémoire principale). Alors être limité à 90K de tas +32K de ram statique+stack, ca parait dommage de ne pas faire mieux (d'ailleurs si je lis bien, les modèles d'avant disposaient de 256K de RAM non utilisée que CasioPython met à profit). Sauf si ils ont programmé de manière désinvolte chez Casio. (ce qui est fort possible bien sur).
Citer : Posté le 18/09/2022 22:30 | #
Cette zone est utilisée sur la Graph 35+E II... et contient notamment ta pile et ton tas.
Il est peut-être possible de squatter un autre bout de RAM, mais je n'ai pas de données sur ce qu'il peut y avoir de libre et/ou à quelle adresse.
Citer : Posté le 18/09/2022 22:43 | #
Oui, c'est pour ca que je me disais qu'il faut localiser la zone utilisée par MicroPython sur la 35, elle est surement safe.
J'ai confirmation que le tas est bien entre 0x8c1e0000 et 0x8c2fffff sur la 90, et pas à la fin de la RAM (dommage, ca aurait fait une zone de RAM safe à utiliser, sans avoir besoin de tester si ça a des conséquences sur le reste du système).
Il suffit de generer une grosse liste genre L=list(range(40000)), ensuite les adresses renvoyées par hex(id(1.2)) sont par exemple en 0x8c2253d0.
Citer : Posté le 19/09/2022 09:42 | #
Intéressant, bien vu pour la zone en 0x8c2. Au pire tu peux toujours te coller plus loin, c'est pas dramatique.
Attends, j'ai l'impression de ne pas t'avoir compris de nouveau. Pour autant que je sache, sur Graph 35+E II, MicroPython utilise juste le malloc() du système. Tu as accès à la même chose dans KhiCAS. S'il doit y avoir de la mémoire en plus, alors c'est un bout de RAM jamais utilisé par l'OS, mais je ne sais pas dans quelle zone ce serait, et il faut comme toujours être prudent sur le fait que l'agencement mémoire change d'une version de l'OS à l'autre.
Citer : Posté le 19/09/2022 13:08 | #
Je viens de modifier khicas.g1a en interne pour tester les adresses des objets créés, je trouve des 0x8805xxxx, i.e. le malloc système commence un peu après 0x88050000. Sur MicroPython, ça commence en 0x88067xxx et je suis au-delà de 0x88070000, soit un écart qui dépasse les 128k avec 0x88050000. Donc le tas MP et le heap de malloc ne semblent pas confondus. Il y aurait une zone mémoire utilisable à la fin du tas malloc.
Citer : Posté le 19/09/2022 18:37 | #
Mes hypotheses actuelles sont les suivantes: sur les 512K de RAM, il y a 192K a partir de 0x88050000 qui servent pour le tas normal et le tas Python (qui utiliserait alors le gestionnaire de tas gc de MicroPython). La frontiere serait en 0x88067000, avec 94208 octets de tas et 102400 octets pour MicroPython. Un peu bizarre comme choix plutot que pile au milieu en 0x88068000, mais ca pourrait correspondre a un cahier des charges avec >= 100 000 octets pour Python.
On y ajoute 64K de memoire principale, 2 stacks de 32K, une pour chaque thread (le thread de l'addin etant remappe en 0x08100000), et il reste 192K pour le thread de l'OS (dont son propre tas), tous a des adresses < 0x88050000. Il faudrait voir si ca marche sur d'autres versions de l'OS (j'ai du passer ma calc en 3.5 pour pouvoir faire des tests en Python).
A propos, il me semble qu'il y a une typo dans https://bible.planet-casio.com/lephenixnoir/sh7305/memory.html, au lieu de char *os_version = (void *)0xa0010020; ca devrait etre 0xa0010021
Je pense que je vais essayer d'utiliser les 192K en shuntant completement le malloc systeme et en utilisant une seule arene de kmalloc de 192K. Ca permettrait de doubler la memoire disponible pour KhiCAS sur la 35gii et les modeles equivalents a l'etranger (ce sont d'ailleurs principalement eux qui telechargent la version monochrome de KhiCAS, 60 telechargements sur 90 du 1er au 17 septembre ; la version couleur a plus de succes avec 163/242 telechargements, +59 personnes qui ont telecharge l'archive zip qui contient tout). Et de depasser la Numworks :-)
Ca pourrait interesser d'autres addins...
Citer : Posté le 20/09/2022 09:56 | #
j'ai téléchargé KhiCAS sur la 35+E II et c'est vraiment formidable. C'est vrai qu'on est un peu à l'étroit en mémoire, mais bon, c'est un travail super. Merci de ton investissement
https://joz.alwaysdata.net/info/
Citer : Posté le 20/09/2022 11:30 | #
Malheureusement, mes essais plantent pour le moment :-(
De plus apres essai sur l'OS 3.40 de l'emulateur, le tas alloue a Python y semble plus petit que sur 3.50, et la zone 0x88070000 inutilisable ce qui reduit la zone potentiellement utilisable de 64K et diminue donc l'interet d'une telle manip (passer de 90K a 120K ne va pas changer enormement).
Donc pour le moment je vais en rester au 90K de tas et plutot porter quelques ameliorations de l'UI de la 90 vers la 35.
Citer : Posté le 20/09/2022 19:28 | #
Voila, j'ai rajoute pour la 35eii l'acces a la table de caracteres ascii par shift INS (on insere un caractere).
Et quelques instructions pour explorer la memoire (je vais aussi les mettre sur la 90):
16 touche sto 2 fois : permet d'afficher les entiers en base 16 (faire 10 sto sto pour revenir en base 10, ca marche aussi pour la base 8)
addr(objet) : renvoie l'adresse en memoire d'un objet de KhiCAS (sauf pour les objets non alloues: petits entiers et flottants), un peu comme id en Python (mais id est deja utilise dans Xcas pour la fonction identite).
Les 2 commandes qui suivent sont a utiliser a vos risques et perils:
read32(adresse,n) qui affiche la valeur en memoire de n groupes de 4 octets. Attention au crash si l'adresse est invalide, si on passe un addr(objet) en argument ca ne devrait pas poser de problemes. Ne pas depasser n=32 sur la 35eii (il manque encore des garde-fous dans l'editeur d'expressions/matrices pour les objets trop gros)
write32(adresse,valeur) qui modifie la memoire (a utiliser avec encore plus de precaution!!!)
Par exemple A=1+2i
read32(addr(A),5) renvoie le format d'affichage (0) en 1er mot, puis la partie reelle sur les 2 mots suivants et la partie imaginaire sur les 2 derniers mots.
Citer : Posté le 23/09/2022 14:26 | #
J'ai maintenant reussi a utiliser dans Xcas (pas encore public) une partie de la memoire au-dela du tas, sur les OS 3.4 et 3.5. J'ai teste sur l'emulateur du premier OS de la graph 35 (OS 3.1) ou le memory layout est different et MicroPython utilise le tas. Ca a certainement ete optimise ensuite, au lieu d'utiliser le malloc systeme, Casio a decide de passer au gc de MicroPython dans la zone libre.
OS 3.1: Python id commence a 0x8805bxxx, fin >= 0x88067830, Xcas a="123", addr(a) renvoie 0x88051090, debut du tas probablement en 0x88050000. Avec read32, je vois des 0 apres la fin du tas, je peux par exemple ecrire en 0x88068000 avec write32 et relire la valeur ecrite avec read32. A premiere vue, l'espace est libre.
OS 3.4/3.5 Python id commence a 0x88066xxx, fin en 0x8807xxxx soit 106 496 octets, essentiellement pas de changement pour Xcas (malloc).
Pour toutes les version d'OS, je conjecture donc que la memoire utilisable occupe au moins 0x16000=90112 octets de 0x88050000 a 0x88066000 (exclus). La zone au-dela semble libre et utilisable, et est utilisee par le tas gc MicroPython sur les OS 3.4 et 3.5.
Citer : Posté le 23/09/2022 18:49 | #
Je mets en telechargement une version alpha pour Graph 35eii avec 170K de memoire disponible (geree par kmalloc), testee sur les OS 3.1 et 3.5:
khicas.g1a
Citer : Posté le 04/10/2022 19:56 | #
Mise a jour pour les 90 et les 35eii (j'ai testé avec l'OS 3.6, pas vu de problèmes).
Nouveauté: on peut se déplacer dans le graphe d'une fonction ou d'une courbe en paramétrique/polaire, avec affichage de x,y (et t pour les paramétriques). On peut aussi afficher la pente et un vecteur tangent (F3) ou un vecteur normal pointant vers le centre de courbure (F4) ou le cercle osculateur et le rayon de courbure (F5). Le menu permet de calculer une racine, un point à tangente horizontale ou verticale, une intersection sur la 90, un point d'inflexion, l'aire sous la courbe ou la longueur d'un arc de courbe (les valeurs sont stockées dans des variables pour pouvoir être ultérieurement utilisées depuis le shell). Sauf erreur de ma part, c'est donc plus complet que le menu Casio et cela fonctionne aussi pour les paramétriques, pas seulement pour les fonctions.
KhiCAS stocke dans x0, x1, x2, y0, y1, y2 l'expression de x(t),y(t) et de ses dérivées 1ère et 2nde pour faciliter l'étude analytique de la courbe.
Sur les 35eii, on est maintenant à la limite de taille d'addin :-(
La doc n'est pas encore à jour sur cette nouveauté, ça viendra dans les prochains jours...
ljf Invité
Citer : Posté le 05/10/2022 17:58 | #
Désoler de jouer les trouble-fêtes :
- Khicas90
- F6 (pas d'accélération, même résultat si F1 de toutes les façons)
- Fich.
- 1 Applications
- 1 Géométrie
- 2 Nouvelle figure 3d
→ crash : System ERROR - REBOOT : [EXIT] - ADDRESS (W) - TARGET = D318430B - PC = 00000001
ljf Invité
Citer : Posté le 05/10/2022 18:16 | #
Et toujours : fx-CG50, os 3.60.0202