Je crois qu'il peut y avoir des problèmes dus à la syntaxe utilisée pour la déclaration des fonctions dans tilemap.h, syntaxe que GTC ne reconnaît pas.
Mais le mieux (à mon avis) est d'utiliser genlib, qui est quand même plus optimisé que ce que j'avais pondu à l'époque.
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
Sasume tu parles des void *dest asm("a0") ou d'autre chose ?
Et les fichiers .a ce sont les fichiers HDR de la calculette ou non ?
Elements Soul, mon projet sur TI-92+ (et d'ailleurs mon seul VRAI projet)
Avancement :
Interface : 90 %
Système de combats : 95 %
BDDs : 60 %
Histoire : 5 %
Oui, la déclaration des paramètres.
Mais je préfèrerais que ce soit Pollux qui réponde à ces question, personnellement je n'ai réalisé aucun test avec GTC, donc je ne sais pas à quel point c'est compatible ou incompatible.
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
C'est sûr que les philosophies de Genlib et d'ExtGraph sont très différentes. Du coup, ExtGraph n'est pas vraiment faite pour la programmation on-calc, même avec des headers précompilés... Et si tu supprimes les fonctions qui utilisent des paramètres hors de d0-d2/a0-a1, tu en supprimes un paquet !
Donc pour l'instant, GTC considère que les paramètres sont d'abord sur d0-d2/a0-a1, puis sur la pile ?
Et ce serait compliqué (ça demande d'écrire beaucoup de code ?) à changer, cette convention d'appel ?
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
Concrètement :
[ul][li]les registres temporaires sont limités à d0-d2/a0-a1, et sont alloués de façon séquentielle pour pouvoir être efficacement empilés et dépilés si besoin est ; il faut pouvoir ajouter d'autres registres temporaires (par exemple a4), et il faut pouvoir allouer de façon non séquentielle quand on génère les arguments de la fonction
[li]les registres sont alloués globalement pour la fonction, or ça serait un peu coûteux de mettre par exemple tous les registres d'adresses en registre temporaire simplement parce qu'un appel de fonction en a besoin : il faut donc 1] évaluer pour chaque registre si ça vaut le coup de le passer en temporaire 2] si un registre n'est pas temporaire mais doit être utilisé pour passer un argument, il faut sauvegarder son contenu dans un registre temporaire, et transformer pour la durée de l'appel les références à l'ancien registre en références au nouveau registre ; or l'architecture actuelle des registres temporaires n'est pas vraiment faite pour ça : par exemple quand on génère x+y, on génère x, on le stocke dans un registre temporaire (disons d0), puis quand on génère y on peut faire n'importe quoi avec d0 du moment que sa valeur est restaurée à la fin de la génération de y pour pouvoir effectuer l'addition -- alors que si une variable était stockée dans d0, elle pourrait être accédée absolument n'importe quand, donc la génération de y ne pourrait pas faire n'importe quoi avec d0 puisque potentiellement elle pourrait avoir besoin de cette valeur en plein milieu du calcul...
[li]plus évidemment plein de petits détails (parser les asm(), modifier la façon dont les fonctions regparm normales sont générées pour pouvoir les mélanger avec les fonctions à paramètres asm(), etc)[/ul]
« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)
? La version de Sasume, ou la version intégrée à ExtGraph (qui ne doit pas être bien différente...) ?
), #define qui doit dater d'une époque où on ne voyait pas encore trop GTC pointer le bout de son nez 
genlib est plus adaptée, mais par contre évidemment ça ne marchera qu'en kernel).
