Posté le 16/04/2019 20:58
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 150 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 17/04/2019 07:45 | #
Non, les fonctions standard fournies par casio sont dans fxlib.
Absolument rien n'a été testé avec la Graph 35+E II puisque seuls toi, Critor et moi en avons une pour autant que je sache. On ne s'amuse pas vraiment à trimballer des versions compilées parce que c'est le meilleur moyen de refaire le coup de la Prizm et perdre les sources. Normalement tu dois la compiler avec ton GCC, à l'étape 6 de ce tutoriel. Elle est alors utilisée "toute seule" (pas besoin de -I ou de -lc notamment).
Citer : Posté le 17/04/2019 13:54 | #
Oui, j'ai bien vu le tutoriel, mais je n'ai pas envie de recompiler une version de gcc avec cette newlib, parce que ca va entrer en conflit avec mon install pour la 90. Il me semble indispensable d'avoir la libc.a et ses headers dans un repertoire independant de l'install de gcc puisqu'on n'utilise pas la meme libc sur la 90 et la 35e2, qu'on precise dans la ligne de commande de compilation avec -I... et -L.../-lc. En plus le source de newlib est bien plus gros que celui de la libc de libfxcg, s'il y a le moindre probleme a corriger, ca va etre la galere. Donc pour le moment je reste sur modifier stdio.c de la libc de libfxcg, et je vais voir si ca aboutit (en plus, j'avais fait pas mal de modifs pour la 90 donc le source m'est familier). Si ca n'aboutit pas j'essaierai avec newlib mais en dehors de l'install de gcc.
Sinon, je persiste a penser que la libc de la branche liberation est celle du SDK de casio, il faut bien qu'ils aient une libc en plus de leur libfx. D'ailleurs elle est completee par un peu de C++ (avec par exemple iostream, complex, etc. dans les headers), qui risque d'entrer en conflit avec la uSTL, donc mieux vaut ne pas s'en servir pour KhiCAS. Faudrait faire des diff -q pour en avoir le coeur net...
Citer : Posté le 17/04/2019 15:13 | #
Ah, tu veux compiler les deux add-ins sur le même dépôt ! Dans ce cas tu as bien raison, c'est plus facile de modifier la version Prizm...
Quitte à insister un peu, je maintiens ma position : toute la partie standard implémentée par Casio se trouve dans libfx.a. Fais un dump de l'archive si tu veux t'en convaincre !
J'ai clôné le dépôt d'Eigenmath ; selon toute probabilité le fichier libc.a est une implémentation partielle que j'ai écrite. On y retrouve une partie de stdio, stdlib, string et time ; et je reconnais plus d'un fichier objet. C'est très loin d'être une implémentation complète.
D'ailleurs le support de la lib standard C++ dans le SDK est dérisoire, c'est essentiellement inutilisable. Il n'y a pas de STL ; au plus une implémentation partielle de string et je crois qu'un des documents explique qu'ils ne sont pas sûr qu'elle marche.
Citer : Posté le 17/04/2019 16:04 | #
Oui, effectivement libfx.a contient des fichiers objets qui devraient etre dans la libc et la libc elle-meme ne contient pas beaucoup de fichiers et il semble y avoir des doublons, je pensais en terme de headers. Bref, c'est pas l'ideal, il y a peut-etre 2 implementations pour la meme fonctionnalite si on linke avec libc.a puis libfx.a.
Sinon, je ne vais pas compiler les 2 addins avec la meme arborescence source de giac car les UI vont differer et giac un peu (par exemple time ne va sans doute pas marcher sur la 35e2), mais je fais ca sur une seule VM donc une seule install de gcc.
Ajouté le 17/04/2019 à 17:34 :
Mon fichier addin.ld pose probleme, lorsque je veux linker un programme test avec la ustl, ca renvoie
/home/parisse/opt/sh3eb-elf/lib/gcc/sh3eb-elf/7.3.0/../../../../sh3eb-elf/bin/ld: section .rodata._ZN4ustl8memblock4readERNS_7istreamE.str1.4 LMA [0000000000309050,0000000000309067] overlaps section .data LMA [0000000000309050,0000000000309094]
/home/parisse/opt/sh3eb-elf/lib/gcc/sh3eb-elf/7.3.0/../../../../sh3eb-elf/bin/ld: section D LMA [0000000000309098,00000000003090fb] overlaps section .rodata._ZN4ustl6string4readERNS_7istreamE.str1.4 LMA [0000000000309084,000000000030909b]
/home/parisse/opt/sh3eb-elf/lib/gcc/sh3eb-elf/7.3.0/../../../../sh3eb-elf/bin/ld: section .rodata._ZNK4ustl6string5writeERNS_7ostreamE.str1.4 LMA [000000000030909c,00000000003090a3] overlaps section D LMA [0000000000309098,00000000003090fb]
Voila le contenu complet de addin.ld
OUTPUT_ARCH(sh3)
ENTRY(initialize)
MEMORY
{
rom : o = 0x00300200, l = 2048k
ram : o = 0x08100000, l = 64k /* pretty safe guess */
}
SECTIONS
{
.text : {
*(.pretext) /* init stuff */
*(.text)
} > rom
.rodata : {
*(.rodata)
*(.rodata.str1.4)
*(.eh_frame)
*(C)
_romdata = . ; /* symbol for initialization data */
} > rom
.bss : {
_bbss = . ;
_bssdatasize = . ;
LONG(0); /* bssdatasize */
*(.bss) *(COMMON);
_ebss = . ;
} > ram
.data BLOCK(4) : AT(_romdata) {
_bdata = . ;
*(.data);
_edata = . ;
} > ram
}
Ajouté le 17/04/2019 à 17:49 :
Bon j'ai trouve sur stakoverflow, il manquait un *(.rodata*) dans la section .rodata.
Citer : Posté le 17/04/2019 19:22 | #
C'est ça, les chaînes de caractères constantes sont placées par GCC dans la section .rodata.str1.4 (taille de caractère 1, alignement 4 si je ne me trompe pas), et des variantes plus exotiques pour le C++.
Citer : Posté le 17/04/2019 21:39 | #
Du coup, mon programme test avec la ustl a l'air de fonctionner. Mais si je compile avec ma libc la branche liberation, l'addin fait un reset, et ce meme si je mets une boucle infinie des le debut de la fonction main. Donc il doit y avoir une initialisation avant appel de main qui plante, mais je n'ai aucune idee de ce que ca pourrait etre, je soupconne que c'est dans les fonctions de gestion de la console avec saisie naturelle qui sont en C++ avec tout ce que ca peut comporter d'initialisations avant main.
Du coup j'ai essaye de prendre l'autre UI d'eigenmaths (celle avec les menus), elle contient un sous-repertoire tex, et la il me manque la resolution d'un symbole si je compile, a savoir undefined reference to _setPixel. La fonction semble etre ecrite en assembleur dans le fichier disp.src, mais celui-ci ne compile pas avec l'assembleur de gcc, meme en le renommant en disp.s
sh3eb-elf-as -c src/tex/disp.s -o build/tex/disp.s.o
src/tex/disp.s: Assembler messages:
src/tex/disp.s:2: Error: unknown opcode
src/tex/disp.s:3: Error: excess operands: 'the color of a pixel on the screen.'
src/tex/disp.s:9: Error: invalid operands for opcode
src/tex/disp.s:12: Error: invalid operands for opcode
src/tex/disp.s:26: Error: invalid operands for opcode
Si je ne peux pas utiliser l'UI d'eigenmaths, il va probablement falloir repartir de l'UI pour la 90, mais ca va prendre beaucoup de temps avant d'avoir quoi que ce soit vu qu'il y a beaucoup de differences entre les 2UI.
Citer : Posté le 17/04/2019 22:13 | #
Je te plains un peu. C'est encore moi qui ai écrit le module d'affichage naturel qui est utilisé par cette version d'Eigenmath. Tu n'y trouveras pas ton compte pour un programme aussi complet que KhiCAS qui a beaucoup de termes différents à afficher.
Pour la petite histoire, la version originale était pour le SDK et utilisait quelques fonctions dans un de mes fichiers récurrents, "disp.src". La syntaxe SDK diffère de celle de GCC, c'est pour ça que tu as des erreurs. setPixel() doit juste afficher un pixel à l'écran, tu pourrais le remplacer par n'importe quoi qui appelle Bdisp_SetPoint_VRAM() par exemple.
Ces deux choses ont déjà plusieurs années et je n'en suis plus très fier. La seule alternative que je peux te proposer est de chercher le port original d'Eigenmath sur Graph 85, auquel l'auteur a (d'après Nemhardy) ajouté l'écriture naturelle à peu près en même temps. Je pense que c'est ta meilleure chance si tu veux éviter de refaire l'UI de zéro.
Citer : Posté le 18/04/2019 10:04 | #
Bon, j'ai reussi a recompiler les 2 ui d'eigenmaths, a ceci pres que le moteur pretty print n'a pas l'air actif (j'ai du oublier quelque chose quelque part). Tout ca est encore tres experimental bien sur, l'archive est la: https://www-fourier.ujf-grenoble.fr/~parisse/casio/giac35.tar.bz2, il suffit de changer le lien symbolique de src vers src1 (saisie naturelle sans menu) ou src2 (entree algebrique et menus) pour compiler l'une ou l'autre des versions en utilisant make pour src1 et make -f Makefile2 pour src2. Il n'y a pour le moment pas un seul fichier source de giac, mais les dependances sont la (tommath et ustl), il ne reste plus qu'a croiser les doigts pour la suite...
Citer : Posté le 18/04/2019 10:24 | #
De mémoire il faut l'activer dans Shift+MENU sur le port de Nemhardy.
Je teste et je te dis.
Ajouté le 18/04/2019 à 10:28 :
J'ai pas mal d'erreurs de compilation et même une erreur de cible Makefile manquante dans src2. Il y a même un lien symbolique qui pointe dans /shared... >_>
Citer : Posté le 18/04/2019 17:02 | #
Ah oui, le fichier eigen.g1a est un lien, je mets la cible hors de la VM pour pouvoir le copier facilement sur la calculatrice, il suffit de supprimer le lien.
Quelles autres erreurs sinon?
Citer : Posté le 18/04/2019 17:23 | # |
Fichier joint
Je te mets un log de make -i en pièce jointe. Essentiellement j'ai <features.h> qui manque et wint_t qui est inconnu. Je ne compile jamais de C++ et je ne sais plus à quoi correspond le premier header. S'il provient du compilateur alors il y a une subtilité dans la toolchain...
Citer : Posté le 18/04/2019 19:12 | #
Il faut que je rajoute des headers manquants depuis les include de la libfxcg de la 90, je ne les vois pas chez moi parce qu'ils sont dans l'install de gcc et donc automatiquement includable. J'ai mis a jour l'archive, j'espere que ca ira mieux, mais il risque d'en manquer encore.
Ajouté le 18/04/2019 à 21:14 :
Sinon, shift-Menu n'affiche que About avec la version que j'ai compilee. Je ne sais pas si c'est a cause des changements que j'ai fait avant d'arriver a avoir une version qui marche, ou si je n'ai pas tout importe. On pourra s'en occuper plus tard.
Ajouté le 19/04/2019 à 19:02 :
Pour le pretty print, c'est probablement parce que le source que j'ai recupere https://git.planet-casio.com/Nemh/Eigenmath/ ne contient pas une version ou il est actif.
J'avance dans la compilation de giac. Y-a-t-il un equivalent de GetVRAMAddress ?
Il me reste aussi a comprendre comment marchent les timers.
Citer : Posté le 19/04/2019 20:17 | #
C'est le syscall 0x135
Ceux de fxlib sont configurés par SetTimer() avec un délai en millisecondes (qui sera arrondi au plus proche multiple de 25) et un callback. Ils envoient des événements qui font des appels réguliers et asychrones au callback jusqu'à ce que KillTimer() soit utilisé.
Citer : Posté le 19/04/2019 20:56 | #
J'ai fini la compilation, mais les nouvelles sont mauvaises, au lancement de l'addin, j'ai une erreur systeme
TLB ERROR
TARGET=08108000
PC=000000000
D'apres le fichier addin.ld, c'est une zone ram qui est concernee, il n'y aurait que 32k de RAM?
Sinon, comment j'appelle le syscall 135?
Citer : Posté le 19/04/2019 21:00 | #
Cette région de la RAM faisait historiquement 8k sur le SDK, le linker script de Kristaba (celui qui contient /* pretty safe guess */) étant très allègrement optimiste en mettant 64k.
J'ai récemment découvert que la zone avait été étendue à 32k en explorant le TLB, ce que j'ai documenté. Je ne sais pas de quand ça date. En tous cas ton problème semble démontrer que ça n'a pas été étendu sur la Graph 35+E II.
Le reste de la RAM se situe dans le tas ; historiquement 48k, mais sur la Graph 35+E II il fait autour de 90k d'après nos tests communs avec Critor. Tu n'as pas d'autre choix que d'aller jouer là-bas.
Citer : Posté le 19/04/2019 21:11 | #
J'ai regle ce probleme, c'etait un tableau reserve pour la tortue. Maintenant j'ai reussi a lancer l'addin si la fonction run ne fait rien, mais pas si elle fait quelque chose, avant que la console soit lancee j'ai l'erreur
ADDRESS (R)
TARGET = DF1ED42A
PC=E500D41F
Citer : Posté le 19/04/2019 21:14 | #
La valeur indiquée de PC est clairement fausse, preuve supplémentaire (s'il en fallait encore) que les System ERRORs ne sont pas fiables dans tous les contextes. La valeur de TARGET est très probablement fausse aussi, même s'il est plus difficile de le prouver...
Citer : Posté le 19/04/2019 21:26 | #
A priori c'est le parser qui pose probleme, je vais essayer de diminuer la taille de la pile du parser.
Ajouté le 19/04/2019 à 21:42 :
Ouaip, c'etait bien la taille de la pile du parser. Ca commence a marcher, mais pour une raison bizarre des que je tape un + dans une expression ca plante!!! D'autres calculs plus compliques marchent comme int(1/(x^4-1)). Il y a encore pas mal de debuggage en perspective, mais je pense que le plus dur est fait! J'ai mis a jour l'archive du source avec un nouveau repertoire src0, c'est la qu'est giac, il suffit en principe de faire make dedans (et la version actuelle de l'addin compile y est disponible en preview, c'est le fichier khicas.g1a)
https://www-fourier.ujf-grenoble.fr/~parisse/casio/giac35.tar.bz2
Ajouté le 20/04/2019 à 08:01 :
Bon, j'ai localise le probleme du plus, il est temporairement fixe en desactivant "aplatir_plus_only" dans kgen.cc.
Du coup, j'ai mis en ligne la toute premiere version alpha de l'addin https://www-fourier.ujf-grenoble.fr/~parisse/casio/khicas.g1a, il y a encore plein de crash mais pas sur des calculs simples en principe. J'ai aussi mis a jour le source. Penser a effacer FMENU.cfg s'il existe pour avoir des menus correspondant a Xcas.
Comment appelle-t-on un syscall (le syscall 135 pour GetVRAMAddress)?
Citer : Posté le 20/04/2019 08:50 | #
Pour les syscalls c'est dans la bible mais je ne la trouve pas
-Planétarium 2
Citer : Posté le 20/04/2019 16:32 | #
Bien joué !
Que fait aplatir_plus_only d'exotique ? Arrête-moi si je me trompe, mais ça ressemble juste à une fonction pour normaliser la forme des termes ?
Comme ceci.
_GetVRAMAddress:
mov.l syscall_table, r2
mov.l 1f, r0
jmp @r2
nop
1: .long 0x135
syscall_table:
.long 0x80010070