APMEP 2019 à Dijon avec Casio, HP, NumWorks, TI et KhiCAS

[parisse]

Je pense que la principale raison est qu'ils craignaient qu'un malloc renvoie un pointeur nul ou invalide et provoque un reset. J'ai ce souci avec Delta, meme si je pense l'avoir a peu pres resolu en testant la valeur retournee par malloc et en demandant a l'utilisateur de purger des variables si on depasse une valeur.

C'est clair que le systeme actuel n'est pas amical pour le developpement d'applications tierces, et la marche est tres haute. Je suis en train d'ecrire de la documentation pour un petit SDK permettant d'ajouter des applications tierces a Delta beaucoup plus facilement (a mon avis en tout cas!). Ainsi, ajouter un addin a Delta pour calculer et afficher la meme fractale de Mandelbrot que le code exemple donne dans le scriptstore prend 30 lignes de code (et l'affichage se fait en quelques secondes). Un addin pour jouer au mastermind 140 lignes.

[Lephe]

Au fait, une partie de la mémoire statiquement allouée (il y a d'autres blocs, par exemple le TreePool) l'est avec une union plutôt qu'une struct. Cette partie-là est donc une zone partagée entre toutes les applis, et non une zone par application.

Ah, c'est donc plus subtil que ce qu'on m'a expliqué.

Je pense que la principale raison est qu'ils craignaient qu'un malloc renvoie un pointeur nul ou invalide et provoque un reset.

Ben... c'est pas une bonne raison ? Le code peut toujours afficher des erreurs, enfin plein de logiciels s'en sortent très bien.

[jean-baptiste boric]

Au fait, une partie de la mémoire statiquement allouée (il y a d'autres blocs, par exemple le TreePool) l'est avec une union plutôt qu'une struct. Cette partie-là est donc une zone partagée entre toutes les applis, et non une zone par application.

Ah, c'est donc plus subtil que ce qu'on m'a expliqué.

Une piste d'amélioration assez évidente serait d'allouer chaque struct du gros union dynamiquement selon l'app active. Cela libérerait un tas de mémoire conséquent pour KhiCAS sans remettre en cause l'architecture d'epsilon, mais les dernières tentatives n'étaient pas très concluantes.

Je pense que la principale raison est qu'ils craignaient qu'un malloc renvoie un pointeur nul ou invalide et provoque un reset.

Ben... c'est pas une bonne raison ? Le code peut toujours afficher des erreurs, enfin plein de logiciels s'en sortent très bien.

L'allocation dynamique sous-entend la possibilité de tomber à court de mémoire, que ce soit par épuisement pur et simple ou fragmentation excessive. Plutôt que de complexifier le code pour gérer cela, dans le monde de l'embarqué il est beaucoup plus simple d'allouer statiquement pour ne jamais avoir de problèmes. Quand au fait que plein de logiciels s'en sortent très bien, c'est l'exception et non la règle. L'immense majorité des logiciels de taille respectable planteront (ou au minimum rencontreront de sérieux problèmes) au premier malloc qui rate.

Une calculatrice moyen de gamme n'est pas un ordinateur portable. Il est communément accepté qu'un onglet de navigateur web plante en cas de pénurie de mémoire si l'utilisateur l'a poussé au-delà du raisonnable, ça l'est beaucoup moins qu'une calculatrice plante parce que l'utilisateur a fait le calcul de trop.