Questions assembleur 6809

[SOREK]

Bonjour,

Pourriez-vous m’apporter votre aide dans la programmation du 6809

J'élabore actuellement un Assembleur pour le 6809 et j'ai quelques difficultés à employer ou ne pas employer l'arithmétique signé sur une plage de 64 ko.

A force de lire certain article sur le sujet de l'arithmétique signée, mon esprit est un peu perdu.

Pourriez-vous me préciser :
Dans quelles conditions doit-on utiliser exactement l'arithmétique signée.
Dans quels cas ne pas utiliser l'arithmétique signée.

Dans mon projet, j'ai un sous-programme qui me calcule la valeur d'une expression arithmétique dans un opérande, à la sortie de ce sous-programme, si la valeur décimale est négative, comment la traiter dans une valeur d'offset dans un adressage indexé à déplacement constant 5, 8 ou 16bits ?

Exemple :

Code : Tout sélectionner

    00244         CRTC     EQU    -8         ;
    00245                  .                 ;
    .                      .                 ;
    00758                  STA    CRTC,U     ;

A la ligne 00244 mon programme va stocker dans la constante CRTC la valeur $FFF8 (correspondant à la valeur -8)

A la ligne 00758 pour le calcul de l'opérande CRTC,U la valeur $FFF8 vaut en décimal 65528

Et donc cette valeur n'arrive pas dans un des trois cas ci-dessous :
Entre [-16 et 15] je l'associe à l'adressage Indexé avec offset en 5 bits
Entre [-128 et -17] ou entre [16 et 127] je l'associe à l'adressage Indexé avec offset en 8 bits
Entre [-32768 et -129] ou entre [128 et 32767] je l'associe à l'adressage Indexé avec offset en 16 bits

Je dois louper une étape mais laquelle ?

D'avance un immense merci.
Bonne journée et bon courage.

Richard SOREK

[__sam__]

Ce que tu ne comprends pas est l'usage général de la représentation signée sur N bits je pense (N arbitraire). Plus spécifiquement, au niveau des modes d'adressage du 6809 tu rencontrera des valeurs signées sur 16, 8 ou même 5 bits.

Avec N bits un nombre est encodé en b(N-1) b(N-2) .. b3 b2 b1 b0. En non signé cela représente une valeur entre 0 et (2^N)-1. Exemple entre 0 et 255 sur 8 bits, et 0 et 65535 sur 16 bits. En signé le même encodage désigne un nombre entre -2^(N-1) et 2^(N-1)-1. Exemple entre -128 et 127 sur 8 bits, -32768 et 32767 sur 16bits et entre -16 et +15 sur 5 bits.

Remarques:

1. Avec M bits on peut encoder n'importe quel nombre de N<M bits de même signe mais pas l'inverse. Les valeurs sur 5 bits sont toutes présentes dans les valeurs 8 ou 16 bits. Le passage de N bits à M bits (M plus grand) se fait en répétant le bit de poids fort pour compléter les (M-N) bits en plus. C'est ce point qui ne colle pas dans ton analyse. Ce n'est pas [-32768,-129] union [127,32767] ou [-128,-17] union [16,127] qu'il faut considérer mais [-32768,32767] et [-128,127] (sans trous). Voir après pour plus l'explication.
2. En signé les nombres négatifs ont la particularité d'avoir leur bits de poids le plus fort à 1: b(N-1)=1.
3. L'information "signée" n'est pas suffisante en soi pour interpréter un nombre hexa ou une suite de bit. Ainsi $18 peut représenter la valeur +24 sur 8 bits signés (son b7=0, le nb est >=0), mais aussi la valeur -8 en signée 5 bits (car en effet, alors son b4=1, et donc le nombre est à interpréter comme négatif sur 5 bits.)

Revenons à ton exemple: CRTC a la valeur $FFF8 oui, mais en 16bits non signé, mais en 16bits signé $FFF8 c'est -8, et donc CRTC est bien dans l'intervalle -16..+15. On peux donc l'encoder sur 5 bits avec la valeur 0b11000. C'est cet encodage là qu'utilisera un assembleur intelligent dans l'adresse "CRTC,U" car cela donne une instruction machine plus compacte et plus rapide. Maintenant, ce -8 peut aussi s'interpréter en signé sur 8 bit et il vaut alors 0b11111000 ou $F8. Dans ce cas là le code machine indiquera "indexation par rapport à A, de $F8(8bits signés)". A noter: les indexations sur 6809 sont toujours des valeur signées (ne ne connais même pas de processeur ayant des indexation autres que signées).

Donc ce qui te préoccupe pour créer un assembleur "optimisant" est de savoir sur combien de bits il te faut nécessairement pour encoder ton entier signé. Si tu peux encoder ton entier sur 5 bits (il représente une valeur de -16 à +15) tu va utiliser l'indexation 5 bits du 6809 (ton "-8" est dans ce cas là). Sinon si ton entier est entre -128 et +127, tu peux utiliser l'indexation signée sur 8bits (un peu plus lente que sur 5 bits). Enfin si ton entier est plus petit que -128 ou plus grand qye 127, tu n'as pas le choix il te faudra utiliser l'indexation sur 16bits qui est la plus lente des trois (et la plus gourmande en longueur d'instruction aussi.)

Remarques:

• Parfois on peut utiliser la notation "<CRTC,A" (noter le "<" au début) pour forcer l'indexation 8 bits quand on veut maitriser le format d'instruction que doit utiliser l'assembleur (il générera une erreur alors si l'offset ne peut tenir sur un octet signé).
• Un compilateur "vite fait" (cf celui de Forth sur 6809 je crois) ne se cassera pas la tête pour optimiser l'indexation et utilisera par défaut l'indexation 16bits qui peut tout représenter. Ca fait le boulot, mais n'utilise pas la puissance complète du 6809. A toi de voir ce que tu veux faire: un truc rapide, ou efficace ?

[hlide]

(ne ne connais même pas de processeur ayant des indexation autres que signées).

MIPS: J et JAL ont un "offset" non signé. Quand on émule le calcul, on peut faire indifféremment

Code : Tout sélectionner

(PC & 0xf0000000) | (offset<< 2)

ou

Code : Tout sélectionner

(PC & 0xf0000000) + (offset << 2)

.

Mais ouais, la très grosse majorité des "offsets" sont signés - même dans les comparaison de valeurs non-signés.

[__sam__]

C'est pas tellement que c'est "non signé", c'est surtout que (offset<<2) est traité comme un nombre sur 28 bits, car si (offset<<2) était sur 32 bits (signé ou pas ca change rien pour les décalages à gauche) la valeur (PC&...) | (...<<2) et (PC&...) + (...<<2) ne seraient pas équivalents. Pour vraiment être équivalent il faudrait écrire (en C, entiers 32 bits)

Code : Tout sélectionner

(PC & 0xF000000000) | ((offset<<2) & 0x0FFFFFFFFF)
(PC & 0xF000000000) + ((offset<<2) & 0x0FFFFFFFFF)

[hlide]

Tu te doutes bien que l'offset en question est une extraction de 26 bit de l'opcode codé sur 32-bit, donc si tu veux être précis, ça nous donne en fait :

Code : Tout sélectionner

(PC & 0xF000000000) | ((opcode & 0x03FFFFFF)<<2)

ou

Code : Tout sélectionner

(PC & 0xF000000000) + ((opcode & 0x03FFFFFF)<<2)

Donc ma formulation était bonne, juste que je n'avais pas précisé que l'offset en question était bien une extension non signée d'un mot de 26 bits en un mot de 32 bits (ou plus mais je me limitais en fait à du MIPS32) - ce qui est in fine le cœur du sujet.

Et je rajouterais qu'un offset ne s'exprime pas nécessairement en octet - là en l’occurrence il s'exprimait en unité de mot 32-bit (puisque une instuction fait toujours 4 octets).

[__sam__]

(puisque une instruction fait toujours 4 octets).

Les CPUs RISC sont marrant avec ça. Je me souviens sur SUN et sur PowerPC que pour charger une constante 32bits dans un registre (une adresse par exemple), il fallait 2 instructions. L'une pour charger la partie haute, et l'autre pour la partie basse. Venant du 68000 à l'époque je trouvais ça pas terrible comme choix de n'avoir que des instructions de 32bits exactement. Mais en fait maintenant sur 680x0 (080 pour ce qui me concerne sur mon amiga vampirisé) je me rend compte que pour charger seulement la partie haute d'un registre (opération pas mal utilisée dans la gestion des textures de quake par exemple) il manque une instruction "rapide". Comme quoi!

[SOREK]

Bonjour,

Pourriez-vous m'apporter votre aide ?

A force de lire certain article sur le sujet de l'arithmétique signée, mon esprit est un peu perdu.
Dans quelles conditions doit-on utiliser exactement l'arithmétique signée ?
Dans quels cas ne pas utiliser l'arithmétique signée ?

Actuellement dans l'écriture d'un assembleur-désassembleur pour le 6809, j'ai un sous-programme qui me calcule la valeur décimale d'une expression arithmétique d'un opérande, à la sortie de ce sous-programme, si la valeur décimale est négative, comment la traiter dans une valeur d'offset dans un adressage indexé à déplacement constant 5, 8 ou 16bits ?

Exemple :

Code : Tout sélectionner

00244   CRTC     EQU  -8      ;
00245                         ;
. .                           ;
00758            STA  CRTC,U  ;

A la ligne 00244 mon programme va stocker dans la constante CRTC la valeur $FFF8 (correspondant à la valeur -8)

A la ligne 00758 pour le calcul de l'opérande CRTC,U la valeur $FFF8 de CRTC vaut en décimal 65528

Et donc cette valeur n'arrive pas dans un des trois cas ci-dessous et je sort donc en erreur :

• Entre [-16 et 15] je l'associe à l'adressage Indexé avec offset en 5 bits
  Entre [-128 et -17] ou entre [16 et 127] je l'associe à l'adressage Indexé avec offset en 8 bits
  Entre [-32768 et -129] ou entre [128 et 32767] je l'associe à l'adressage Indexé avec offset en 16 bits

Je dois louper une étape mais laquelle ?

D'avance un immense merci.
Bonne journée et bon courage.
Richard SOREK

[Daniel]

La même question a été posée quatre fois en deux jours, dans trois fils de discussion différents.

[fneck]

J'ai essayé de regrouper tout ce qui concerne cette demande ici, dans un topic dédié et avec un titre qui va bien.

@ Richard, merci de continuer ici

[SOREK]

C'est vrai, mais pour l'instant, personne ne m'apporte de véritables réponses, toutes les réponses reçues pour l'instant sont trop générales ou évasives.

Peut-être cela provient de moi, je n'arrive peut-être pas à comprendre ce que l'on me dit ?

C'est pour cela que j'essaye d'avoir plusieurs "son de cloche", et peut-être quelqu'un m'apportera une réponse claire !

Je n'arrive pas à accéder au regroupement de mes questions proposé par fneck

Bonne journée à tous
Richard

[__sam__]

C'est vrai, mais pour l'instant, personne ne m'apporte de véritables réponses, toutes les réponses reçues pour l'instant sont trop générales ou évasives.

Heuu.. tu as lu ma réponse ? Ou alors tu ne l'as pas comprise ?

Bon je te ré-explique une 2e fois. Ton erreur est de ne pas avoir vu que $FFF8 (65528 en décimal 16 bits non signé) et -8 (décimal encore, mais signé ce coup ci) sont la même chose, le même entier natuel mathématique mais représenté suivant des encodages différents. Donc quand tu cherches à faire entrer 65528 dans les intervales, c'est l'entier mathématique qu'il faut utiliser, à savoir -8 et pas 65528.

L'algo est donc toujours le même:

1. tu convertis ton entier 16bits (65528) en version signée. Ici on s'appercoit que 65528 a le bit 15 à 1 car 65528 & 32768!=0 (ou encore 65528>=32768, il y a pleins de façon de tester le MSbit), donc c'est un entier signé négatif. On obtient la version signée négative en soustrayant 65536: 65528 - 65536 = -8. Ok notre valeur 16 bits est donc la valeur signée -8
2. tu trouves dans quel intervale cette valeur signée tombe. Ici c'est -16..15.
3. tu utilises l'encodage relatif à cet intervale dans l'instruction machine.

C'est clair ?

[hlide]

Essaye donc de poser la question à Siri... j'ai bien cru que l'on avait affaire à un bot spammeur.

Moi, j'ai très bien compris la réponse de __sam__ et elle me parait bien suffisante (au sens positif, hein !). Et ça me surprend pour quelqu'un qui se fait un assembleur qu'il ne soit pas au fait de ces choses-là.

Vu que le 6809 utilise un adressage 16-bit, ton $FFF8 entre bien dans l’intervalle possible d'un nombre signé sur 5-bit. Pour d'autres adresse, tu auras peut-être un peu plus de chance de mettre sur 8-bit. Tu pourras mettre toutes les adresses avec du 16-bit. On couvre tous les cas d'adressage. Parce que ton adresse 16-bit fonctionne avec un adressage signé sur 16-bit sur toute la plage possible d'adresse.

Où est donc le problème ?

Le CPU se fiche de savoir si c'est signé ou pas, pour lui une adresse, c'est juste un tas de 16 bits qui peut se lire en décimal signé ou non signé au choix de l'humain qui a tendance à chercher midi à quatorze heures.

Le problème serait différent si l'adressage se faisait sur plus de 16-bit, mais ce n'est pas le cas avec un 6809, non ?

Alors où est le problème ?

[hlide]

Ah, tu veux savoir comment on choisit l'instruction ?

Code : Tout sélectionner

c++:

auto imm = short(value); // l'adresse est modulo 2^16 donc on fait une extension du signe au delà du bit 15

if (unsigned(imm + 16) < 32u) // inside [-16..15] (2^5 == 32)
    encode5bitIndexedInstruction(value);
else if (unsigned(imm + 128) < 256u) // inside [-128..127] (2^8 == 256)
    encode8bitIndexedInstruction(value);
else
    encode16bitIndexedInstruction(value);

qui est équivalent à :

Code : Tout sélectionner

c++:

auto imm = unsigned short(value); // l'adresse est modulo 2^16 donc on fait une extension de zéro au delà du bit 15

if ((imm + 16u) < 32u)
    encode5bitIndexedInstruction(value);
else if ((imm + 128u) < 256u)
    encode8bitIndexedInstruction(value);
else
    encode16bitIndexedInstruction(value);

[fneck]

Je n'arrive pas à accéder au regroupement de mes questions proposé par fneck

Des messages ont été effacés car ils semblaient être en double dans différents topics. Si ce n'était pas le cas, je te demande de nous excuser, et n'hésite pas à reposer tes questions ici-même.

[SOREK]

Un grand merci à __sam__ et aux autres

J'avoue, vais un peu de mal à comprendre, je n'est pas le résonnement d'un programmeur travaillant en C, je travail sous Visual Basic 4.0.

Pour le codage en arithmétique signé, j'avais bien compris avant, mais je n'arrivais pas à l'appliquer dans mon source P30RS09.

Mon problème était, je dis bien "était"

Code : Tout sélectionner

00244   CRTC     EQU  -8      ;
00245                         ;
. .                           ;
00758            STA  CRTC,U  ;

A la ligne 00244 mon assembleur stockait dans la constante CRTC la valeur $FFF8 (correspondant à la valeur -8)
Puis plus loin en 00758 pour le calcul de l'opérande CRTC,U la valeur $FFF8 valais en décimal 65528 et je sortait en erreur car cette valeur ne passait pas dans un des trois cas.

La solution que j'ai opéré est : comme en adressage indexé on est obligatoirement en arithmétique signé :

--- Pour toutes les valeurs (constantes ou après calculs) si la valeur n est < -32768 exemple n = $7FE0 soit -32800 en non signé
Je recalcule la valeur en faisant 65536 + la valeur de n , ce qui fait dans 65536 + (-32800) = 32736 en signé = $7FE0

---- Pour toutes les valeurs (constantes ou après calculs) si la valeur n est > 32767 cas de mon exemple n = $FFF8 = 65528 en non signé
Je recalcule la valeur en faisant (65536 - la valeur de n) x -1 , ce qui fait dans (65536 - 65528) = -8 en signé = $FFF8

et alors là, la valeur qui avait été stocké en début de listing par CRTC EQU -8 passe bien dans un des cas ci-dessous sans erreur.
--- Entre [-16 et 15] je l'associe à l'adressage Indexé avec offset en 5 bits
--- Entre [-128 et -17] ou entre [16 et 127] je l'associe à l'adressage Indexé avec offset en 8 bits
--- Entre [-32768 et -129] ou entre [128 et 32767] je l'associe à l'adressage Indexé avec offset en 16 bits

En appliquant ces deux opérations cela fonctionne, j'arrive bien à calculer les offsets.

La réalisation du désassembleur et de l'assembleur P30RS09 en VISUAL BASIC 4.0 sont terminé à 99% il me reste qu'à terminer la doc programme et l'interface utilisateur.

Mon assembleur P30RS09 devra être testé par d'autres personnes.

Le problème est qu'actuellement mon P30RS09 ne tourne que sous Windows XP.
Je n'ai pas une version de VISUAL BASIC tournant sous Windows 7, d'ailleurs je recherche un CD d'une telle version !

Dans quel temps je mettrais à disposition ce programme sur ce site, ainsi que mon livre de 230 pages sur le 6809 et ses périphériques (corrigé des fautes d'orthographe).

Un grand merci à tous !
Richard