question sdk graph 90+e/ portage CAS

[parisse]

Apres une batterie d'autres tests, il semble que ca plante des qu'on utilise une instruction "Casio" (BDisp* ou PrintXY). Par contre libtommath (librarie C) ne pose pas de problemes. Peut-etre un probleme d'interaction entre malloc/free et new/delete? Il faut que j'explore la faisabilite de detourner new/delete vers la memoire statique https://www.planet-casio.com/Fr/programmation/tutoriels.php?id=62

[parisse]

J'ai detourne l'allocation dynamique c++ vers memmgr_alloc/free, new a bien l'air de marcher, mais un appel a delete fait tout crasher, alors que si on ecrit memmgr_free(ptr); au lieu de delete ptr; dans main(), ca marche. Pourtant j'ai modifie le code de void operator delete(void *) en remplacant l'appel a free(ptr) par memmgr_free(ptr) donc dans les 2 cas memmgr_free s'execute avec le meme parametre.
Le pointeur sur lequel on fait memmgr_free est en 0x8100144, le crash affiche ADDRESS (R) TARGET(0030DC09) PC=8100024. Les parametres de memmgr.h sont POOL_SIZE 128*1024, MIN_POOL_ALLOC_QUANTAS 4. Les parametres de ld sont rom (rx) : o = 0x00300000, l = 512k
ram (rwx) : o = 0x08100004, l = 256k
La seule difference que je vois entre l'appel direct de memmgr_free() depuis main ou en passant par delete c'est un stack frame. Si la memoire en 0x08100000 est partagee avec la stack, il peut y avoir conflit, mais normalement la stack descend en commencant de bien plus haut, donc il ne devrait pas y avoir conflit (d'ailleurs c'est identique avec ld 64K de ram et memmgr a 32K).
Si on ne peut pas resoudre ce probleme, je crois que cette fois c'est mort

[parisse]

J'ai trouve un fork de libfxcg https://github.com/AHelper/libfxcg qui pour l'instant ne crashe pas sur des tests simples.

[critor]

critor: il y a un build sur ma page https://www-fourier.ujf-grenoble.fr/~parisse/casio/

Désolé pour le délai, j'ai été assez occupé cette semaine, ma présence à l'Orme ayant décalé nombre de choses.

C'est testé. Je ne sais pas ce que vous avez changé, mais l'affichage me semble correct sur Graph 90+E.

Que pensez-vous d'annoncer votre version d'eigenmath, puisque celle actuellement en archive chez nous et Planète Casio n'affiche pas correctement sur Graph 90+E ?

Cela pourrait être utile à ceux qui passent le BAC avec ce modèle ces jours-ci, en attendant mieux bien sûr.

[parisse]

Je n'ai fait que recompiler, si ca corrige un bug, autant en faire profiter le maximum de personnes, etant entendu que je suis incapable de fournir le moindre support...
J'ai l'impression qu'il y a eu 2 forks d'un libfxcg originel ayant chacun complete dans des directions differentes, j'espere qu'en les mergeant je vais avancer dans le compilation de giac...

[parisse]

Un petit point :
* libc: relativement utilisable, certaines fonctions sont incompletes et il manque les fonctions de type scanf et donc l'entree console, je ne sais pas encore s'il sera necessaire de les avoir. Il y a une sortie console (stdout) et des ecritures fichiers (je n'ai pas encore teste la lecture), il faut juste mettre un chemin du type

Code: Tout sélectionner

FILE * f =fopen("\\\\fls0\\fichier.txt","w")

* uSTL : j'ai teste les templates vector et map, ainsi que string. J'ai pu detourner la memoire de malloc vers memmgr. Les flux ne marchent pas. J'ai un remplacement basique pour cout.
* tommath (entiers longs): semble ok.
* memoire: Il me semble qu'il y a 1M de RAM de dispo pour un add-in, en 0x08100000 (ou 0x88100000 qui designe la meme adresse physique). La stack est a +917408, malloc a +918272, et memmgr a +84, donc on doit pouvoir allouer pas mal de memoire dans la zone "RAM statique" avec memmgr. En flash, j'espere qu'il n'y a pas de limites autres que la flash dispo mais je n'en suis pas sur.
* giac: j'ai nettoye toutes les allocations dynamiques de variables statiques.
Il reste a tester l'interpreteur et le passage a l'echelle. Le temps de chargement d'un add-in de 4.5M risque d'etre tres long sur l'emulateur (41s pour eigenmath pour 291K, 10s pour test pour 50K, je prevois 10 minutes), donc si ca crashe ca risque d'etre trop fastidieux de faire beaucoup d'essais pour localiser. A moins que ca n'aille plus vite sur windows?

[parisse]

J'ai avance sur l'entree console, mais j'ai perdu beaucoup de temps parce que le segment BSS n'a pas l'air d'etre initialise a 0, du coup l'initialisation de FILE _impl_stdin={0,0,0,0,0,0,0,0,0} ne se faisait pas! Il semble qu'une parade soit d'utiliser le flag -fno-zero-initialized-in-bss.
Ou corriger le code assembleur de crt0.S:

Code: Tout sélectionner

! C runtime initialization for Prizm addins
! By Tari and calc84maniac, based on Kristaba's reverse-engineered crt0.

    .extern _main
    .global initialize
   
    .section ".pretext"
    .align 2
initialize:
! Preserve things on the stack
    mov.l r14, @-r15    ! Frame pointer
    sts.l pr, @-r15     ! Return address
    mov.l r4, @-r15     ! Parameter 1
   
! Copy .data section into RAM
    mov.l v_datald, r0      ! From
    mov.l v_sdata, r2       ! To
    mov.l v_edata, r3       ! Limit
dataLoop:
    cmp/hs r3, r2
    bt dataDone             ! Stop when r2 >= r3
    mov.l @r0+, r1
    mov.l r1, @r2
    bra dataLoop
    add #4, r2              ! Delay slot
dataDone:

! Zero out .bss
    mov.l v_ram_ebss, r2    ! To
    mov.l v_ram_bbss, r3    ! Limit
    mov #0, r1              ! Constant
bssLoop:
    cmp/hi r3, r2
    bf bssDone              ! Stop when r2 <= r3
    nop
    bra bssLoop
    mov.b r1, @-r2          ! Delay slot
bssDone:
   
! RAM is now initialized

    mov r5, r14             ! Save parameter 2
    mov #1, r6
    mov #0, r4
    bsr _GlibAddinAplExecutionCheck
    mov r6, r5
   
! main(r4, r5) with same state as input (returns to our caller)
   
    mov.l main, r7
    extu.w r14, r5
    mov.l @r15+, r5
    lds.l @r15+, pr
    jmp @r7
    mov.l @r15+, r14        ! Delay slot
   
_GlibAddinAplExecutionCheck:
    mov.l v_syscall, r2
    jmp @r2                 ! _GlibAddinAplExecutionCheck
    mov #0x29, r0           ! Delay slot
   
! Constants
    .align 4
main:
    .long _main
v_syscall:
    .long 0x80020070

v_datald:
    .long _datald
v_edata:
    .long _edata
v_sdata:
    .long _sdata
   
v_ram_bbss:
    .long _bbss
v_ram_ebss:
    .long _ebss


[parisse]

Le transfert d'un addin s'avere 2 fois plus lent que prevu, 15 a 20 minutes pour 3.5M. Et la, je suis bloqué, parce que l'addin n'apparait pas dans le menu et ne peut donc pas etre lancé, je soupconne qu'il y a une limite de taille ou que le header est mal ecrit lorsque la taille depasse 1M.

[parisse]

Apres tests, la limite d'un add-in semble etre de 2M (soit c'est une limite de l'OS, soit de mkg3a).
C'est peut-etre possible de degraisser le mamouth, mais passer de 3.5M a 2M ca va surement prendre du temps.

[critor]

Voilà, EigenMath pour Graph 90+E est annoncé, juste à temps pour le BAC 2018 :
viewtopic.php?t=21580&p=232509#p232509

Merci @parisse !

(par contre, en 2019 il sera bloqué par le mode examen, défavorisant ainsi les possesseurs de ce modèle )