Vertel 2.00 - Page 5

???

quoi ?

oui, bon, ben, ce post là il aurait tres bien pu allerdans un autre topic, hein ???

_keytest c justement un _rowread simplifié pour pouvoir déterminer les touches sans faire de binaire/hexa...

Vertyos
a écrit : Il reste donc les multiples bugs de golstein... Je suis désolé de demander ça mais ça m'est venu tout à coup à l'esprit : N'aurais-tu pas par hazar eu la très mauvaise idée d'envoyer la version pour Ti92+ sur ta V200 ? Parceque si c'est le cas, pas la peine de chercher la cause plus loin...

Ce n'est pas normal que ça plante! C'est censé mettre un message "Wrong calculator model". Si ce n'est pas le cas, mets à jour TIGCC si ta version est trop vieille et supprime #define NO_CALC_DETECT si tu l'as mis.

Ma version est la 0.94 finale et j'ai mit ce switch volontairement pour gagner un peu de place. Des versions pour les trois calculatrice étant dans le zip, il n'y a normalement aucune raison de se tromper.

Si: envoi de calculatrice à calculatrice!!! Vous avez toujours tendance à oublier cela! Ça arrive souvent d'envoyer des fichiers d'une TI-89 à une TI-92+ par exemple.
S'il te plaît, supprime ce switch! Si on a mis cette détection de modèle, c'est pour une raison (justement, empêcher ces plantages)! Ce #define n'est là que pour des cas vraiment spéciaux (si c'est la seule manière d'être en dessous de 8, 24 ou 64 KO, si c'est la partie résidente d'un TSR et qu'on a déjà fait le test dans la partie installation, si le programme est compatible on-calc et qu'on n'utilise aucune constante qui dépend du modèle, ...). N'en abusez pas s'il vous plaît.

Et paf, 76 octets de plus

Est-ce qu'il serait possible d'améliorer ce #define dans une prochaine version ?
Je cherche vraiment à gagner de la place, et si je pouvais remplacer le message d'erreur par "Error", je le ferais.

Une utilisation du type :

#define CALC_DETECT message

Serait la bienvenue.

P.S : J'utilise aussi NO_AMS_CHECK, j'imagine que tu vas aussi me le reprocher, ce qui va encore faire perdre quelques octets

Arrête de râler pour même pas 100 octets.

Sinon, 2 conseils "secrets" (pas vraiment ) pour gagner quelques octets de taille:
1. Essaye -fno-if-conversion (en plus de -Os, évidemment).
2. http://tigcc.ticalc.org/gcc33/. Ça fait même gagner plus que "quelques octets" dans certains cas. Il vaut le coup d'essayer en tout cas.

Pour la détection de AMS, #define MIN_AMS 100 ne marche pas? Parce que c'est la solution idéale au problème. Mais évidemment, il ne faut utiliser que des fonctions compatibles AMS 1.00.

Ben... Le plus gros gain que j'ai eu pour l'instant c'est en changeant un point important dans la séparation des fonctions, ça m'a fait gagner environ 500 octets, ce qui est énorme.
100 octets c'est la taille moyenne d'une fonction, ce qui n'est quand même pas négligeable

Je cherche à rester en des 8Ko, pour ne pas être obligé de scinder la librairie en deux comme FL l'a fait.

Je vais appliquer tes deux conseils et voir combien ça "rapporte"

Au fait, tu ne m'as pas dit ce que tu pensais du NO_AMS_CHECK ?

J'ai dit que c'est une mauvaise idée et qu'il vaut mieux utiliser des fonctions accessibles en MIN_AMS=100.

Résultats :

GCC version distribuée avec TIGCC 0.94 finale, avec NO_CALC_DETECT : 7233 octets.
GCC version distribuée avec TIGCC 0.94 finale, avec detection de la calc : 7309 octets.
GCC version 3.3 et switch -fno-if-conversion, avec detection de la calc : 7285 octets.

GCC 3.3 a donc optimisé de 24 octets, ce qui n'est pas vraiment miraculeux
(mais c'est toujours ça de gagné)

Edit : Et en retirant le switch -fno-if-conversion le gain n'est plus que de 4 octets

Au moins ce n'est pas une régression. J'ai vu des exemples isolés où la taille a augmenté. Mais pour la plupart, l'optimisation est meilleure. GCC 3.3 a fait des miracles pour Backgammon et pour CC. Dommage qu'il n'a pas apporté grand chose pour Vertel.

Tant pis, en fait je m'attendais un peu à ce résultat : je n'arrive plus moi même à gagner une quantité significative d'octets, ça m'aurait un peu vexé que le compilateur le fasse à ma place

Tu sais à peu près dans quels cas les gains sont plus ou moins importants ?

Aucune idée. Désolé.

Pas grave.

Retour au sujet : est-ce que d'autres bugs sont à corriger, autres que ceux de Golstein (que je n'arrive toujours pas à comprendre d'ailleurs) ?

Kevin Kofler a écrit :
J'ai dit que c'est une mauvaise idée et qu'il vaut mieux utiliser des fonctions accessibles en MIN_AMS=100.

Mais je ne comprends pas, vu que de toute façon l'AMS la plus vieille est la 1.00 tous les rom_calls tournent au moins dessus, non ?
Donc ça revient au même que d'utilise NO_AMS_CHECK, non ? (à part pour pedrom)

y a des rom_call qui existait pas l'époque et qui existe maintenant

Ben oui, mais si on met MIN_AMS 100 le prog s'exécutera seulement si on a au moins AMS 1.00, or comme il n'y a pas d'AMS avant, je ne vois pas à quoi ça sert.
Mais je dois me tromper en fait.

MacIntoc> Pour les ROM_CALLS récents, il faut définir MIN_AMS 200 (ou un truc du genre). Mais definir MIN_AMS 100, je ne vois pas à quoi ça sert

nan, min_ams_100 renvois une erreur quand tu compile une source qui contient une rom_call qui est pas supporter par AMS 1.00

sans tsr il y a toujours les memes problemes

Brmfmlfmfl...
Ben je sais pas... T'es le seul qui ait ça, et vu le genre de bugs que t'as à mon avis si quelqun d'autre les avait il me l'aurais dit.

je vais faire un reset complet de ma calc et tout remettre proprement et je verai bien la

bah... faudrait voire les sources.

de Vertel ? tu les as déjà non ?

mais nan, on s'en fout de Vertel, si t'arrive pas à trouver le prbm, y a rien d'autre à faire de ce coté. Je parle des sources basic

Arf ok

Autre chose :

Grâce à un conseil de BiHi, la taille a encore diminué, et Vertel est repassée sous la barre des 7000 octets (6985 pour être exact).
ExtendeD m'a conseillé d'utiliser un define de TIGCC qui :
+ Réduirait encore de 300 octets la taille de la librairie
- La rendrait incompatible avec les AMS inferieurs à 2.04
- La ralentirait un peu

Personnellement je suis contre, à cause de l'incompatibilité, mais reste à voir ce qu'en pensent les utilisateurs. Votre avis ?

bahj si ca ralentit ca ne vaut pas trop le coup...
c'ets l'utilisation de la fline (ou un nom comme ca) ?

ralentirais dans kel proportions ?????
sinon, pour l'imcompatibilité, je m'en fout (TI-92+ HW2 AMS 2.08 PoWa !!!!!).

D'après ExtendeD ça serait imperceptible (il ne faut pas oublier que c'est un ralentissement à l'échelle du C, donc en basic...).

Sinon oui, c'est la FLINE, qui nécessite un #define MIN_AMS 204