Forum TI-Planet.org

Et toujours pas possible de prendre le contrôle de l'ARM de la TI-83 Premium CE Edition Python ?

Si, mais si j'ai bien compris, on ne peut pas faire tout ce qu'on veut a cause de l'archi matérielle, par exemple on ne peut pas faire pointer la VRAM dessus par exemple, c'est indirect. Je ne sais pas s'il y a vraiment eu de PoC de code tiers tournant dessus, en tout cas c'est faisable sans trop de problème selon Jacobly. Mais pour le moment (après une période sur l'USB avec Mateo, sur quoi il va revenir par la suite je suppose ), il est occupé sur LLVM en lui-même, ce qui va être bien plus utile à plus grande échelle.

Bref, techniquement, avec beaucoup d'huile de coude, en combinant des astuces de déplacement de stack (?), d'utilisation de vram+cursrorMemory+sha+... comme zones mémoires rapides additionnelles, + USB, + ARM, il est surement possible de faire des choses. Mais c'est beaucoup trop de boulot pour le moment je pense.

L'avantage indirect d'arriver à coder des choses sur l'ARM c'est que ça serait de facto disponible uniquement sur 83PCE EP, et TI France n'a pas besoin de combattre le CAS sur non-CAS, puisqu'en France le CAS est autorisé... (et pas sûr qu'ils considèrent vraiment ça comme un manque à gagner vis a vis d'un achat d'une Nspire CX II-T CAS, on n'est quand meme pas sûr une égalité...)

Ah oui et j'oubliais : rien n'empêche de tester l'état actuel de LLVM (enfin, "clang -target ez80", déjà) sur des gros bouts de codes, et voir ce que ça donne, sans parler de link ou autre.
Peut-être que ça révèlera des problèmes de compilation (des crashs de clang, déjà, c'est simple à voir ) que jacobly pourra corriger.

Avec ses 32 KB de RAM et 256 KB de Flash propres, l'ARM embarqué est bien trop limité pour tourner giac, et il n'est pas vraiment fait pour accéder au reste de la mémoire.

Oui, il serait potentiellement utilisable à des fins de calculs/traitement bien spécifique sur du code assez commun qui serait trop lent sur eZ80. Mais ça reste faiblard aussi en effet.

Je ne vois pas pourquoi tu t'inquiètes pour le CAS @Adriweb.

Le CAS est tout autant disponible sur les Casio Graph 35/75/85/90/95 et fx-9750GII/9860G / fx-CG10/20/50 pour nos voisins européens anti-CAS, et Casio n'a pas l'air d'en faire une maladie.

Et puis en cherchant bien, tu peux déjà trouver des bricoles apparentées à du CAS pour TI-82/83/84, et sans doute largement suffisantes avant les études supérieures pour le lycéen moyen.

Soit les pays concernés imposent le reset / mode examen, soit ils acceptent les programmes vu que ce sont des machines programmables, y compris les programmes qui implémentent plus ou moins bien des fonctionnalités CAS.

C'est le contexte haut de gamme TI-Nspire / HP Prime qui est différent, avec l'argument commercial du no-CAS qui est je suppose mis en avant par les constructeurs. Soit via le mode examen qui désactive cette fonctionnalité (HP Prime et TI-Nspire CX II CAS), soit via des modèles en édition spécifique non-CAS (TI-Nspire). Un CAS sur une TI-Nspire alors qu'elle est vendue exprès garantie comme non-CAS, là oui ça fait râler je suppose.

Et puis l'offload vers un périphérique de calcul externe, puis la récupération du résultat, seraient loin d'être gratuites...

@critor : justement, je ne m'en inquiète pas, au contraire Mais pour TI US, je ne sais pas ce qu'ils penseraient d'un vrai moteur CAS sur la série des z80/eZ80 - car ça serait une première, que je sache. On sait déjà qu'ils ont enlevé l'AsmPrgm pour une simple idée venus de profs américains qu'il serait possible de faire des choses capable d'aider à la triche. Alors avoir directement un moteur CAS là où ce n'est pas autorisé, ça va être simple de trouver des profs américains (surtout) qui ne seraient pas contents. Mais bref, en France surtout, pas de pb.
Par ailleurs, l'ARM n'est pas reset (il me semble ?) par le mode examen, donc ça pourrait peut être être abusé par des tricheurs, je suppose. Donc il faudrait faire gaffe à ce niveau là (m'enfin rien que d'évoquer ça ici peut-être qu'à Dallas ils sont déjà en train de se demander comment reset l'ARM a chaque reboot en parallele de la vérification de l'OS CE, ce qui rajoutera des secondes perdues lors de l'initialisation de l'app python... )

Adriweb a écrit:Ne pas oublier que parmi les 69k de heap contiguës, le segment de BSS y est compris :/
Aussi.... le stack fait 4K. C'est peu

J'ai 18K de bss et 1.5K de data pour giac sur la Numworks, ca laisserait 50K de tas. Par contre la stack a 4K, c'est clairement insuffisant.

Je ressuscite ce topic pour signaler que les tests de la toolchain passent désormais tous avec la branche LLVM: https://travis-ci.org/github/CE-Program ... /667963572