parisse a écrit: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.
Mon port de Lua il y a quelques années faisait dans les 100 KB, et à l'époque deja, la toolchain gérer le split automatique en loader+appvars, et ca marchait sans problème (même si je ne sais pas comment plus que ca), donc il y a de l'espoir quand même.
La, ca donne ca:
- Code: Tout sélectionner
[warning] Input too large; split across 2 appvars...
[success] build/MPY.8xp.0.8xv, 65308 bytes.
[success] build/MPY.8xp.1.8xv, 14731 bytes.
[success] build/MPY.8xp, 307 bytes. (compressed 46.86%)
Mais bon, dès le
mp_init() je me prends un null ptr deref, y'a encore du boulot, même si c'est probablement du au fait que le GC a été désactivé à la compil 
Je vais essayer de voir ce que j'arrive à faire (genre, executer quelques lignes de python...
)parisse a écrit: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.
Je ne suis pas sur qu'on parle de la même chose, mais quand on tape une expression sur le homescreen, c'est deja des tokens qui sont utilisés (d'où le besoin de le detokenizer, ou bien les traiter directement, dans un programme tiers).
Pour la liste des tokens, cf ici: https://github.com/TI-Planet/z80_basic_ ... tokens.csv et pour un detokenizer, j'ai fait une lib (notamment utilisé par CEmu ou sur tiplanet dans les archives etc) ici : https://github.com/adriweb/tivars_lib_c ... d.cpp#L101
Si on parle de "tokens" un peu plus haut niveau, genre un arbre/AST, je ne suis pas sur que ce soit accessible, voire si c'est fait comme ca tout court dans l'OS. Donc en effet les programmes CE qui font des maths avec un moteur custom (il y en a quelques uns, PineappleCAS, CASymba...), c'est fait à la main.
parisse a écrit: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.
En 2018, la toolchain CE n'était pas aussi avancée, et TI ne se basait/base que sur les outils officiels de Zilog, donc mauvais compilateur, buggé, ancien, et qui ne gère que du vieux C89. Côté communauté, certes il y a eu des travaux avec LLVM pendant longtemps, mais officiellement ca n'a été releasé (et donc la dépendance sur les outils de Zilog complètement enlevée) qu'à la fin 2020.
Mais c'est sûr que TI a la possibilité de faire des choses beaucoup plus interessantes que nous niveau agencement de la mémoire s'ils en avaient vraiment besoin, pour des grosses APPs etc.
Apres, en étant réaliste, il est fort probable que le circuitpython sur le chip ARM choisi par TI tourne de manière plus performante que sur l'eZ80, mais bon, on verra bien quand on fera des benchmarks...
Par ailleurs, surtout avec TI, il ne faut vraiment pas oublier le syndrome du Not Invented Here, malheureusement...
C'est sûr que ça serait génial si TI se mettait à utiliser et améliorer la toolchain CE (partie compilateur, surtout), mais à mon avis ca n'arrivera jamais.
