Forum TI-Planet.org

Oui probablement (brew install ninja?)
Et de toute façon llvm eZ80 n’est pas encore prêt (jacobly n’a plus travaillé dessus depuis quelques temps, il attend entre autre le GlobalISel). C’est pratique pour quelques trucs de base en C n’utilisant pas les flottants. Et cote C++, en gros c’est pour tester le langage en lui même, il. Y a pas de stdlib ou autre (j’ai fait avec succès quelques essais de microstdlib mais bon, ça remplissait déjà un tiers de la taille Max d’un programme, pour seulement 3 types )

Je peux me debrouiller sans support de la libstdc++, il me faut seulement le support du langage C++. Par contre, en parcourant la doc, je realise que la taille maximale des programmes semble etre de 64K. Y-a-t-il une raison forte qui empeche d'aller plus loin alors que je lis par ailleurs qu'il y a 3M de flash utilisable? Bon, de toutes facons, avec des entiers sur 24 bits et des double sur 32 bits, ca aurait necessite sans doute encore plus de boulot que pour porter Giac sur Casio, il sera sans doute plus raisonnable d'attendre que TI passe a une architecture moins archaique...

Y-a-t-il une raison forte qui empeche d'aller plus loin alors que je lis par ailleurs qu'il y a 3M de flash utilisable?

En faisant des FlashApps, on peut théoriquement aller plus loin que la limite des 64 KB imposée aux programmes ASM, mais... ces FlashApps, il faut les installer de manière spéciale, puisque TI ne fournit pas de moyen officiel de faire des FlashApps TI-eZ80. Ca fait des années qu'on le leur a réclamé, sans succès.

ca aurait necessite sans doute encore plus de boulot que pour porter Giac sur Casio, il sera sans doute plus raisonnable d'attendre que TI passe a une architecture moins archaique...

Je le pense aussi.

Non mais pour le moment c’est mort et enterré hein, sur CE ^^
Et puis il n’y a que 4 Ko de stack et 69 Ko de heap.
On peut « tricher » niveau taille Max en passant par un loader d’appvar (Convhex le gère automatiquement ou presque, on lui passe le .hex final trop gros, et avec un flag il fabrique tout seul les appvar et le loader), c’est ce que j’avais du faire pour mon portage de minilua, qui faisait en tout 110 Ko ou un truc du genre. Ce fut déjà pas évident.
Sinon, des flash apps oui, mais on reporte le problème. Car il faut bien les « installer » via un programme, pour nous.

Niveau llvm sinon, c’est absolument pas utilisable en l’état, il y a pas mal de cas pas bien gérés et qui font donc « crashed » le compilo (certes a l’époque Oiram a réussi à être compilé en entier, et forcément llvm produit du code bien meilleur que ZDS, mais en fin de compte, du code C ansi utilisant des entiers uniquement, c’est pas complexe.)
Quand je serai rentré chez moi je linkerai mon projet partage de test CPP sur le Project Builder, ça permettra de voir l’avancée des choses et bidouiller avec llvm direcetement en ligne sans avoir à l’installer (dans un premier temps c’est pas mal)

Il y a quelques semaines, Jacobly a repris pour de bon le boulot sur le backend z80/eZ80 LLVM
Et en fait, il a réécrit entièrement la partie de sélection d'instructions pour profiter du nouveau "GlobalISel" de LLVM, bien plus efficace et simple pour faire ses backends que celui utilisé avant (DAGIsel).

Et du coup, en quelques semaines, ce travail porte déjà ses fruits, avec la toolchain communautaire qui builde entièrement, ainsi que ses exemples. D'autres programmes plus complexes, comme Oiram, commencent à fonctionner aussi
Des bugs sont corrigés chaque jour, et des améliorations apportées, donc ne vous attendez pas à quelque chose de stable pour le moment... mais ça avance vite !
Toujours est-il que vous pouvez suivre l'évolution de l'intégration de LLVM dans la toolchain par ici : https://github.com/CE-Programming/toolchain/tree/llvm

Instructions de build (attention, ça peut être long, mais c'est normal surtout la première fois que le build est fait) : https://github.com/jacobly0/llvm-project/wiki (vous noterez que ce n'est plus le même repo que la dernière fois - en effet entre temps LLVM est passé à un monorepo git, ce qui facilite par ailleurs bien le process)

On va bientôt pouvoir dire au revoir aux outils de Zilog et enfin avoir une toolchain moderne basés sur des outils libres et puissants !
(Quand ça sera prêt, vous n'aurez pas à builder ça vous même, on vous proposera une version déjà pré-faite en téléchargement)

Pour ma part, je compte refaire la partie de gestion des toolchain ez80 du PB pour pouvoir avoir ce tout dernier backend LLVM ainsi que la derniere version de la toolchain stable actuellement releasée.

Du coup, on pourrait peut-etre compiler un jour une version strippee de KhiCAS sur la 83?

Compiler, peut-être, même si pour cela, il faudra certainement étendre la lib standard.
Après, il faudra produire un binaire final, et le rendre installable et lançable sur la machine... ça sera une version plus complexe de ce que Cesium fait pour pouvoir s'installer comme FlashApp alors que TI ne permet pas de faire des FlashApps communautaires. Au moins, maintenant que l'USB est à peu près compris, on pourrait même gérer nous-mêmes le transfert et l'écriture en Flash, avec plus ou moins de coopération de l'OS.
Mais dans tous les cas, il faudra faire avec des limitations de taille de RAM disponible similaires à celles des machines NumWorks: le tas contigu utilisé par la toolchain communautaire et ses libs fait moins de 70 KB, de mémoire...
Une chose me semble sûre, TI n'apprécierait pas du tout qu'on puisse installer un CAS sur une TI-eZ80, même si sait techniquement contrôler la disponibilité en mode examen

D'apres mes mesures, le tas reellement utilisable pour KhiCAS sur la Numworks fait un peu moins de 50K (c'est vrai que si ca depasse un peu, on mord sur la fin de la stack qui est contigu ce qui rajoute un peu de place). 70K ce n'est pas ideal, mais ca permettrait quand meme de faire des choses, a condition que la vitesse du processeur ne soit pas trop lente.
Apres, c'est sur que je n'irai pas me battre tout seul contre les protections de l'OS de la TI, mais s'il y a un espoir raisonnable et du support de la communaute, ca peut valoir le coup. Il faut bien lutter contre les constructeurs de calculatrice qui continuent a nous vendre des produits volontairement brides, ainsi que contre les obscurantistes.

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

L'eZ80 de la 83PCE EP est moins bridé par la lenteur de la Flash et la RAM que celui des 83PCE / 84+CE / 84+CE-T précédentes, mais l'eZ80 reste une ISA 8 bits avec des registres de 16/24 bits et des instructions très limitées. La puissance brute sera donc très en-dessous de celle d'ARM 32 bits à quelques dizaines de MHz, 100 MHz comme le processeur des N0100, etc.
Et j'oubliais la très faible taille de la stack, en effet. Sur TI-68k, on peut compter sur une dizaine de KB en pratique (2 buffers écran de 3840 octets passent sans problème mais 3 buffers sont proches de la limite)... c'est déjà plus confortable !