encore une chtite question - Page 28

Je rappelle aussi que le timing de l'int 5 est variable selon les calcs (90 Hz, 270Hz).

PpHd
: Je rappelle aussi que le timing de l'int 5 est variable selon les calcs (90 Hz, 270Hz).

Ce n'est pas insurmontable, il suffit de le rerègler à 270 Hz pour toutes les calcs et de n'appeler l'interruption de genlib qu'une fois sur 3 pour faire 90 Hz.

pk 270 Hz ?

Un tiers de l'écran par interruption (gris HW2/HW3), donc 3 fois la fréquence de rafraîchissement de l'écran.

>Je pourais éviter certains problèmes avec l'int1?
Oui!!!

On ne peut pas. Tu es obligé de sauvegarder la vraie taille quelque part, comme en C standard.

La doc TIGCC est mal tournee. HeapSize retourne la taille du bloc que tu as le droit de modifier, ce qui peux etre plus que ce que tu as demande (En gros c'est max(8, (size+1)&~1))

Ah! Donc, si je veux la taille d'un handle dont je dois recopier le contenu, il n'y a pas de problème...

Quoique je me demande si c'est pas +2. Verifie (printf("S=%lu\n", HeapSize(HeapAlloc(100))); )

HeapAlloc(n) t'alloue un bloc de p octets, avec p >= n.. Il faut aussi p >= 6 car il a besoin de 6 octets pour faire le HeapFree, mais je crois que qu'il peut aussi t'allouer plus quand la distance entre ton bloc et le bloc suivant est inférieure à 8o et qu'il ne veut pas bouger le bloc suivant.

Martial Demolins
: oui, je dois recopier des groupes de 24 octets, donc une fois que j'ai la taille, je recopie par 24 octets, et je m'arrête à peu près au bout.

Attention, danger!!!
"je m'arrête à peu près au bout", ça sent le buffer overflow à une distance de 100 km!

Donc des buffer overflow

Mais utilise les features du linker! Compile avec toutes les optimisations activées, c'est nettement mieux, et la probabilité d'erreur est de zéro (0) depuis que j'ai implémenté les relogements inoptimisables (elle était très faible avant, mais là elle est exactement nulle).

Mais voilà ce que c'est:

						// *** Move Optimization ***
						// Optimize LEA(.L) var.L,reg into
						// LEA(.L) var.W(%PC),reg.
						// Optimize PEA(.L) var.L into PEA(.L) var.W(%PC).
						// Optimize MOVE.x var.L,reg/(reg)/(reg)+ into
						// MOVE.x var.W(%PC),reg/(reg)/(reg)+.
						// Optimize MOVE.x var.L,-(reg) into
						// MOVE.x var.W(%PC),-(reg).

Tout est dans les sources du linker, il suffit de les regarder...

Tu peux parfaitement remettre SR a 0 apres genlib::init. Meme en laissant l'int d'AMS.

C'est mieux de desactiver les ints, mais en pratique ca marche sans (Car les ints ne sont pas inter-dependantes).

d0<<2 ? Ça me paraît bizarre. Enfin pas avec a68k en tout cas. C'est possible qu'un autre assembleur sache le traiter (comme un lsl.w #2,d0).
Sinon, avec a68k il est possible d'utiliser l'opérateur '<<' dans les expressions numériques, mais pas sur les registres. a<<b signifie "a décalé de b bits vers la gauche".

Le BCD est un codage binaire différent du code naturel, et dont certaines opérations sont disponibles nativement sur TI (addition et soustraction [et peut-être que j'en oublie]). Le principe consiste à stocker un chiffre décimal sur 4 bits de ton BCD. Ainsi sur un octet, tu stockes des nombres de 0 à 99.

Sur TI il y a aussi une structure qui s'appelle bcd (en minuscules), c'est celle utilisée pour représenter les nombres réels. Elle permettrait de stocker avec plus de précisions les nombres que la représentation IEEE754. Je te renvoie à la doc pour plus d'informations : http://tigcc.ticalc.org/doc/timath.html#bcd

tu viens de trouver une feature, je suppose (à ne surtout pas confondre avec un bug !)