Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Modérateur : mazertoc
Boite à outils nombres signés ou non ?
bonjour F6FCO,
je crois que dans ces affaires, il faut séparer les arithmétiques signées ou non.
En arithmétique non signée (pas de négatifs), la soustraction n'est définie que si le premier opérande est >= au deuxième, sinon erreur autrement ça marche toujours.
En arithmétique signée, ça se complique un peu, ton exemple marche parce qu’il est dans les limites de la machine, remarque que le résultat est à interpréter en arithmétique signée. Mais j'ai suivi le même algorithme en tentant de retrancher 0x00000003 à 0x80000000 (le plus petit négatif en 32 bits signés), j'ai obtenu 0x7FFFFFFD qui est un nombre positif , pas cool.
Je crois qu'une méthode efficace est d'ajouter un octet en haut poids de chaque opérande, de lui étendre le bit de signe d'opérer comme tu fais sur les 5 octets, Si les 9 bits de haut poids du résultat sont égaux, c'est tout bon sinon il y a dépassement de capacité de la machine. le résultat ne s'écrit pas sur 32 bits. C'es le cas de l'exemple donné plus haut, en fait, le résultat sur 40 bits est 0xFF7FFFFFFD qui est la bonne valeur sur 40 bits signés.
En fait, en info, on est en arithmétique finie, il faut toujours craindre cette finitude et informer l'utilisateur, le programmeur, qu'il demande à la machine des chose qu'elle ne peut pas faire. Il pourra toujours augmenter la précision qu'il a choisie pour ses nombres.
Cordialement
je crois que dans ces affaires, il faut séparer les arithmétiques signées ou non.
En arithmétique non signée (pas de négatifs), la soustraction n'est définie que si le premier opérande est >= au deuxième, sinon erreur autrement ça marche toujours.
En arithmétique signée, ça se complique un peu, ton exemple marche parce qu’il est dans les limites de la machine, remarque que le résultat est à interpréter en arithmétique signée. Mais j'ai suivi le même algorithme en tentant de retrancher 0x00000003 à 0x80000000 (le plus petit négatif en 32 bits signés), j'ai obtenu 0x7FFFFFFD qui est un nombre positif , pas cool.
Je crois qu'une méthode efficace est d'ajouter un octet en haut poids de chaque opérande, de lui étendre le bit de signe d'opérer comme tu fais sur les 5 octets, Si les 9 bits de haut poids du résultat sont égaux, c'est tout bon sinon il y a dépassement de capacité de la machine. le résultat ne s'écrit pas sur 32 bits. C'es le cas de l'exemple donné plus haut, en fait, le résultat sur 40 bits est 0xFF7FFFFFFD qui est la bonne valeur sur 40 bits signés.
En fait, en info, on est en arithmétique finie, il faut toujours craindre cette finitude et informer l'utilisateur, le programmeur, qu'il demande à la machine des chose qu'elle ne peut pas faire. Il pourra toujours augmenter la précision qu'il a choisie pour ses nombres.
Cordialement
Menu de routines ASM à disposition
Rebonjour F6FCO,
je ferais bien la même observation pour la routine de soustraction 16 bits, essaye 0x8000 - 0x0003, mêmes causes mêmes effets.
En fait, je suis bien ennuyé, car je travaillais sur ce même sujet quand j'ai trouvé tes posts, en témoigne celui que j'ai écrit sur l'arithmétique 8 bits signés. J'ai le même étendu à 16 bits que je n'ose plus poster.
Cordialement
je ferais bien la même observation pour la routine de soustraction 16 bits, essaye 0x8000 - 0x0003, mêmes causes mêmes effets.
En fait, je suis bien ennuyé, car je travaillais sur ce même sujet quand j'ai trouvé tes posts, en témoigne celui que j'ai écrit sur l'arithmétique 8 bits signés. J'ai le même étendu à 16 bits que je n'ose plus poster.
Cordialement
Menu de routines ASM à disposition
- F6FCO
Expert- Messages : 1413
- Âge : 70
- Enregistré en : décembre 2017
- Localisation : Furtif je suis.
- Contact :
Bonsoir JJE,
Je réponds avec du retard mais je ne suis pas à la maison tous les débuts de semaine. Et pas de pot j'ai oublié sur mon chantier la clé USB qui me suit partout et qui contient mes programmes.
Je ferai l'opération que tu préconises pour voir le résultat et mieux comprendre ton propos. Je précise que mes routines sont destinées à des nombres non-signés, j'ai développé ces opérations parce que j'avais besoin d'une soustraction 16 bits pour mes recherches sur les rampes d'accélération
Je réponds avec du retard mais je ne suis pas à la maison tous les débuts de semaine. Et pas de pot j'ai oublié sur mon chantier la clé USB qui me suit partout et qui contient mes programmes.
Je ferai l'opération que tu préconises pour voir le résultat et mieux comprendre ton propos. Je précise que mes routines sont destinées à des nombres non-signés, j'ai développé ces opérations parce que j'avais besoin d'une soustraction 16 bits pour mes recherches sur les rampes d'accélération
Menu de routines ASM à disposition
- F6FCO
Expert- Messages : 1413
- Âge : 70
- Enregistré en : décembre 2017
- Localisation : Furtif je suis.
- Contact :
JJE a écrit :Rebonjour F6FCO,
J'ai le même étendu à 16 bits que je n'ose plus poster.
Cordialement
Bonjour JJE,
Je ne comprends pas bien le sens de ta phrase, si tu n'oses pas poster ta routine parce que j'ai posté la mienne juste avant, no problem il n'y a pas de compétition entre nous , au contraire le but est de contribuer pour se faire une belle caisse à outils et plusieurs membres peuvent bien poster chacun leurs routines concernant le même problème. Perso dans ma vraie caisse à outils je dois bien avoir au moins 3 clés plates 15x17.
Les routines d'additions et soustractions que j'ai postées sont pour des calculs non signés parce que j'en avais besoin telles quelles, sur une cnc il n'y a pas de pas négatifs. Je ne me suis pas encore penché sur les nombres signés et tes routines seront les bienvenues.
JJE a écrit :bonjour F6FCO,
En arithmétique non signée (pas de négatifs), la soustraction n'est définie que si le premier opérande est >= au deuxième, sinon erreur autrement ça marche toujours.
Heuuu ! ben non çà colle dans les deux sens, je viens de refaire l'expérience en vérifiant les résultats avec la calculatrice de Windows:
Soustraction 16bits:
0x00F1 - 0x001F = 0x00D2
0x001F - 0x00F1 = 0xFF2E
Soustraction32bits:
0x0000 00F1 - 0x0000001F = 0x0000 00D2
0x0000 001F - 0x000000F1 = 0xFFFF FF2E
Pour ton exemple j'obtiens:
0x0003 - 0x8000 = 0x8003 en 16 bits
0x0000 0003 - 0x8000 0000 = 0x8000 0003 en 32bits
0x8000 0000 - 0x0000 0003 = 0x7FFF FFFD (ce qui est normal en non signé)
Je plaisante mais je comprends parfaitement ce que tu veux dire (FF peut aussi bien valoir -1 que 255 ), si on se retrouve dans cette configuration c'est sur qu'il faut partir avec des calculs en nombres signés. Il faut déterminer avant de commencer à coder si l'on risque de se retrouver avec des nombres négatifs sinon çà peut vite devenir problématique.
Menu de routines ASM à disposition
Salut F6FCO,
Imagine la situation d'un titulaire de compte bancaire dont le solde est à 100 (peu importe l'unité), il émet un chèque de 120, deux situations se présentent :
dans le deuxième cas, le chèque est refusé, souvent avec pénalité, ce qui complique la chose.
dans le premier cas, 100-120 a un sens, dans le second non.
dans le premier cas, on dispose de nombres négatifs, on est en arithmétique signée, dans le deuxième cas non, on ne peut pas effectuer l'opération 100-120 tout simplement parce qu’il n'existe pas de nombre entier qui ajouté à 120 donne 100.
Je crois que Basic traite tous les entiers comme signés (avec des étendues différentes) mais C fait la distinction et si tu déclare trois variables 8 bits signées r, a et b, que a vaut -128 (plus petit signé 8 bits) et b vaut 3 (ou n'importe quoi d'ailleurs sauf 0), écrire r = a+b t'envoie aux pelotes.
En assembleur, on n'a pas de variable typée. Toutes représentent des octets et c'est au programmeur de savoir ce qu'il met dans ces octets sachant que s'il ne s'intéresse pas aux valeurs négatives, tout simplement parce que pour son sujet elles n'ont pas de sens, il faut qu'il s'interdise les opérations impossibles comme a-b si b>a, mais c'est bien qu'il en prévienne l'utilisateur (en général par un STATUS,C à 1).
Cordialement.
Imagine la situation d'un titulaire de compte bancaire dont le solde est à 100 (peu importe l'unité), il émet un chèque de 120, deux situations se présentent :
- il dispose d'une autorisation de découvert
ou non
dans le deuxième cas, le chèque est refusé, souvent avec pénalité, ce qui complique la chose.
dans le premier cas, 100-120 a un sens, dans le second non.
dans le premier cas, on dispose de nombres négatifs, on est en arithmétique signée, dans le deuxième cas non, on ne peut pas effectuer l'opération 100-120 tout simplement parce qu’il n'existe pas de nombre entier qui ajouté à 120 donne 100.
Je crois que Basic traite tous les entiers comme signés (avec des étendues différentes) mais C fait la distinction et si tu déclare trois variables 8 bits signées r, a et b, que a vaut -128 (plus petit signé 8 bits) et b vaut 3 (ou n'importe quoi d'ailleurs sauf 0), écrire r = a+b t'envoie aux pelotes.
En assembleur, on n'a pas de variable typée. Toutes représentent des octets et c'est au programmeur de savoir ce qu'il met dans ces octets sachant que s'il ne s'intéresse pas aux valeurs négatives, tout simplement parce que pour son sujet elles n'ont pas de sens, il faut qu'il s'interdise les opérations impossibles comme a-b si b>a, mais c'est bien qu'il en prévienne l'utilisateur (en général par un STATUS,C à 1).
Cordialement.
Menu de routines ASM à disposition
Boite à outils nombres signés ou non ?
Boite à outils nombres signés ou non ?
Boite à outils nombres signés ou non ?
-
Jérémy
Administrateur du site- Messages : 2722
- Âge : 45
- Enregistré en : juillet 2015
- Localisation : Dans le sud
- Contact :
F6FCO a écrit :Source du message Non signé pour mes routines.
Oups oui non signé . lol .
Ok je fais la modif alors !
Boite à outils nombres signés ou non ?
Bonjour Jérémy,
quelques mots de commentaires bien que je pense que tu fasses la différence entre arithmétique signée et non signée
La connaissance de tous les bits d'un octet ne donne aucune information sur ce qu'il représente, c'est le programmeur qui sait ce qu'il a voulu y écrire.
imaginons qu'une variable V contienne 0x54 et W 0x63, l'instruction addwf V, f mettra 0xB7 dans V.
C'est très bien si le programme s'occupe par exemple d'un nombre d'objets (qui peut s'étendre de 0 à 255), ce n'est pas bien du tout si ce programme s'occupe d'une valeur signée, par exemple une température (comprise entre -128 et +127 du coup). Si la température d'un objet est de 84° (0x54) et qu'elle s'élève de 99° ( 0x63), à la fin de l'opération, elle sera bien à 183° mais ce nombre n'est pas représentable sur un octet signé (>128). En fait la place est déjà prise par le nombre -49 (0xB7). Il y a eu dépassement de capacité, ce qu'on maifeste généralement par le bit C de STATUS à 1. C'est ce qui se passe si dant l'exemple ci-dessus V vaut 0xA4 et W 0x63 l'instruction addwf V, f mettra 0x07dans V. Ce résultat est manifestement faux mais on en est prévenu par STATUS, C, en fait, le résultat est 0x104 qui ne tient pas sur un octet.
Le vrai problème n'est pas tellement signé contre insigné, c'est plutôt qu'on travaille dans une arithmétique finie, ce qu'on n'a pas l'habitude de faire. Dans un programme, si un calcul dépasse les capacités de la machine, il faut passer à la représentation permettant une étendue plus grande. Dans mon premier exemple, si au lieu de travailler sur des octets, je travaille sur des mots de 16 bits V = 0x0057 W= 0x0063 et le résultat est 0x0104 et tout va bien. Mais bien sûr ce n'est que reporter le problème, sauf à travailler sur des chaînes de caractères (et on butera quand même sur la taille de la mémoire) mais c'est un autre sujet sur des Pics !
Comme les micros mid-range ne connaissent pas l'arithmétique 16 bits, il est donc utile de développer les sous-programmes qui pallient leur carences.
Tu peux nommer mon sujet "Arihmétique signée 8 bits"
Cordialement
PS Je m'absente quelques jours.
quelques mots de commentaires bien que je pense que tu fasses la différence entre arithmétique signée et non signée
Jérémy a écrit :Source du message addition (signée) et soustraction ( signée) ? ca r la différence est importante .
La connaissance de tous les bits d'un octet ne donne aucune information sur ce qu'il représente, c'est le programmeur qui sait ce qu'il a voulu y écrire.
imaginons qu'une variable V contienne 0x54 et W 0x63, l'instruction addwf V, f mettra 0xB7 dans V.
C'est très bien si le programme s'occupe par exemple d'un nombre d'objets (qui peut s'étendre de 0 à 255), ce n'est pas bien du tout si ce programme s'occupe d'une valeur signée, par exemple une température (comprise entre -128 et +127 du coup). Si la température d'un objet est de 84° (0x54) et qu'elle s'élève de 99° ( 0x63), à la fin de l'opération, elle sera bien à 183° mais ce nombre n'est pas représentable sur un octet signé (>128). En fait la place est déjà prise par le nombre -49 (0xB7). Il y a eu dépassement de capacité, ce qu'on maifeste généralement par le bit C de STATUS à 1. C'est ce qui se passe si dant l'exemple ci-dessus V vaut 0xA4 et W 0x63 l'instruction addwf V, f mettra 0x07dans V. Ce résultat est manifestement faux mais on en est prévenu par STATUS, C, en fait, le résultat est 0x104 qui ne tient pas sur un octet.
Le vrai problème n'est pas tellement signé contre insigné, c'est plutôt qu'on travaille dans une arithmétique finie, ce qu'on n'a pas l'habitude de faire. Dans un programme, si un calcul dépasse les capacités de la machine, il faut passer à la représentation permettant une étendue plus grande. Dans mon premier exemple, si au lieu de travailler sur des octets, je travaille sur des mots de 16 bits V = 0x0057 W= 0x0063 et le résultat est 0x0104 et tout va bien. Mais bien sûr ce n'est que reporter le problème, sauf à travailler sur des chaînes de caractères (et on butera quand même sur la taille de la mémoire) mais c'est un autre sujet sur des Pics !
Comme les micros mid-range ne connaissent pas l'arithmétique 16 bits, il est donc utile de développer les sous-programmes qui pallient leur carences.
Tu peux nommer mon sujet "Arihmétique signée 8 bits"
Cordialement
PS Je m'absente quelques jours.
Retourner vers « Langage ASM »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 66 invités