Folco (./1545) :
- le kernel fournit une détection matérielle, que chaque programme nostub réinvente

La version matérielle est mise à disposition par le système d'exploitation, la fonction de TIGCCLIB se contente d'aller vérifier le bon octet du système d'exploitation. (Il y a un hack spécial pour VTI, mais vu l'obsolescence de VTI, on pourrait l'enlever désormais.) Le RAM_CALL kernel n'est qu'une autre méthode, redondante, d'accéder à cette information.

- le kernel fournit une détection de AMS, que chaque programme nostub réinvente

Le système d'exploitation propose 2 valeurs: le nombre de ROM_CALLs et, sous les versions récentes, la version exacte. TIGCCLIB se contente d'aller vérifier ces 2 valeurs (en général, la première suffit, elle est accessible en moins d'octets qu'un RAM_CALL). Le RAM_CALL kernel n'est qu'une autre méthode, redondante, d'accéder à cette information.

- le kernel fournit un linker dynamique avec les librairies, que chaque programme nostub réinvente

Les programmes _nostub n'inventent aucun linker dynamique, ils utilisent le linkage statique.

- le kernel fournit un support des bss, que chaque programme nostub réinvente

Les BSS sont souvent inefficaces à cause des relogements, il y a souvent des solutions meilleures, et dans les cas où c'est utile, ça coûte une allocation et une désallocation de mémoire, on n'a pas besoin d'un kernel pour ça.

- le kernel fournit une détection de VTI, que chaque programme nostub réinvente

VTI est obsolète, donc cette détection peut être supprimée.

- le kernel fournit l'adresse de ROM_BASE, que chaque programme nostub réinvente

ROM_BASE peut être calculée avec un simple & logique. Le RAM_CALL kernel n'est qu'une autre méthode, redondante, d'accéder à cette information.

- le kernel fournit un support des valeurs de retour, que chaque programme nostub réinvente

L'astuce de RETURN_VALUE ne prend presque pas de place dans le code.

- le kernel fournit un support pour exécuter d'autres programmes, que chaque programme nostub réinvente

Le programme moyen n'a pas du tout besoin d'exécuter d'autres programmes.

- le kernel fournit le support de exit et atexit, que chaque programme nostub réinvente

Le programme moyen n'a pas du tout besoin de exit ni atexit, AMHA avoir besoin de ces fonctions est un indicateur de code sale ou du moins peu adapté au support visé.

- le kernel fournit un support du fline moderne, que chaque programme nostub réinvente

AMS gère la FLine depuis la version 2.04.

- le kernel fournit un anticrash, pas le nostub

L'anticrash met en général la calculatrice en un état instable, donc autant faire un reset (c'est de toute façon conseillé même après anticrash). La mémoire archive est gardée.

- le kernel fournit d'autres choses encore, comme la gestion des pack archive, pas le nostub

Fonctionnalités exotiques et inutiles, et surtout sans aucun intérêt pour l'utilisateur final.

- le kernel fournit une API stable, pas AMS que les programmes nostub prennent en pleine poire

AMS fournit une API stable: les ROM_CALLs.

- le nostub consomme 4 kb de RAM pour sauver l'écran, pas les programmes kernel

Tu es libre d'utiliser la restauration de l'écran… Et puis la sauvegarde est plus simple, plus rapide et plus compatible, et la place est prise sur la pile où on n'a normalement pas besoin de ces 3840 octets.

- le nostub est dépendant des protections mises en place par TI, pas les programmes kernel

Le kernel ne pourrait même pas exister sans contourner ces protections. Les programmes _nostub font attention à ces protections exprès, pour pouvoir tourner sur n'importe quelle machine dès l'usine.

- le nostub tourne de manière absolument débile sous PedroM, sur lequel les programmes kernel peuvent tourner de manière terriblement efficace (libc intégrée, exécution en archive et plus encore).

Le _nostub est le format natif de AMS, donc forcément, ça utilise les fonctionnalités de AMS, pas celles de PedroM. Mais ça tourne très bien sous PedroM aussi si PedroM implémente les ROM_CALLs nécessaires. Je trouve dommage que PpHd n'accorde pas plus d'importance à la compatibilité AMS (implémenter les ROM_CALLs manquants, changer quelques détails internes pour un fonctionnement plus proche à celui de AMS (genre: boucle événementielle, pile d'expressions, implémentation interne des handles compatible AMS) pour être compatible avec des programmes qui dépendent de ces détails etc. plutôt que d'implémenter des fonctionnalités qui dupliquent celles de TIGCCLIB).