À quand KhiCas pour TI-83 Premium CE / Edition Python ?

[parisse]

Pour la version de la toolchain c'est bien la dernière release ou bien la nightly (dans les releases github) ? Le sha de clang a l'air ok en tout cas, c'est deja ça.

j'ai fait au plus simple, install du package debian 11 après avoir ajouté le repository.

Il y a pas mal d'exemples (et presque tous avec des tests autos qui tournent en CI pour chaque commit) dans la toolchain, pour du stand-alone et des libs. Et puis la doc est normalement bien fournie.

Mais oui, pour le moment la toolchain est particulierement faite pour des programmes qui tournent en ram et qui subissent donc les contraintes habituelles. Mais les ressources externes en appvars c'est assez commun, et il y a plusieurs exemples dans la toolchain, par exemple pour la gestion de graphiques qui y sont stockés (tilemaps etc)

Problème de nouveau, si j'essaie de compiler examples/library_examples/graphx/tilemap_appvar (dont le nom est prometteur), j'ai l'erreur suivante:

Code: Select all

make
[compiling] src/main.c
src/main.c:5:10: fatal error: 'gfx/vargfx.h' file not found
#include "gfx/vargfx.h"
         ^~~~~~~~~~~~~~
1 error generated.
make: *** [/home/parisse/CEdev/meta/makefile.mk:338 : obj/src/main.c.bc] Erreur 1


Je n'ai pas trouvé trace de ce fichier vargfx.h dans l'arborescence de CEdev.

[parisse]

Bon il manque un appel à convimg à faire dans le répertoire gfx.

[Adriweb]

Pour la version de la toolchain c'est bien la dernière release ou bien la nightly (dans les releases github) ? Le sha de clang a l'air ok en tout cas, c'est deja ça.

j'ai fait au plus simple, install du package debian 11 après avoir ajouté le repository.

Je ne sais pas de quoi on parle alors - rien n'est officiel/à-jour à part les releases github, c'est marqué dans la doc ici : https://ce-programming.github.io/toolch ... arted.html
un "make version", dans un projet, doit donner "nightly" ou bien "11.0" (dont la principale nouveauté est le jeu de libs de gestion de l'USB)

Apres, autant sur mac et windows, les versions pré-buildée sont testées sans problème (et c'est même codesigné etc. pour mac), je ne sais pas ce que ca donne pour le prebuild Linux, je suppose que c'est OK si on a une version assez recente de la glibc etc...
Enfin bon, le problème ne semble pas être là, a priori.

-----

Bon il manque un appel à convimg à faire dans le répertoire gfx.

Non, c'est make gfx qu'il faut faire (avant le "make" normal"), quand il y a des ressources graphiques à générer, comme expliqué dans la doc ici

Mais du coup je conseille de faire un "make clean" pour rattraper le coup parce que je sais pas si un appel a la main a convimg a fait tout ce qu'il fallait (probablement que oui, mais on sait jamais)

Une evolution dans la toolchain+convimg est en train d'être faite, ces derniers temps, pour automatiser cette etape de "gfx" au besoin.

-----

Au passage, pour verifier que tout va bien du coté de la toolchain locale, il suffit de se placer dans le dossier CEdev/examples/ et faire un "make gfx" suivi de "make" (avec les -j qui vont bien pour paralleliser tout ca, comme d'hab).
Ca buildera tous les exemples (une soixantaine).

[Adriweb]

Et sinon, je reproduis en local le crash de clang sur cette fonction/fichier là.
Ca semble être juste les logical shift-right avec un signed 48bit, qui ne passent pas, le même problème apparaît ailleurs.

J'ai demandé sur le chat si c'était un problème connu.

[parisse]

Pour les appvars, je vois le code suivant

Code: Select all

unsigned char vargfx_init(void)
{
    unsigned int data, i;
    uint8_t appvar;

    appvar = ti_Open("vargfx", "r");
    if (appvar == 0)
    {
        return 0;
    }

    data = (unsigned int)ti_GetDataPtr(appvar) - (unsigned int)vargfx_appvar[0] + vargfx_HEADER_SIZE;
...


Donc on peut lire l'adresse en flash d'une zone de donnée. Mais on ne controle pas cette adresse au moment de la compilation, alors je ne vois pas bien comment on pourrait faire tourner un gros programme comme KhiCAS de cette manière (surtout que les adresses des opérateurs et fonctions usuelles de Xcas sont représentés dans les expressions symboliques par des pointeurs). Par contre j'imagine bien qu'on peut avoir des petites librairies dynamiques (dont le code est compilé avec -fPIC) en appelant les fonctions dedans à partir de leur adresse de base déterminée par ti_GetDataPtr et une liste d'offsets, mais c'est pas clair qu'on puisse dépasser la taille d'une variable pour une librairie. Il faudrait pouvoir mettre la main sur la facon dont l'interpreteur lua est linké pour voir s'il y a une autre méthode que je n'imagine pas.
Conclusion provisoire: KhiCAS ne me semble pas portable, seul un miniCAS me semble faisable, si possible en utilisant les structures de données TI, il faudrait regarder si le parser est accessible (conversion d'une chaine en un truc tokenisé à la manière de ce qui existe sur les 92, et bien sur non évalué automatiquement). Et aussi utiliser le shell de TI dont les routines ont l'air d'être exportées (philosophiquement, ca ressemblerait à ce que j'avais fait sur les HP48).

[Adriweb]

Par contre j'imagine bien qu'on peut avoir des petites librairies dynamiques

C'est comme ca (chargement+relocation avec libload ; cf. le flowchart ici pour les détails) que fonctionnent les libs de la toolchain, elles sont en appvars archivés en flash (dispos ici).

Et sinon, je reproduis en local le crash de clang sur cette fonction/fichier là.

Pour info, j'ai réussi à contourner le problème de compilation de MicroPython en mettant dans ports/ez80/mpconfigport.h, MICROPY_ENABLE_GC à 0 au lieu de 1, pour le moment.
Reste ensuite un problème de link avec un if HAS_LIBC mais ca c'est surement un ajustement par rapport à la toolchain et/ou au makefile du port, bref - en tout cas ca compile

Conclusion provisoire: KhiCAS ne me semble pas portable, seul un miniCAS me semble faisable, si possible en utilisant les structures de données TI, il faudrait regarder si le parser est accessible (conversion d'une chaine en un truc tokenisé à la manière de ce qui existe sur les 92, et bien sur non évalué automatiquement). Et aussi utiliser le shell de TI dont les routines ont l'air d'être exportées (philosophiquement, ca ressemblerait à ce que j'avais fait sur les HP48).

Oui, c'est ce qu'a fait Hamza.S dans son moteur CAS pour CE "CASymba".
Commandblockguy va finir de faire ce qu'il faut a un moment donner pour se hooker directement alpha+enter pour appeler le CAS sur le calcul/expression écrite sur le homescreen Pour le moment, faut passer le string en argument (enfin, en l'occurrence, via le Ans, que le main() va lire) et appeler le programme, comme on peut le voir sur les screenshots, c'est moins bien côté UX

[parisse]

Le flowchart n'est pas très clair, il indique des chargements en RAM, on ne sait pas s'il y a déchargement après. Sinon ça n'économise pas de RAM, ça économise de la flash en partageant du code entre divers programmes. Comment le code de la lib est-il appelé s'il n'est pas copié en RAM: est-ce qu'on a en RAM une table d'appels pour chaque lib archivée dans une appvar en flash, et le code généré va lire l'adresse de la fonction dans ces tables? Ca peut occuper de la place pour un gros projet qui serait scindé en plusieurs petites librairies (chacune dans une appvar), à raison de 3 octets par fonction C exportée.

Sinon en regardant la façon dont CASymba lit son argument par l'intermédiaire de Ans, le parseur de TI ne semble pas appelable en C, mauvaise nouvelle, ça veut dire qu'il faut inclure son propre parseur ou bien un éditeur d'expression.

[Adriweb]

Le fonctionnement de libload est, sans passer par le flowchart qui est potentiellement pas tout à fait à jour (dans les grandes lignes, si, je pense), visible via son code ASM eZ80 si on parle ce langage
On peut y voir, notamment "; notes: all code is location independent; no need to relocate to absolute address. keeping in archive is safe."
Mais clairement pour toute question il va falloir demander à MateoC, vu que c'est lui qui l'a fait.
Pour autant que je sache, oui, rien n'est résident en ram après (ça leakerait, et on en a déjà pas assez...), et le but et de partager les dépendances au lieu de les dupliquer ou pire avoir du code statique alors que la mémoire est faible.

Et sinon, "peu" de choses de l'OS/boot sont exportées en C (vu que la majorité du code de TI reste de l'ASM, et certaines nouvelles parties, comme des apps, en C), on a déjà pas mal de chance que ca soit le cas pour l'actuel, et c'est probablement le minimum que TI ait fait pour satisfaire ses propres besoins... et ca ne va pas s'améliorer.
Donc, oui, il faut faire son propre parseur d'expression.

____

Voila sinon mon petit patch qui permet de compiler et linker micropython (ca resulte en un firmware.bin de presque 150 Ko)

[parisse]

Le fonctionnement de libload est, sans passer par le flowchart qui est potentiellement pas tout à fait à jour (dans les grandes lignes, si, je pense), visible via son code ASM eZ80 si on parle ce langage
On peut y voir, notamment "; notes: all code is location independent; no need to relocate to absolute address. keeping in archive is safe."
Mais clairement pour toute question il va falloir demander à MateoC, vu que c'est lui qui l'a fait.

Je reste inquiet, ligne 363 et plus loin on lit

Code: Select all

        ld   hl, ti.userMem      ; this is where programs are loaded to
   ld   de, (ti.asm_prgm_size)
   add   hl, de         ; hl->end of program+libaries
   ex   de, hl         ; de->location to load to

   ld   (ramlocation), de   ; save this pointer

   res   keep_in_arc, (iy + LIB_FLAGS)
   ld   hl, (arclocation)   ; hl->start of library code in archive
   ld   de, (loaded_size)
   add   hl, de         ; hl->start of library relocation table
   ld   (reloc_tbl_ptr), hl   ; store this
   ld   de, (end_reloc_tbl)
   call   ti.CpHLDE      ; check and see if they match -- if so, this library is going to remain in the archive
   jr   nz, need_to_load_lib
   ld   hl, (arclocation)
   ld   (ramlocation), hl   ; okay, not a ram location, but it's use is still the same
   set   keep_in_arc, (iy + LIB_FLAGS)

need_to_load_lib:
...


Donc si j'ai bien compris, il charge certaines librairies en RAM après le programme lui-même, les need_to_load_lib, qui sont celles pour lesquelles il y a des dépendances à recalculer (et ça expliquerait la possibilité d'une erreur mémoire éventuelle). Les autres libs peuvent rester en archive. Si on veut pouvoir conserver toutes les libs en archive, il faudrait modifier les librairies qui ont des dépendances et les réarchiver modifiées.

Si j'ai bien compris, pour un gros projet, il faut arriver à mettre en archive des morceaux de librairies self-contained de 60K max, sinon dès qu'il y a une dépendance, la lib est mise en RAM. Si tu a une taille de micropython à 150K, il faudrait arriver à découper en 3 sous-libraires, chacune indépendant des deux autres, pas sur que ce soit possible, ce qui expliquerait que ça soit resté en plan depuis octobre 2021. Pour KhiCAS, c'est sans espoir.

[parisse]

Sur le parseur TI, même si leur code est principalement en assembleur, il doit quand même y avoir quelque part une fonction assembleur qui prend en entrée une chaine normale et renvoie une chaine tokenisée.
Et pour micropython, s'ils avaient à leur disposition la toolchain cedev, ils devraient pouvoir s'affranchir des limitations de taille de code à 60K que nous avons, ils peuvent utiliser une adresse fixe en flash pour une taille de code arbitrairement longue (enfin limitée seulement par la taille de la flash). Alors il y a peut-être une autre raison qui explique la complexité de leur solution technique.