Bonjour à tous et à toutes
Les microcontroleurs n'exécutent que des instructions qui sont décodées en langage machine (binaire).
Ainsi, au niveau de la mémoire, le contenu d'une adresse est sous forme d'une suite binaire qui peut être interprété selon le type de la donnée : signé ou non!
Ma question est : comment le µC connait d'avance le type de la variable pour qu'il puisse faire l'opération correspondante ?
Merci d'avance
Je ne suis pas sûr si cela réponds à ta questions mais je tente...
Le µC ne connait même pas le mot "variable"... C'est le compilateur qui décide au moment de la compilation quel mnémonic il faut prendre pour p.ex. la comparaison, selon que la variable est signée ou pas. Si tu codes en assembleur c'est à toi de bien lire le instruction set et choisir ce qu'il faut.comment le µC connait d'avance le type de la variable pour qu'il puisse faire l'opération correspondante ?
Dernière modification par gienas ; 04/07/2013 à 18h02. Motif: Titre
Merci de votre réponse
Ces informations existent déjà dans les instructions à décoder?
Est ce qu'il y a des mnémonique qui désignent le type et par la suite le µC les prend en considération lorsqu'il effectue des opérations arithmétiques?
A+
Re : La représentation des données sur microcontrôleur
Bonsoir narakpvysics et tout le groupe
Hum! Je ne suis pas sûr de bien comprendre ta question, même suite aux bonnes réponses déjà données.Envoyé par narakphysics
D'abord, le mnémonique est inconnu par la machine, qui ne connait que des "codes" (instructions), que chaque constructeur traduit en lui attribuant un mnémonique supposé être plus parlant pour l'utilisateur humain qui va programmer en langage machine.
Les instructions élémentaires ne comportent aucune ambigüité, il suffit de lire la définition de chaque instruction dans la datasheet du μC utilisé pour lever le doute éventuel. Certaines instructions supposent du signé, d'autres non.
Le mieux, pour mieux cerner la véritable question et adapter les réponses, c'est de donner un exemple précis et concret des opérations visées, ainsi que la cible.
En langage évolué, C par exemple, la question ne se pose plus (je pense), puisqu'il faut explicitement déclarer le type de variable traitée, ce qui évite d'avoir à se poser des questions.
J'ai peut-être mal compris, c'est pourquoi plus de précisions et des exemples lèveront tes doutes et les nôtres.
Bonsoir gienas et merci de votre réponse
J'ai pas un cas pratique mais juste j'aimerai bien comprendre comment le µC effectue les opérations tout en prenant en considération l’architecture interne.
Si on prend le langage C, il y a plusieurs type des variables : byte, short, char, int, float, double, unsigned short ...En langage évolué, C par exemple, la question ne se pose plus (je pense), puisqu'il faut explicitement déclarer le type de variable traitée, ce qui évite d'avoir à se poser des questions.
au contraire, si on on prend les instructions assembleurs, par exemple, pour effectuer l'addition, il y a que des instruction qui le fait sur la taille 16 ou 32 bits alors qu'il y a aucune information sur le signe ?!!
Autre question : pourquoi le langage évolué, comme C, offre plusieurs type alors que l'assembleur non plus ?
A+
Dernière modification par narakphysics ; 04/07/2013 à 20h46.
faire une addition (par exemple deux octets ensemble) ne prédispose nullement de savoir si on a affaire à des octets signés ou non signés(de l'intérêt de la représentation en complément à 2 +1 pour les octets négatif !).
C'est au niveau du positionnement des flags internes du µC que l'on dira, en les testant, si on parle en signé ou en non signé.le µC, dans 99,99% des cas ne connait que des entiers. Et c'est le compilateur qui vient faire exécuter une "cuisine" (donc un sous programme) pour additionner deux flottants ! C'est pour ça qu'utiliser une variable flottante pour représenter un entier est une ineptie qui surcharge le µC et peut entrainer des gags (enfin des bugs !) mémorables .pourquoi le langage évolué, comme C, offre plusieurs type alors que l'assembleur non plus ?
Par exemple si on teste qu'un flottant qui part de 0 et qui est incrémenté de 1 un certain nombre de fois atteint la valeur 69 ...... on risque d'attendre très longtemps !
J'aime pas le Grec
Exactement. Pour une addition on a pas besoin de savoir, pour une multiplication par contre c'est important. Et là le compilateur (ou l'utilisateur s'il programme en ASM) va effectivement choisir des mnémonic différents selon la situation. Même chose pour les comparaisons.faire une addition (par exemple deux octets ensemble) ne prédispose nullement de savoir si on a affaire à des octets signés ou non signés(de l'intérêt de la représentation en complément à 2 +1 pour les octets négatif !).
Euh, entre nous DAUDET78:Ce n'est pas plutôt le complément à 1 + 1 ou alors le complément à 2 tout court (sans +1)? Pardon, je cherche la petite bête mais ça peut avoir son importance.complément à 2 +1 .
Un µP est bête. Tout ce qu'il sait faire c'est additionner deux valeurs de 8 bits (si on parle d'un processeur 8 bits genre Atmel AVR ou 32 bits si on parle PC etc...). Il y a des cas ou additionner deux valeurs de 8 bits c'est exactement ce que veut faire l'utilisateur, dans ce cas il choisira (u)int8_t et le compilateur traduira l'addition a+b; directement en ADD r16,r17 (r16 et r17 au pif et j'omets volontairement la partie chargement des valeurs depuis la RAM et réécriture dans cette dernière). Par contre il y a des jours ou l'utilisateur veut additionner des valeurs de 32 bits p.ex. parce que calculer sur 8 bits ce n'est pas toujours suffisant. Dans ce cas le compilateur ne poura pas traduire directement, mais comme le dit DAUDET78 il va sortir une "recette de cuisine" c'est-à-dire qu'il va décomposer tout le travail en petites portions que le µP sait faire (chaque portion = un mnémonic). Par exemple pour nos 32 bits cela pourrais donner genrepourquoi le langage évolué, comme C, offre plusieurs type alors que l'assembleur non plus ?
Tu vois bien: Plusieurs instructions. Si l'utilisateur veut faire des choses encore plus complexes p.ex. travailler avec des réels (donc des nombres avec virgule) ou faire des divisions là le compilateur aura plus de travail mais fera encore la même chose: Décomposer en petites tâches que le µP sait faire. Or il est evident que plusieurs instructions prennent plus de temps qu'une seule, d'où l'intérêt de choisir toujours la taille de variable la plus petite possible et d'où l'intérêt de proposer plusieurs types de variables au niveau du compilateur. J'espère que c'est clair, je genre de trucs fondamentaux ce n'est pas toujours évident à expliquer / à comprendre...Code:add r16, r20 adc r17, r21 adc r18, r22 adc r19, r23
C'est tout à fait vrai mais un peu HS, n'embrouillons pas le TO avec ce genre de "détails" pour le moment...Par exemple si on teste qu'un flottant qui part de 0 et qui est incrémenté de 1 un certain nombre de fois atteint la valeur 69 ...... on risque d'attendre très longtemps !
Bonsoir,
une précision : tant que la donnée est inférieure ou égale à celle de l'ALU le temps d’exécution est le même, il en va de même pour les flottants s'il existe une FPU.
Pour certains µC (T800) il était même plus rapide de multiplier en flottant qu'en entier(24 bits au lieu de 32) et pour en rester aux flottants certains (DSP Texas famille C30 C40..)utilisent des formats internes propriétaires qui font que les résultats des calculs varient suivant que celui ci est mené entre registres ou au moyen de variables stockées en mémoire .
Et pour finir la même donnée peut être interprétée de façon différente au gré du programmeur (cast ou union en c) mais jamais le µC ne sait ce qu'il manipule et l'adresse de celle ci ne renseigne en rien sur sa nature.
JR
l'électronique c'est pas du vaudou!
Merci à tous et à toutes de vos réponses
Donc c'est le compilateur qui se charge de la traduction de chaque définition d'une variable en des instructions bien définies pour que le µC puisse savoir d'où s'arrête la représentation de la valeur (l'état électrique de la mémoire).
Autre question :
Pour déclarer un pointeur, on utilise la définition :
ici on spécifie le type.Code:type * ponteur;// ex : char * ponteur;
Donc lorsqu'on définie une variable :
implicitemement, dans la chaine de compilation cette ligne sera traduite par exemple par :Code:char mychar;
Est ce juste ?Code:char * ponteur;//pointeur pointe sur l'adresse de mychar
Bonjour,
Je ne connais pas le C, mais si tu écris systématiquement "ponteur" au lieu de "poInteur", tu auras des erreurs à la compilation.
Seuls les faucons volent. Les vrais restent au sol.
ba non 'ponteur' ici est juste le nom de la variable, tu peux blabla ou truc ca ira aussi... c'est le '*' qui indique que c'est un pointeur...
Pour la question, tu indique pas le lien entre mychar et le pointeur...
si tu veux que ponteur recoit l'adresse de mychar tu dois lui donner sa valeur..
ponteur=&mychar;
De mémoire, & signifiant l'adresse de..! Synthaxe A vérifier!
Là où va le vent...
Bonjour à tous
Je confirme.
*ponteur est l'objet pointé;
ponteur "cache" l'adresse ou le moyen d'atteindre l'objet pointé, et les opérations arthmétiques sur les pointeurs et objets pointés tiennent compte des particularité de chacun.
ponteur + 1; /* va pointer l'objet suivant dans le tableau quelle que soit sa taille et qui est définie par sa déclaration et le compilateur */
*ponteur + 1 ; /* ajoute 1 à l'objet pointé quel que soit son type */
