85Fermer87
Lionel DebrouxLe 24/06/2008 à 08:24
Je pense qu'on peut trouver un peu mieux comme explication wink

Déjà, il n'est pas très juste de taper sur TIGCC. Au cas où certains feraient semblant de l'oublier, TIGCC, avec son linker depuis TIGCC 0.95, introduit des capacités (optimisation) que les vieux outils traditionnellement utilisés pour le kernel-based n'ont pas - et qui peuvent aussi profiter au kernel-based. Certains de la poignée de programmeurs kernel-based restants ne l'utilisent à ma connaissance pas, ils ont tort.

Mais ce linker introduit aussi certaines capacités du kernel-based qui sont mauvaises en _efficacité_: citons BSS, relocations mode kernel. Dans ces deux cas (et aussi avec les RAM_CALLs, par exemple), on se trouve avec du xxx.l relogé alors que du pc-relatif ou du an-relatif est en général largement possible, et plus efficace.
La couche d'abstraction représentée par le kernel (se traduisant notamment par kernel::exec et les RAM_CALLs) est bien pour la compatibilité antérieure. Celle qui permet toujours au vieux txtrider buggé de fonctionner (un peu) sur les machines modernes.
Mais vous savez comme moi, et ça ne s'applique pas qu'aux TI-68k, que la compatibilité antérieure se fait au détriment de l'efficacité, notamment parce que l'absence de modif/recompilation périodique ne permet pas de profiter des améliorations de la toolchain.