Logicielsmoto.com

Ca m'interresse ca. Y'a-t-il des modes d'adressage existant mais non documente pour certaines instructions, ou carement de nouveaux mode d'adressages ? T'as des infos (genre explication rapide) a partager avant ce soir ?

ouais.. mais en fait il se trouve que j'en ai besoin.. je suis en train d'essayer de porter l'algo basic des montagnes fractales en asm. Pour cela je commence par le faire en C pour trouver et debugger les algos et apres je reencode a la main en asm (j'ai defini un algo de trace de triangle rapide et la je regarde les fixed point pur savoir si un format 8.8 est suffisant).

Le C c'est pas mal en 1ere approximation pour se faire une idee d'un algo. A la louche c'est seulement E a 3 fois plus lent qu'a la main mais c'est bcp plus aise a manipuler.

En regardant le code C de crt0.o je m'appecrois qu'il y a une bonne optimisation pour calculer un pseudo "negd". Normalement on fait plutot:Or la crtO.o c'est bcp mieux: et hop 2 octets et 2 (ou 3) cycles de gagnes! Chapeau.. j'ai toujours procede avec le "addd #1" mais le coup du sbca c'est bien vu!

Hop! deux octets de plus et je ne parle pas des cycles cpu (sauf si B pointe sur #0 )

Par contre, je ne connais pas l'instruction SBCx Cela prend en compte la retenue non?!

Au même titre que SUBX.B sur 68K si je ne m'abuse.

@Yoann
Dans l'adressage indexe, je crois me souvenir qu'il y a des redondances.
Sinon, il y a effectivement 2 ou 3 modes en plus, sans aucun interet. Il y a aussi un mode d'adressage indexe equivalent au mode etendu. Enfin bon j'ai pas le detail la

Sinon, je suis entrain de me souvenir que pour le TFR et le EXG, il y a aussi des combinaisons non documentees a implementer.
J'ai fait tout ca dans mon emulateur mais je prefere garder mes sources. En revanche, ca ne me gene pas de partager l'information.
Je ferai un check up des sources pour voir toutes les bizarreries du 6809.

a+
Seg.

Pourquoi? Tu as peur que l'Atariste que je suis s'en serve à mauvais escient

@jasz
Mais non C'est juste que je prefere garder mon travail tant que le projet n'est pas fini. D'ailleurs, mon emulateur est au point mort depuis 2003, mais il est fonctionnel et il gobe des disquettes thomson sans soucis.
Je compte m'y remettre. Il n'a jamais ete mis au placard.

a+
Seg.

Bon, Si tu as besoin d'un coup de main, n'hésite pas alors. Ce sera une allience historique.

en effet ce qui limite bcp son interet pratique



exact.. Il y a aussi adca et adcb.. addition avec carry.

Sur 68k le subx est pas mal utilise pour les optims bas niveau. Ca permet d'avoir facilement un registre avec -1 si c==1: subx.l d0,d0 ==> d0 contient 0 si c=0 ou 0xFFFFFFFF si c=1. En quelque sorte on a recopie la carry a tout le registre d0.

Su 6809e je me demande comment faire ca bien car on ne peut faire un sbc que par rapport a une constante. Il faudrait donc clearer le registre avant:

Sauf que clrb force c=0. Bon evidemment si on peut le mettre avant l'isntruction positionnant C, c'est parfait.. mais sinon je vois pas trop sauf a faire des trucs pas super efficaces:

Pour du 16bits on peut par contre faire:

Oh que c'est beau... sisi.. pas une instruction de trop, meme les copies sur la pile sont utilisees. Mince si ca se trouve le code du sqrt() est pas le plus court.. J'suis jaloux . Ce genre de routines se trouve comment ? A partir d'un algo deja pas mal rapide et en reorganisant les instructions pour virer les trucs redondants ou pour utiliser a mieux les resultats partiels ? Il y a une bibliotheque de code arihmetiques optimisee pour 6809e quelque part ?

sam (oui je sais c'est pas desinterresse)

@Sam
Je ne connais pas de bibliotheque arithmetique mais si tu veux commencer a collecter les routines dispersees sur le forum, ca peut faire un truc interessant.
De plus, en rendant public les sources, ca peut amener certains a trouver des optimisations que l'on n'aurait pas pense.

Pour la routine de racine carree, on va laisser tomber la version 8 bits qui n'a pas d'interet vu qu'une table de 256 valeurs fait l'affaire. On va plutot se concentrer sur la racine carree d'un nombre 16 bits.
J'en avais fait une qui me semble plus courte que la tienne (en ne deroulant pas la boucle) mais je la trouve pas tres optimisee aujourd'hui. Faut dire que elle aussi date d'il y a 15 ans (j'en connais un qui va encore en prendre un coup ). Donc, je peux la poster et on peut l'ameliorer ensemble... ou bien tu m'en proposes une autres plus courte

a+
Seg.

@Sam
Pour l'algo de div 8 bits, je suis parti de la methode de division en base 10 que j'ai applique au binaire. Evidemment, en binaire c'est beaucoup plus simple.
Apres, pour le code 6809, tu ponds une premiere version, puis tu optimises pour arriver au final a un code qui coule bien... enfin, du mieux que tu peux... en optimisant au max l'utilisation des registres.
J'ai aussi une routine de division 16 bits dans mes vieilles disquettes...

a+
Seg.

Je suis tombe sur un algo en C tres interressant sur http://www.embedded.com/98/9802fe2.htm (ou ftp://ftp.embedded.com/pub/1998/cren98_2.txt):


Ca doit se coder super efficacement en asm quand on voit que le a>>30 recupere les 2 bits du a<<=2 pour les inserer dans la partie basse de rem. Idem le root <<= 1 ... ++root c'est un ror avec la carry positionee a . Donc si pour du 16 bits on choisi de mettre rem dans regB, root dans regA, la valeur a sur la pile on a un code qui ressemble a:
La apres, on colle i dans le registre X, et voila l'algo est quasiment code. Il a plein de bonne propriete cet algo pour le 6809 finalement.
(il faut faire gaffe car root deborde d'1 bit le resultat donc il faudrait 9 bits.. le bit C peut peut-etre servir de 9eme bit si on choisi les instructions ne perturbant pas C.

C'est vrai que ca serait cool (enfin pour moi au moins) de creer un sujet sur les algos "arithmetiques" ou les algos "complexes" optimises pour 6809e.. Certes on gagne des cycles comme dans le sujet courant, sauf que la c'est au niveau de l'algo plus qu'au niveau des instructions elementaires... encore que.. l'optim d'instructions elementaire a un role non negligeable aussi.

Il y a l'air d'avoir des trucs interressants ici: http://www.embedded.com/code/master.htm

sam.

@Sam
Bien vu sam. C'est l'algo que j'utilise si ma memoire est bonne. Reste a voir l'implementation que tu en fais. Mon implementation n'est pas tip top mais si on peut en faire une qui depote, ca sera toujours ca de gagne.

a+
Seg.

Donc voici les modes indexes non documentes (codage binaire):

Pour les instructions TFR et EXG maintenant:
On peut transferer un registre 8 bits dans un registre 16 bits. Ca se transforme en $ff00+Registre 8 bits.
Pour le registre CC, il se retrouve en poids fort et en poids faible quand on le transfert dans un registre 16 bits. Enfin c'est ce que dit mon code J'ai fait ca il y a longtemps alors je me rappelle plus des tests que j'avais effectue.
Idem pour le registre DP
Pour les transferts 16 bits vers 8 bits, seuls les poids faibles sont gardes.
Maintenant, si on specifie un registre qui n'existe pas en source, on retrouve un $FF ou un $FFFF (suivant la taille du registre) en destination.

Sinon je reviens sur les instructions non documentees "speciales" que j'avais range dans la categorie "exception", pour specifier l'increment PC constate apres execution de l'instruction:

a+
Seg.

j'suis preneur!