Outils communautaires de programmation on-calc
Posté le 10/01/2025 13:58
Dans le topic
Les projets de Planète Casio pour 2025 Sabercat a relancé l'idée d'avoir des bons outils de programmation on-calc (en plus de la compatibilité 35+E II mais ça ça ira dans un autre topic peut-être).
Je liste ici les messages de cette discussion avec un résumé.
Messages principaux :
#198728,
#198735,
#198761,
#198763,
#198767,
#198773,
#198774,
#198775,
#198777,
#198786,
#198788
Ce qu'on pourrait viser comme langages :
- Python : ok, PythonExtra
- LuaFX : à porter
- Malical : à porter — y a-t-il de la demande ?
- Quelque chose pour coder des add-ins (C ? Autre ?)
- Basic : il y a déjà C.Basic (intégration sans doute impossible)
Ce qu'on peut viser comme éditeur :
- A priori plutôt un éditeur séparé plutôt qu'un éditeur embarqué dans chaque appli
- Kiwi Text : mais copyright, pas de sources, apparemment pas complètement stable
- Micropy : existe déjà et marche, toutefois basé sur le PrizmSDK, et le support langage reste à coder
- Nouveau programme à base de gint + JustUI comme PythonExtra ou text-viewer
Sabercat a mentionné qu'il serait bien de pouvoir coder des add-ins sur la calto. Je suis d'accord. Par contre, avoir un compilateur + linker sur la calto c'est trèèès ambitieux et porter les outils GNU c'est pas possible. Personnellement, je pense qu'il serait plus intelligent de coder des add-ins sur la calto
dans un autre langage que le C. Je sais pas ce que vous en pensez...
Citer : Posté le 10/01/2025 18:31 | #
J'ai testé d'utiliser monochromlib sur LUAFX (SH4) ça fonctionne mais il reste plein de bugs au niveau du lancement d'un programme LUA ou LC
(sur g35eii)
Citer : Posté le 10/01/2025 18:45 | #
Il serait sans doute possible de faire des addins en ASM, et avec un macro asm comme gas.
Par contre oui pour le C ça me paraît très difficile, au sens qu'il n'y a pas de compilateur SH pouvant rentrer sur nos caltos (gcc fait autour de 300-400Mo, et celui de Renesas doit faire <40Mo au pif mais est propriétaire). Il faudrait donc faire un backend pour le tiny c compiler ou autres.
Après il y avait Mb88 qui avait un projet de lisp, et ça doit être possible de porter un interpréteur simple.
Bref, je vois pas grand chose d'autre qui pourrait être possible, pour la plupart des langages interprétés les interpréteurs sont trop gros, et pour les langages compilés ils n'ont pas de backend SH (ou alors c'est gcc)
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 10/01/2025 23:07 | #
Qu'est ce qui fait la taille de gcc ? Ca m'étonnerait qu'il y ai 400 millions de lignes d'assembleur dans gcc... Est ce que ce serai pas possible de faire un petit compilateur from scratch en quelques centaines de Ko si il est bien spécialisé sur le C et SH4 ?
Citer : Posté le 10/01/2025 23:11 | #
gcc est gros parce que y'a plein de libs, et beaucoup, beaucoup de logique. 400 Mo c'est une surestimation, mais y'a tant de dépendances que c'est vraiment pas la peine d'y penser.
Ce qu'on peut faire par contre, c'est coder un compilateur ou un semi-compilateur qui génère du bytecode et intègre l'interpréteur dans le g3a. Mais coder un compilateur C faut le vouloir... vous avez peut-être vu tcc mais Bellard est pas tout à fait sur le même plan d'existence que nous.
Personnellement je pensais plus à coder un compilateur on-calc pour du Lua ou du Basic ou un truc dans ce genre. Malical c'était un peu ça à l'époque aussi si ma mémoire est bonne : un langage inventé pour la calto (mais interprété, je crois ?).
Citer : Posté le 11/01/2025 01:03 | #
400 Mo c'est une surestimation
$ du -sh fxsdk/sysroot/
244M fxsdk/sysroot/
A peine --'
Personnellement je pensais plus à coder un compilateur on-calc pour du Lua ou du Basic ou un truc dans ce genre. Malical c'était un peu ça à l'époque aussi si ma mémoire est bonne : un langage inventé pour la calto (mais interprété, je crois ?).
Ça serait assez cool, mais c'est quand même un très gros projet. Mais bon, tu me diras, c'est ton boulot les compilos
Le BASIC reste assez pourri dans la plupart de ses itérations par contre, que ça soit Casio Basic, Microsoft Basic, ou VBA. Le Lua ça passe mais une version plus bas niveau serait pas mal, puisque sinon autant faire un LuaFX 2.0 ou LuaCG en portant l'interpréteur
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 11/01/2025 08:12 | #
J'ai quand même de gros doutes sur l'intérêt pratique d'un tel projet vs le travail de développement: qui utiliserait un compilateur d'addins sur calculatrice? Même parmi la poignée de passionnés qui interviennent sur planete-casio ou cemetech. Les passionnés ici ne programment pas sur calc mais sur ordi. Un signe de cela c'est que jusqu'à maintenant PythonExtra ne fournit pas d'environnement de dev oncalc, c'est un addin d'exécution de code créé ailleurs, et il a fallu que je cite explicitement Micropy pour qu'il apparaisse comme un candidat d'éditeur.
Même dans les années 1990, où on n'avait pas d'ordi portables en concurrence avec les calculatrices, il y avait peu de passionés qui programmaient oncalc sur les hp48 (on pouvait programmer en rpl système et en assembleur, c'est l'équivalent des addins aujourd'hui), le développement se faisait sur PC.
La programmation sur calculatrices a aujourd'hui uniquement un intérêt scolaire à mon avis, car cela permet d'intégrer dans un cours un petit exo d'algorithmique de manière souple. Et c'est très peu utilisé en pratique, à part par une poignée de profs de maths passionnés de calculatrices. Python a principalement servi d'argument marketing à Numworks pour se faire connaitre, et aux autres constructeurs pour diminuer le recours à la revente de calculatrices d'occasion.
Citer : Posté le 11/01/2025 08:35 | #
J'ajoute qu'à mon sens, un grand projet qui serait plus utile ce serait un OS alternatif sur la Math+ (éventuellement avec dual boot puisque Casio n'utilise pas toute la flash), un peu comme ExistOS pour la hp39 (https://github.com/ExistOS-Team).
Citer : Posté le 11/01/2025 11:18 | #
oui, le malical est interpreté
Mais entre le C.Basic et python ya des options plus completes qui rivalise (voire gagne) en rapidité
Citer : Posté le 12/01/2025 22:43 | #
Sinon, pour avoir un truc plus accessible, on pourrait faire un outil de dev à la Scratch comme sur fx92 + mais qui compilerait en add-in.
Je trouve ca dommage d'avoir un interpreter car l'avantage des add-ins sur le Python ou le basic c'est quand même la vitesse d'exécution.
Citer : Posté le 13/01/2025 13:00 | #
Les passionnés ici ne programment pas sur calc mais sur ordi
Et personnellement je le regrette ! Je pense que j'avais plus de fun à coder en Basic quand j'étais petit en moyenne
---
Je pense qu'à ce stade culturellement sur Planète Casio on aime bien faire des add-ins, mais c'est clair que c'est chiant à faire : il faut un SDK, faut savoir coder en C, et si vous avez le malheur d'essayer d'utiliser le combo gint/fxSDK faut du Linux ou du WSL et encore des embrouilles en plus.
Ce serait cool d'avoir un middle ground où on peut faire des add-ins, même pas ultra rapides, sur la calto, pour attirer des utilisateurs qui savent pas déjà faire tous les trucs compliqués sur le PC. Ça éliminerait une des difficultés (le setup ordinateur). L'autre difficulté est le langage : le C, qui est dur à apprendre et aussi dur à compiler sur la calto
Faire du Basic ou du Python intersecte avec C.Basic / Python officiel / PythonExtra et risque de pas avoir accès aux mêmes fonctions/modules, ce qui est tendu, mais réutilise des outils de programmation déjà connus. Faire autre chose nécessite d'apprendre un autre langage mais y'a pas d'ambiguïté possible.
Je me laisse penser qu'un mini-langage qui soit pas trop verbeux (= facile à taper) accompagné d'un système pour automatiquement intégrer textes, images, etc. en ressources dans une appli développée sur la calto serait intéressant. Limite style PICO-8
Citer : Posté le 13/01/2025 17:08 | #
Pour avoir testé Pico8 il y a pas très longtemps, c'est clair que ce serait un format idéal sur calculatrice. Bon en gros c'est du lua light (subset). On aurait un truc dont une base serait déjà présente avec luafx.
Pour l'anecdote, les tns de la nspire permettent d'intégrer du lua et y'a vraiment des trucs cools qui sont faits avec.
Citer : Posté le 13/01/2025 17:24 | #
Les passionnés ici ne programment pas sur calc mais sur ordi
Et personnellement je le regrette ! Je pense que j'avais plus de fun à coder en Basic quand j'étais petit en moyenne
J'imagine qu'ici on est beaucoup à avoir commencé à programmer sur calculatrice au collège (à mon époque c'était proche de l'assembleur d'ailleurs...) et forcément on est un peu nostalgique! Mais j'ai l'impression que ce qui compte surtout à ce niveau, c'est d'avoir un langage facile à prendre en main, je ne crois pas que la rapidité soit un critère déterminant (je peux me tromper bien sur, chacun a une trajectoire perso différente). A ce titre, la suppression du basic sur la math+ est certainement une perte, malheureusement les personnes qui décident n'ont pas du tout les memes priorités, les décisions prises dans un but purement économiques vont à l'encontre des besoins spécifiques des très bons élèves susceptibles d'etre intéressés par la programmation (ou par les maths d'ailleurs) parce qu'il y en a peu. Au lieu de contribuer à élever le niveau, il est plus rentable de niveler par le bas.
Citer : Posté le 13/01/2025 22:45 | #
Je suis d'accord que la vitesse n'est probablement pas critique. Cela dit l'écart entre ce qu'on peut faire avec Basic/Python et des add-ins est très large... y'a qu'à voir les jeux qu'on galère à écrire fluides avec Critor en Python qui se font à l'arrache en C sans problème. Sûrement il doit y avoir un juste milieu pour faire des programmes dans la même "catégorie" que des add-ins et qui est plus accessible
Lua est un peut-être un bon compromis : c'est un langage tout simple, vaguement utile à connaître, et ça intersecterait LuaFX en effet.
Citer : Posté le 14/01/2025 00:37 | #
It's true that programming on the PC is better, so I love programming on the calculator when I'm on the bus or metro or sitting and waiting since I lose a couple of hours a week like this. It's better than mindlessly scrolling on my phone which is what I would do otherwise.
I'm working on a C program that implements a small subset of Python that I hope to fit into 16K of flash on an MSP430 microcontroller (MicroPython takes 256K). It excludes some of the things I can live without if I have to like classes and floating point. Rather than calling C code from Python, this would call Python code from C as needed. The Python initialization function takes a chunk of memory to use which the C program can reuse for other things after the Python code runs, so no need to rely on malloc. The bytecode can be compiled on the PC and embedded as data in the C program. The most useful feature, though, is calling the underlying Python functions for things like lists and dicts directly from C which avoids interpretation overhead. I think the binary size will also be pretty small if I get the linker to only include the underlying functions that are used by the C program and exclude the compiler and interpreter when they aren't needed.
One of my plans with all of this is to implement a 6502 assembler and emulator I can run on my CG50 to develop the firmware for a 6502 calculator I've been working on for a few years (Emulator here). I built a combined assembler/emulator in Python and was very surprised how much easier it is when most of the parsing relies on tables stored in spreadsheets processed by a relatively small amount of Python code (The assembler runs in browser here. Blog post here.) It's easy to have the spreadsheet generate a single column combining all the tables in the spreadsheet formulated as valid Python lists and dicts that gets pasted into a tables.py file any time the spreadsheet is modified. The assembler needs to handle not just simple expressions like LDA 0x42AF but also more complicated things like LDA lo(BASE+(VAL<<4)&~MASK|hi(OFFSET)) as well as differentiating LDA (1+2+3) (which is indirect addressing) and LDA (1+2)+3 which despite the parentheses is direct addressing.
Parsing C code is not much more complicated than the assembly parsing above which is relatively straightforward once you have the right data structures. On the other hand, the C program I'm working on now to compile Python to bytecode could be adapted to compile C to bytecode since Python syntax is just as complicated as C syntax. Back when I was doing a lot of TI-89 programming, I briefly ran a C compiler on the calculator that compiled to machine code but lost interest since it's too easy to lock up the machine and have to hard reset when you have a bug. The advantage of bytecode is that you can implement protections in the interpreter that catch out of bound memory accesses and periodically monitor for an ON key press to stop the program if it gets stuck. In theory, it should be impossible to crash the calculator running a C program in the interpreter. Another idea is to design each bytecode so that its machine code can be copied directly into memory. This will still execute relatively slowly if no optimization was done but at least it eliminates the overhead of interpreting the tokens. I really like the idea of writing and testing C code on the calculator then moving it to the PC piece by piece to be compiled to machine code once it's done. The loss in speed probably won't matter much during development since the final result is entirely compiled on the PC.
The last idea, which appeals to me less than the others, is implementing a stack-based language like Forth. The UserRPL programming mentioned above and the SystemRPL that underlies that on the HP-48, 49, and 50 calculators share a lot in common with Forth. Many people turn to Forth when a machine is relatively low-powered but needs to compile for itself since it requires extremely minimal resources. There is very little syntax to account for which is an advantage when implementing the compiler, but in my opinion it's a real headache when trying to read your own code or anyone else's, hence the name "write-only code." Running Forth bytecode would be just as slow as C bytecode and maybe even slower because of the extra operations needed to manipulate the stack. There are a handful of optimizing Forth compilers including Mecrisp which generates optimized machine code for a couple of microcontrollers including the Cortex M0 which I think is somewhat equivalent to the SH4. The author of Mecrisp, Mathias, is very friendly and accessible on IRC. He doesn't plan to add support for any more processors, so we won't be getting an SH4 port, but it's noteworthy that the Mecrisp binary for Cortex M0 (which runs on Cortex M0 not on a PC) is 20K yet produces code that's only 2-3x slower than C compiled on a PC. This is very impressive considering unoptimized Forth machine code can easily be 10x slower than compiled C depending on the architecture.