Aide pour débutant en assembleur svp

[Hamza.S]

Il me semble qu'il y a un tuto de TheMachine02 sur le forum, as-tu fait des recherches ?
J'espère que tu testes sur un émulateur l'ASM peut être dangereux pour ta calculatrice

[emilechombier]

oui mais il y a celui-là qui est très complet aussi (je comprends l'anglais)
http://tutorials.eeems.ca/ASMin28Days/lesson/toc.
et bien sur, CEmu64 est mon ami...

[critor]

La seule chose vraiment dangereuse serait d'écrire dans une zone vitale de la Flash.
Normalement ça ne se fait pas par accident chez TI.

[emilechombier]

Bonjour,

Voilà j'ai programmé ma double boucle de 100 itérations en ASM. Voici le code sur PB, vous trouverez la version en C dans un autre onglet
https://tiplanet.org/pb/?id=229901_1567367967_86bf32715a&file=testasm.asm

mais c'est 4 fois plus lent que le programme en C compilé sous PB !!! A quoi ça sert que Ducros il se décarcasse !!
Je résume les chronos pour un test sur 100x100 itérations avec affichage des tours sur TI83PCE-EP :
Ti-BAsic : 25 minutes (si si) je vous jure
Python : 2 minutes
C : 13 secondes
ASM : 50 secondes

Je crois que c'est à cause des call _DispHL et des rappels (curRow) et des (curCol) si j'essaye de m'en passer on dirair que la TI y met d'autres données et fiche son boxon, y a-t-il moyen d'optimiser cela svp?

[Adriweb]

Il y a sans aucun doute moyen de faire du code ASM optimisé pour la vitesse - mais c'est pas moi qui vais pouvoir aider pour ce coup la

[emilechombier]

merci oui Themachine02 m'a conseillé de ne pas utiliser _dispHL, mais comme je débute (day 4 du tuto) je ne vois pas faire autrement pour afficher des nombres. Je vais regarder le code compilé dans PB mais je suis sur que je vais rien piger

[Epharius]

Ton code qui boucle m'a l'air plutôt opti donc je ne pense pas qu'il y ait de problème de ce côté là. Je pense que cette grosse différence de temps d'exécution provient entre autres de 2 choses :

- Premièrement (et je rejoins TheMachine02), la plupart des romcalls proposée par Ti sont lentes (dont dispHL), parce qu'elles ont souvent plein d'options et de fonctionnalités, de conditions etc. Cependant je ne crois pas que dispHL soit réputée pour être particulièrement lente. Dans tous les cas, la "la toolchain communautaire" a sûrement sa propre routine d'affichage, optimisée selon les besoins du programmeur, dont forcément plus rapide. L'objectif serait donc de faire sa propre routine d'affichage de nombre même si j'avoue que c'est lourd à faire.

- Deuxièmement, je crois que la "la toolchain communautaire" utilise l'astuce du bout de code qui accélère les programmes de 30% environ. Donc le temps qu'il met à exécuter ton programme est un peu "triché". Si tu utilisais cette astuce tu devrais te rapprocher du résultat en C.

Cependant, je ne sais pas si ça explique cette grosse différence de vitesse. À tester.

[Adriweb]

Il faut remplacer "le PB" par "la toolchain communautaire" dans ton message, mais sinon, oui

[Epharius]

Oups, pardon en effet, j'ai du mal avec tous les noms autour de la progra en C sur 83PCE

[emilechombier]

Ton code qui boucle m'a l'air plutôt opti donc je ne pense pas qu'il y ait de problème de ce côté là.

ah merci ça fait plaisir c'est mon premier programme en ASM sur TI83 (très fier ! )
J'ai remarqué qu'en supprimant les (curRow) avant les _dispHL ça va plus vite mais je ne peux pas m'en passer car l'affichage fait n'importe quoi au 2e tour, on dirait que leurs valeurs ne "tiennent pas" un tour, une instruction doit polluer l'adresse
En fait si j'ai bien compris PB et la "chaintool communautaire" fait ses propres "RomCalls" plus rapides... bon ben j'arrête de lutter avec l'ASM et je reste sur du C, du bon C est plus rapide du mauvais ASM...