Ca faisait super longtemps !
Je ne répondrai que sur la partie exécution en Flash.
D'une part, l'exécution en Flash ne permet pas le SMC. Le SMC qui permet parfois de bons compromis entre optimisation taille et optimisation vitesse: routine de niveaux de gris de TIGCCLIB/ExtGraph, FastDrawLine dans ExtGraph (et il me semble avoir vu du SMC dans le code de Genlib, mais je peux me tromper);
D'autre part, ne pas mélanger, dans l'image binaire du programme, les segments .data et .text, est mauvais pour l'efficacité taille surtout, et (marginalement) l'efficacité vitesse.
En effet, ça empêche l'utilisation de références d(pc) (venant souvent d'une optimisation du linker) en lecture, sauf pour les données constantes (qu'il est malin de mettre dans le même espace que .text).
Il y a au moins deux solutions pour implémenter les segments .data/.bss en RAM, .text en Flash:
* version FlashApp: segment .data ET .bss pré-alloué en RAM pour pouvoir faire la relocation lors de l'écriture une bonne fois pour toutes de la FlashApp (qui ne bouge pas lors du garbage collect de l'archive). Autrement dit, xxx.l en écriture ET en lecture - il faut faire exprès pour faire pire.
=> Consommation statique de RAM, potentiellement élevée; à moins de spécifier qu'un programme à exécution en Flash ne bougera pas lors d'un garbage collect de la Flash, il faut garder les infos de relocation, ce qui ajoute à la taille.
* version FlashApp modifiée: on alloue lors de l'écriture du programme (bootstrap), un handle en RAM, qui ne contiendra que les pointeurs vers .data et .bss lors de l'exécution. Bloc auquel on fait référence à travers une adresse xxx.l.
=> consommation statique de RAM négligeable, MAIS ajout d'un niveau d'indirection.
(Ce deuxième point n'est pas valable si on utilise du reg-relatif pour les accès à .data et .bss - ce qui n'est possible que si la somme des deux tailles ne dépasse pas 64 KB).
En résumé: pour moi, c'est pas une bonne idée de faire de l'exécution en Flash...