[ASM Z80] Comment mettre un OP dans un registre 16 bit

Bonjour à tous !


Tout est dans le titre, en fait, j'aimerais mettre par exemple OP1 dans HL J'ai bien fait pas mal de recherches mais comme l'assembleur est assez mal documenté, je n'ai pas trouvé.
J'ai aussi regardé dans l'include pour voir s'il n'y avait pas une RomCall susceptible de faire ceci mais rien ne m'a sauté aux yeux.
Parce que pour mettre A dans OP1, ça y'a pas de problème, mais pour le contraire, y'a plus personne x)


C'est pour cela que je me tourne vers vous : y a-t-il un moyen de mettre un OP dans un registre 16 bit ?

Michi beaucoup !

La romcall ConvOP1 de TI convertit un flottant stocké dans OP1 vers le registre 16bits DE. Je n'ai aucune idée des erreurs de conversion hors domaine.
ConvDim et ConvDim00 y ressemblent mais assurent des valeurs valides pour les listes et matrices.
Je les ai trouvé dans le guide des routines 83plus et vérifié leur présence dans le fichier include de ti83 par Brandon Wilson. Tu peux faire de même.
Je te prie de désigner précisément les mémoires. "A" est trop vague. Le registre (accumulateur) ou la variable numérique du TI-Basic ?

Linkakro a écrit:Je te prie de désigner précisément les mémoires. "A" est trop vague. Le registre (accumulateur) ou la variable numérique du TI-Basic ?

Si tu parle de : "Parce que pour mettre A dans OP1, ça y'a pas de problème", ça je sais déjà le faire. Mais oui, je parlais bien de l'accumulateur et pas de la variable en Basic. Mais j'avoue que c'était un peu ambiguë.

En effet, Convop1 met bien OP1 dans DE. Merci beaucoup !

Pour ConvDim et ConvDim00, comment marchent-ils ? J'ai essayé de chercher sur google mais je n'ai pas trouvé...

J'ai lu un des SDK de ti83plus fournis sur le site de ti83plus.
[Vous devez être inscrit et connecté pour voir ce lien]
On n'a presque rien d'autre excepté quelques sources d'experts tels que WikiTI ou la communauté du forum Omnimaga.
[Vous devez être inscrit et connecté pour voir ce lien]

Merci pour le PDF, c'est incroyable que quelqu'un ai rassemblé autant de routines... il devait s'y connaitre x)

Pour WikiTI je connaissait du coup puisqu'on en avait déjà parlé, mais malheureusement il n'y en a pas énormément.

Le SDK que je t'ai indiqué est officiel, il est publié par TI, sur le site de TI-education. TI connaît ses propres routines, cela me semble normal. Bien sûr c'est la génération ti83plus donc cela demeure expérimental pour la ti83.

D'ailleurs, en passant : sujet intéressant (enfin je trouve... ^^).
Voici un exemple de code si a est de valeur [0;255] :

Code:

cp 100
jp m,label

Alors, d'après toi, la Ti devrait sauter si A (accumulateur) >100. En partie ! Problème de bits je suppose.
Les résultats que j'obtiens se situent entre [0;100]U[200;255] (ce sont des valeurs approximatives). Intriguant non ?

Comme je le disais _Random doit "tirer" des nombres en binaire et non en base de 10 (normal) Après, je ne m'y connais pas beaucoup en binaire.

J'ai remarqué ça y'a quelque temps. Je trouve ça intriguant : mais en même temps ça peut poser des problèmes. Saurais-tu comment contourner le problème ? Ce qui est bizarre c'est que par exemple 200, s'écrit en binaire %11010000, alors que 60 s'écrit %00110000. C'est quand même facile de dire que %11010000>%00110000. Alors quel est la problème que se pose la calculatrice ?

Voilà =)

La romcall _Random génère les nombres réels aléatoires du TI-Basic. Pas juste des entiers. Je n'ai pas cherché ses effets secondaires sur les registres en revanche.

####

Ton problème est certainement le codage des nombres négatifs.
J'ai relu le manuel au chapitre des flags (drapeaux) Sign, Carry, et Overflow (P/V).

Le processeur considère des nombres entiers signés en complément à 2 pour la plupart des opérations.
Cela signifie les propriétés suivantes :
-la plage est -128 à +127 pour les nombres 8 bits
(pour N bits elle de -2^(N-1) à 2^(N-1)-1 )
-le bit de poids fort est le bit de signe, 0 pour positif et 1 pour négatif
-un nombre négatif est le complément à deux de son opposé et réciproquement.

Le complément à deux se détermine de plusieurs manières dont les suivantes :
- "-A" sur 8 bits est codé comme le serait le positif non-signé 256-A sur 8bits.
- le complément à un (inversion, complémentation, de chaque bit) puis ajoutant 1. Remarque que complémenter à un revient à calculer 255-A.
- la conservation des zeros de droite à gauche jusqu'au premier 1, conservation de ce 1, et complémentation de tous les bits plus à gauche

Exemple : 16=%00010000 et -16=%11101111+1=%11110000 par codage complément à deux

Pour ta culture, sache que ce codage assure un code unique du nombre zéro et des calculs de somme de nombres relatifs.

####

mémo pour moi-même : jp m,nn est conditionné par le flag de signe S avant le saut.
Priviliégie JR (saut (jump) relatif) au saut absolu JP dans des programme courts car il est plus léger, plus rapide, et indépendant de la position du programme (cf directive ".org" du compilateur).

####

Le flag de signe S est basé sur le bit de signe du résultat.
Or 200=%1100 1000 a un bit de signe 1 et est le complément à deux de -56=%11001000.
Ainsi 200-100=100 revient en réalité à -56-100=-156=%110 0100 qui est négatif par son bit de signe.
Donc le flag de signe négatif S est mis à 1 par ld a,200 \ cp 100. 

Le flag overflow (dépassement de capacité) est mis à 1 si le calcul arithmétique dépasse la plage -127 à 128.

Le flag de retenu Carry C est affecté par les retenues des opérations d'addition et soustraction non-signées d'après ce que j'interprète. Il signale le dépassement de 256 ou 0. Mais le manuel ne l'indique pas explicitement. Il mentionne seulement les retenues "Carry" ou "Borrow" et les instructions du Carry.
D'autres instructions l'affectent avec d'autres significations.

(Je viens de me rendre compte que mon message ne voulait rien dire par moment x) )


J'utilisais JP pour l'exemple.

Donc il faudrait d'abord que je vérifie que ce nombre est positif en faisant un "JR s,negatif", puis, vérifier qu'il ne dépasse pas une certaine valeur ?
Ce qui m'étonne c'est que le nombre affiché est bien positif... Ou alors _DISPHL affiche le nombre entre 0 et 255 seulement...

Je pense que tu dois utiliser le flag carry C pour détecter les dépassements des nombres non-signés, au lieu du flag de signe qui n'est adapté que pour des nombres signés.
(Tu peux aussi utiliser plusieurs conditions, ou encore comparer entre avant et après, mais les alternatives deviennent lourdingues en assembleur.)

Tout ce qui compte est l'interprétation du code d'un nombre et l'utilisation de routines compatibles avec ce code.
La romcall _DispHL utilise le codage des nombres non-signés, voilà tout. De plus HL est de 16 bits, pas 8. Je teste $FFFF et cela affiche bien 65535, pas -1.
Il y a des flags et des instructions qui travaillent sur des nombres non-signés, et TI fait ce qu'il veut avec ses routines.

C'est vrai que rien que de faire deux conditions, ça devient lourd et illisible.

Enfin c'est compliqué de se dire que y'a des romCalls qui interprètent avec les signes et d'autres sans. Ça crée des erreurs facilement.

Bref, merci beaucoup ! J'y penserai quand un problème de ce genre arrivera =)