quelque question interressente en asm - Page 1

-

Orion_>
- Oui mais en désactivant les interruptions (les auto-ints les autres ne se déclenchent pas toutes seules) donc c'est plutôt génant par exemple pour ceux qui ont la 2.08 et l'heure.
- En théorie oui, en pratique pas tellement je pense, si tu désactives les interruptions 1 et 5, déjà ça ira un peu mieux.
- La routine de gray se place dans une auto-int, et à chaque fois qu'elle se déclenche, elle dessine un plan différent (en pratique c'est plus compliqué car pour avoir quelque chose de potable, il faut dessiner un tiers d'écran puis un autre et enfin le dernier (haut-bas-milieu je crois). En plus elles ne marchent pas pareil sur HW1 et HW2 car avec du HW1, on utilise l'écran normal de la TI ($4c00) pour un des plans de gris.

-

AutoInt1

et il vaut mieux ne pas désactiver le 3, qui est utilisé pour l'horloge...

lakelle ? j'croyais que l AMS 2.08 était buggére...

les gris c'est soit l'ai1 soit l'ai5, ça dépend...

Ha ?

Ça dépend de l'implémentation. Dans l'implémentation standard (tigcc.a), c'est l'AI1.

il me semble que c Genlib qui utilise l'AI5...
(il me semble que c ce que PpHd avait dit à un des open... enfin, si j'ai bonne mémoire)

Oui.
Et certaines anciennes routines de niveaux de gris (anciennes versions de Universal OS et de tigcc.a notamment) utilisaient l'AI5 sur HW2 parce que ça fonctionnait mieux pour ajuster la synchronisation. Mais maintenant, on utilise le port de synchronisation, donc l'AI1 convient très bien maintenant.

OK.
merci pr l'info

-

Je trouve que c'est pas une raison pour emmerder ceux qui utilisent l'heure !

Moi j'ai fait vite le tri après avoir installé la 2.08, j'ai viré tous les programmes qui dérèglent l'heure ou qui plantent complètement la calto (càd reset total qui fout l'heure en l'air).

En clair, j'utilise l'heure, elle n'est jamais déréglée, et il ne faut pas compter sur moi pour adopter un programme qui inhibe l'AI 3 (alors que ça n'apporte rien)

Il y a deux, voire trois façon pour bloquer une AI. Par le SR, par détournement, et peut-être par un port.

-

THibaut> donc, tu n'utilise pas les progs utilsant Genlib...
(enfin, à moins que PpHd ait changé ça... il me semble que, voila quelques temps, Genlib désactivait (ou détournai) l'AI3)

>Il y a deux, voire trois façon pour bloquer une AI. Par le SR, par détournement, et peut-être par un port.
En effet. C'est le port 60015, bit 2.

squale92 a écrit :
THibaut> donc, tu n'utilise pas les progs utilsant Genlib... (enfin, à moins que PpHd ait changé ça... il me semble que, voila quelques temps, Genlib désactivait (ou détournai) l'AI3)

Ce qui est une bonne raison de ne pas l'utiliser.


Et Orion_, au lieu de désactiver toutes les interruptions, il suffit de rediriger les auto-interruptions 1 et 5, et éventuellement 2, 4 et 6 (mais pas 3 et 7!) vers un rte. Ne touche pas:
* à l'AI 3: elle est utilisée pour l'horloge, n'est activée qu'une fois par seconde et ne contient que 2 instructions (un addq.l #1,... et un rte). Elle ne ralentit donc pas du tout ton programme.
* à l'AI 7: elle n'est activée qu'en cas de "Protected Memory Violation", donc elle ne ralentit en rien ton programme.

Ce qui est une bonne raison de ne pas l'utiliser.

pas pour moi : j'ai une HW1, donc, sans horloge...
donc, que genlib touche à l'AI3 ne me géne pasd

-

Tu références un label qui n'existe pas. Le nouveau linker qui accompagnera TIGCC 0.95 donnera un message d'erreur plus clair, indiquant entre autre le nom du label en question. Maile-moi le fichier et je te dirai où est le problème.

-

Je n'aime pas du tout ta façon d'optimiser, Orion...
En plus, si tu fais ça partout, sh`L prendra 50 ko....

On voit clairement que c'est dans le principe du -O3, pas du -Os. Personnellement, je suis partisan du -Os.
D'ailleurs, as-tu compilé avec -O3 quand tu as eu une version C tellement plus lente que ta version en assembleur? Si c'est le cas, ton code C n'était pas génial... Parce que GCC sait lui aussi dérouler les boucles si on le lui demande.

-

-

Orion, ton concurrent direct était aussi à une époque à 10 ko en-dessous.
Mais quand il a ajouté le tri par types, la compression, le support natif des sous-répertoires, il a eu la surprise de voir son programme gonfler comme il ne l'avait pas prévu. Ne parle pas trop vite, on verra quand tu auras terminé tout ce que tu veux faire à cette nouvelle version

moveq #0,%d0
Trap #1

Kevin Kofler a écrit :
Ce qui est une bonne raison de ne pas l'utiliser.

Ce qui montre l'avantage du kernel et la puissance des libs dynamiques : une mise a jour de genlib (depuis la sortie de la V200) a elimine cette source de bug sans recompiler tous les programmes genlib...