Script qui refuse de s’exécuter sur la Numworks N0100

[cent20]

Puisque l'utilisation d'un tas Python de 32 KB change le comportement... allons un peu plus loin ?
En pièce jointe, un build avec un tas de 40 KB

Jusque là j'ai tout compris !

et un nombre maximum de noeuds réduit (3/4 de la valeur d'origine mentionnée plus haut, et sizeof(TreeNode) == 12, donc ça laisse 2048 noeuds). Comme le deuxième changement réduit davantage la RAM consommée que le premier ne l'augmente, le tas pour malloc (section .heap) est plus grand, 0xEB64 octets maintenant.
Je me demande si on ne pourrait pas réduire la taille de la pile (section .stack), aussi... sauf utilisation de grosses variables locales, 32 KB (0x7FF8) est élevé alors que le tas ne fait même pas le double de ça.

sizeof(TreeNode) == 12 parce qu'il y a deux int16_t et un int8_t, et un pointeur vers la vtable, donc du padding. De toute façon, la taille doit être multiple de 4 pour faciliter les copies mémoire, c'est également marqué en commentaire.

J'ai tout compris, bien évidemment.

Quelques questions en rapport avec le .bin :

Tu le génère depuis une machine sous quel OS ?
Tu fais comment pour attraper le .bin ?
Le mien sous debian 10 avec interface graphique (on ne rigole pas) s'efface immédiatement après l'echec du flashage, car il serait trop gros pour être envoyé (forcement 8mo>1mo), bon après aussi je ne savais pas qu'il avait été généré par défaut pour la N0110, ce n'est pas marqué dans la doc ni qu'il faut rajouter des paramètres pour compiler )

[jean-baptiste boric]

Je me demande si on ne pourrait pas réduire la taille de la pile (section .stack), aussi... sauf utilisation de grosses variables locales, 32 KB (0x7FF8) est élevé alors que le tas ne fait même pas le double de ça.

Je n'ai pas étudié la question en détail, mais le DFU de NumWorks s'exécute dans le bas de la pile afin de pouvoir mettre à jour le firmware sans scier sa propre branche au passage. Un autre cas qui me vient en tête est la décompression des images avec un buffer d'environ 8 KiB sur la pile (image_view.cpp).

[parisse]

Prudence quand meme avec la stack, il peut y avoir des alloca.
Reste quand meme qu'etre oblige d'optimiser la taille d'un script est peut-etre pas ideal d'un point de vue pedagogique...

[Lionel Debroux]

Tu le génère depuis une machine sous quel OS ?

Debian sid/unstable amd64, dont le gros deviendra Debian 11 dans plus de 2 ans. Debian 10 va très bien pour faire ce que tu veux. Moi aussi, j'ai une interface graphique

Tu fais comment pour attraper le .bin ?

Depuis la racine du clone d'epsilon:

Code: Select all

make MODEL=n0100
make build/device/n0100/epsilon.bin

et je récupère ce dernier fichier pour l'uploader ici.

Quant à l'usage de la pile: tout à l'heure, j'ai justement ajouté -Wstack-usage=512 -Wframe-larger-than=512 dans CXXFLAGS de scripts/default.mak, et j'ai eu zéro warnings. Mais ça m'étonne, moi aussi... le buffer de 8000 octets dans image_view.cpp aurait dû être reporté, en effet.

[critor]

Voilà, l'exploit est annoncé en page d'accueil, vu qu'il change la donne en cette période de rentrée/acquisitions :
viewtopic.php?p=245130#p245130

J'ai normalement crédité tous les acteurs, dites-moi si il y a des modifications à apporter.

Merci.

[cent20]

Depuis la racine du clone d'epsilon:

Code: Select all

make MODEL=n0100
make build/device/n0100/epsilon.bin

et je récupère ce dernier fichier pour l'uploader ici.

Merci beaucoup. Avec ça je peux compiler directement dans ma machine virtuelle et distribuer les .bin aux élèves. ça suffira pour commencer. Surtout que mes élèves en 1ère NSI auront cette année une TI 83 prenium sans python ni le module externe , alors eux les .bin ils s'en moqueront totalement et le python on le fera sur PC mais ça sera moins ludique ...

[cent20]

Je profite du lancement d'un démineur, , un petit script de 3.09ko qui refuse de tourner sur les 16ko pour relancer ce topic.

Depuis le 8 septembre dernier, 5 mois ce sont écoulés nous avons bien progressé à python.
(nous étions parti de 0 en juillet 2019 !)

Et du coup le script de 6ko que l'on pensait incompressible fait désormais 4,00ko, il est ici : https://workshop.numworks.com/python/cent20/polynome et il refuse de tourner sur la version de Epsilon et son tas python de 16ko.

On a réussit à le réduire de 30% depuis les 6ko sans enlever de fonctionnalités essentielles. Mais rien à faire, sur Epsilon ça ne veut pas tourner.

Il tourne très bien sur Omega par contre, et le Pull Request de Lionel Debroux sur GitHub est le PR le plus populaire...

Et je n'ai pas encore crée un DM demandant à mes élèves de poster un commentaire sous ce PR, ni de cliquer sur les coeurs, ça c'est prévu pour septembre 2020.