encore une chtite question - Page 12

Martial Demolins :
Est-ce que getsn (que j'utilise finalement) est compatibles avec les niveaux de gris?

Pas vraiment , mais vu qu'on utilise les fonctions de TI pour l'affichage, je suppose que PortSet fonctionne, donc que tu peux le faire afficher en gris foncé avec un GraySetAMSPlane(DARK_PLANE);. Donc:

Si oui, ça doit afficher alors dans le plan actif je pense...

Oui.

Martial Demolins
: Au fait, je cherche à savoir comment bencher des morceaux de routines que je fais, comment puis-je m'y prendre?

Appeler la routine 10ⁿ fois (pour une valeur raisonnable de n: plus c'est grand, plus c'est précis, mais plus le bench met du temps), chronométrer, diviser par 10ⁿ.

Mais le compteur de cycles de VTI est incorrect. Pour certaines instructions (Bcc, MULx, DIVx, décalages de bits), les valeurs seront mauvaises.

J'en doute fortement.
J'avais regardé les sources (je ne me souviens plus si c'était celles de la version modifiée ou non), et j'avais vu que ça demandait pas mal de boulot de changer ça.

En gors j'avais remarqué que (sous la version modifiée) il comptait toujours les mêmes temps d'exécutions pour les instructions de décallages (lsl, lsr, etc). Ca doit être la même chose pour les autres instructions citées par Sasume. Ceci dit, tu peux faire des tests comparatifs qui te permettront quand même de voir si un bout de nouveau code tourne plus vite que l'ancien en utilisant ça, même si la précision n'est pas parfaite ça permet toujours de se faire une idée

Parfois les résultats sont faux, dans les cas où on utilise les instructions de décalages en général.

En fait, vti utilise une table qui contient le temps d'éxécution de chaque instruction, mais comme il y a des instructions dont le temps d'éxécution dépend de la valeur des opérandes (celles que j'ai citées en ./335 [et peut-être d'autres que j'ai oubliées]) le résultat est incorrect...

^^ oué mais ça c pske il utilise le core cpu de mame () J'avais d/l les source une fois (pour me servir de l'émulation 68k bien sûr) et j'ai pu voir que ct bien de la merde (donc -> poubelle)

C'est une des raisons pour lesquelles je préfère optimiser en taille: c'est plus simple.

2 > oui c'est ça

Martial Demolins
: ->Quand je compile un prog (qui utilise une lib statique perso), il tigcc me met un warning du genre "a nostub program contains startup section", ou qqchose qui ressemble à ça. D'où ça peut venir?

Librairie statique à recompiler avec TIGCC 0.95 et/ou en définissant _GENERIC_ARCHIVE.

->char *getsn (char *string, unsigned long maxlen); ça veut bien dire que getsn renvoie un pointeur (donc un longword dans A0), je me trompe ou c'est ça?

Oui, il renvoie un pointeur, qui est une copie du pointeur string.

Martial Demolins
: 1) ok, mais la lib je l'ai recompilée déjà plusieurs fois avec la version 0.95, donc c'est pas ça.

Mais l'as-tu recompilée entièrement? C'est-à-dire avec Project/Build, pas Project/Make!

Donc le _GENERIC_ARCHIVE, je le mets où?

-D_GENERIC_ARCHIVE dans les options du compilateur, ou alors #define _GENERIC_ARCHIVE dans chaque fichier. Mais la première solution est la plus pratique à mon avis.

Ah oui: si _nostub est mentionné littéralement quelque part (dans une source en assembleur), vire-le. Le problème, c'est peut-être ça aussi. (Il n'a jamais été une bonne idée d'exporter _nostub dans une librairie statique - c'était au programme principal de le faire - mais c'est encore plus grave maintenant que le linker distingue entre _nostub (sans code de démarrage) et _tigcc_native (avec code de démarrage, peut donner du _nostub, du kernel etc.).)

2) ok, merci, j'ai des petits soucis avec cette fonction, mais je vais régler ça. En plus, je l'utilise dans mas lib statique, qui foire apparemment (cf1), donc je verrai une fois que la lib marchera

Le problème du 1. est un warning, ça ne devrait pas être un problème grave à ce point.

D'ailleurs, il n'y a pas vraiment "la bonne": si tu ne veux recompiler qu'une partie, utilise Make, mais si tu viens de mettre à jour TIGCC, utilise Build au moins une fois pour tout recompiler.

1. getsn n'est pas un ROM_CALL, donc tu ne peux pas utiliser une macro de ROM_CALL pour l'appeler. Utilise un simple bsr.
2. getsn importe le code pour mettre le bit in-use, qui est nécessaire pour utiliser le event loop, qui est nécessaire pour afficher le menu CHAR. Or, tu as sans doûte exporté _nostub dans ton programme principal, d'où ton warning. Il faut remplacer ton:
xdef _nostub
par:

_tigcc_native: xdef _tigcc_native
__ref_all___startup_code: xdef __ref_all___startup_code
__ref_all___nostub: xdef __ref_all___nostub
 xdef __main

__main:

Il faut vraiment que je réécrive mon tutorial ASM pour le nouveau linker.

Martial Demolins
: j'aurais jamais trouvé pour le reste

Il faudra en effet que je mette ça:
1. dans mon tutorial et
2. quelque part dans la documentation de TIGCC, probablement dans "Information for Assembly Programmers"
parce que là, tu as raison, ce n'est pas clair du tout. On peut à la limite le retrouver en fouillant bien la documentation du linker (et encore, je ne pense pas que les noms des global imports y sont), mais ce n'est pas vraiment bien documenté. Pour l'instant, la meilleure manière de trouver les xdef à mettre est de compiler un programme en C et de regarder le .s généré.

Martial Demolins :
il faudrait mettre un getsn2 pour ne pas accéder au menu char , ça résoudrait le problème en partie

À mon avis, c'est plus un hack qu'une vraie solution...

Martial Demolins
:

Kevin Kofler :
Pour l'instant, la meilleure manière de trouver les xdef à mettre est de compiler un programme en C et de regarder le .s généré.

lol je vais devoir apprendre le C pour p^rogrammer en asm

Un programme vide suffit:
#define USE_TI89
#include <tigcclib.h>
void _main(void) {}

Sinon pour getsn2, si c'est une fonction de tigcc, ce ne sera pas un hack

Si, faire une fonction à part à fonctionnalités réduites juste pour éviter de devoir mettre du code de démarrage, c'est un hack.