Discussion :

[leffe]

qqun pourrai-til m'aider a répondre a cette question.

Sur un machine 32 bits... il faut écrire une procédure qui fait la somme de deux nombres entiers signés sur 16 bits. Cette procédure doit permettre de détecter les cas de débordements positifs et négatifs. Cette procédure devra afficher le résultat de la somme et indiquer si le résultat correspondant est correct ou est un débordement positif ou négatif.

Merci de votre aide

[Thierry Chappuis]

qqun pourrai-til m'aider a répondre a cette question.

Sur un machine 32 bits... il faut écrire une procédure qui fait la somme de deux nombres entiers signés sur 16 bits. Cette procédure doit permettre de détecter les cas de débordements positifs et négatifs. Cette procédure devra afficher le résultat de la somme et indiquer si le résultat correspondant est correct ou est un débordement positif ou négatif.

Merci de votre aide

Le langage C ne spécifie pas qu'un certain type d'entier doit occuper 16 bits en mémoire. Tout ce que dit la norme, c'est:

• un entier de type short doit pouvoir représenter une valeur entre -32767 et 32767
• idem pour un entier de type int
• un entier de type long doit pouvoir représenter une valeur entre -(2**31 - 1) et (2**31 - 1)

De plus la relation suivante doit être vérifiée:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sizeof(short) <= sizeof(int) <= sizeof(long)

Sur certaines architectures, les types short, int et long font tous les trois 64 bits. De plus, le langage C n'impose aucune contrainte sur la manière de représenter les entiers négatifs (complément à deux, complément à 1, bit de signe)

Pour détecter les débordements potentiels tu peux te servir des constantes symboliques SHRT_MIN, SHRT_MAX, INT_MIN, INT_MAX, etc. déclarées dans le fichier d'en-tête standard limits.h.

Thierry

[nicolas.sitbon]

Le langage C ne spécifie pas qu'un certain type d'entier doit occuper 16 bits en mémoire.
Thierry

int16_t ou uint16_t en C99 et biensûr un processeur compatible.
Cordialement.

[Thierry Chappuis]

int16_t ou uint16_t en C99 et biensûr un processeur compatible.
Cordialement.

Comme je n'utilise pas (ou peu, à part snprintf()) les extensions C99, j'ai tendance à les oublier...

Thierry

[Emmanuel Delahaye]

int16_t ou uint16_t en C99 et biensûr un processeur compatible.

Ce qui fait que ces types, bien que standards (C99), ne sont pas portables...

[Emmanuel Delahaye]

qqun pourrai-til m'aider a répondre a cette question.

Sur un machine 32 bits... il faut écrire une procédure qui fait la somme de deux nombres entiers signés sur 16 bits. Cette procédure doit permettre de détecter les cas de débordements positifs et négatifs. Cette procédure devra afficher le résultat de la somme et indiquer si le résultat correspondant est correct ou est un débordement positif ou négatif.

Il faut faire un additionneur binaire. L'utilisation d'un mot de 32-bit non signé (unsigned long, par exemple) permet de gérer proprement le débordement les calculs dur 16-bit.

http://www.univ-lemans.fr/enseigneme.../addition.html

http://emmanuel-delahaye.developpez.com/bits.htm

Par contre, concernant les valeurs négatives, l'énoncé est incomplet. Il faut préciser comment sont codés les nombres négatifs. (signe+amplitude, complément à 1 ou complément à 2).

[nicolas.sitbon]

Sur un machine 32 bits...

Apparamment il ne cherche pas spécialement la portabilité. Même si ces extensions de la norme C99 ne sont pas portables, elle restent néanmoins accessibles à une majorité de machine, voilà pourquoi j'ai jugé bon de les rappeler...

[Emmanuel Delahaye]

Apparamment il ne cherche pas spécialement la portabilité. Même si ces extensions de la norme C99 ne sont pas portables, elle restent néanmoins accessibles à une majorité de machine, voilà pourquoi j'ai jugé bon de les rappeler...

Justement, il y a des machines 32-bit qui n'ont pas de mots de 16-bit (DSP Freescale 56156, par exemple).

[nicolas.sitbon]

Oui je connais le dsp freescale, c'est l'exemple qui est toujours sorti quand on explique au gens qu'un octet ne fait pas forcément 8 bits, maintenant il faudrait voir avec l'intéressé s'il code sur dsp freescale, et si ça n'est pas le cas, voir si son compilateur implémente cette partie de la norme C99. On ne va pas se priver des extensions apportés par la norme C99 sous prétexte que le dsp freescale à l'octet qui fait 16 bits. Même si je sais que pour vous la norme C99 n'apporte pas de grandes nouveautés, il reste que pour moi, beaucoup de ces nouveauté sont incontournables mais tu fais bien de rappeler Emmanuel qu'il faut attention à la portabilité dans ce cas la même si je l'avais déjà préciser dès le début.
Cordialement.

[Thierry Chappuis]

Oui je connais le dsp freescale, c'est l'exemple qui est toujours sorti quand on explique au gens qu'un octet ne fait pas forcément 8 bits, maintenant il faudrait voir avec l'intéressé s'il code sur dsp freescale, et si ça n'est pas le cas, voir si son compilateur implémente cette partie de la norme C99. On ne va pas se priver des extensions apportés par la norme C99 sous prétexte que le dsp freescale à l'octet qui fait 16 bits. Même si je sais que pour vous la norme C99 n'apporte pas de grandes nouveautés, il reste que pour moi, beaucoup de ces nouveauté sont incontournables mais tu fais bien de rappeler Emmanuel qu'il faut attention à la portabilité dans ce cas la même si je l'avais déjà préciser dès le début.
Cordialement.

A mon avis, un octet fait toujours 8 bits par définition. Par contre, la taille du byte varie avec l'architecture.

Thierry

[nicolas.sitbon]

A mon avis, un octet fait toujours 8 bits par définition. Par contre, la taille du byte varie avec l'architecture.
Thierry

Non la traduction de byte en octet est un gros abus de langage qui ne date pas d'hier, c'est une erreur tout bonnement, et la norme du langage C est la pour le rappeler.
Cordialement.