octet -> 2quartet

octet -> 2quartet - C - Programmation

Marsh Posté le 21-09-2005 à 12:26:49    

bonjour,
je me demandai s'il existe une maniére simple de mettre en octet en deux quartet :
 
int octet =...
int quartet1=0
int quartet2=0
 
function magique(octet, *quartet1, *quartet2)
 
merci d'avance
 
edit : quartet1 poids fort      et quartet2 poids faible    ou inversement bien sur


Message édité par schmur le 21-09-2005 à 12:34:10
Reply

Marsh Posté le 21-09-2005 à 12:26:49   

Reply

Marsh Posté le 21-09-2005 à 12:35:26    

Bonjour
Il est curieux d'utiliser un int pour stocker un octet
quartet1 = octet & 0xf;
quartet2 = (octet & 0xf0) >> 4;
le & 0xf0 devient inutile si octet est défini comme un char
 

Reply

Marsh Posté le 21-09-2005 à 13:37:18    

db__ a écrit :

Il est curieux d'utiliser un int pour stocker un octet


Pourquoi ?

Citation :


quartet1 = octet & 0xf;
quartet2 = (octet & 0xf0) >> 4;
le & 0xf0 devient inutile si octet est défini comme un char


Non, car rien ne garanti qu'un char fasse exactement 8 bits. Il peut faire plus (voir CHAR_BIT de <limits.h> ).
 
De plus , il n'est pas inutile de préciser que quartet1 reçoit le quartet LSB et quartet2 le quartet MSB.


Message édité par Emmanuel Delahaye le 21-09-2005 à 14:28:15

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
Reply

Marsh Posté le 21-09-2005 à 13:44:10    

merci j'avais pas penser a faire ca comme ca.
cette solution me plait :-)

Reply

Marsh Posté le 21-09-2005 à 14:27:02    

petite modification
quartet1 = (octet & 0xf) >>4;  
quartet2 = octet & 0xf0 ;  

Reply

Marsh Posté le 21-09-2005 à 14:29:18    

schmur a écrit :

petite modification
quartet1 = (octet & 0xf) >>4;  
quartet2 = octet & 0xf0 ;


Certainement pas. La solution de DB__ était bonne.


#include <stdio.h>
 
int main (void)
{
   unsigned x = 0xA5;
   unsigned qmsb = (x & 0xF0) >> 4;
   unsigned qlsb = x & 0x0F;
 
   printf ("x = %02X\n"
           "qmsb = %X\n"
           "qlsb = %X\n"
           , x
           , qmsb
           , qlsb);
   
   return 0;
}

Message cité 1 fois
Message édité par Emmanuel Delahaye le 21-09-2005 à 14:36:22

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
Reply

Marsh Posté le 21-09-2005 à 14:34:25    

Emmanuel Delahaye a écrit :

Certainement pas. La solution de DB__ était bonne.


mille excuse
t'as bien raison, j'a fait une erreur de frappe lors de mes testes.
desole de ma betisse ! honte à moi  :sweat:

Reply

Marsh Posté le 22-09-2005 à 12:41:57    

Bonjour
avant de faire du C j'ai fait et continue à faire de l'assembleur. Tous les processeurs que j'ai cotoyés, connaissait l'octet donc pour moi un char est un octet. Si le standard C était bien foutu (je n'en sait rien) le compilateur devrait faire en sorte que les char soient des octets et gérer les problèmes d'extension de signe lorsque le problème se pose.
si on a un unsigned char qui vaut 0xff et que l'on fait un décalage à gauche de 4 bits, le résultat devrait être 0x00f0 et non 0x0ff0 sur un unsigned char codé sur 16 bits.
Si ce n'est pas le cas, a quoi sert le type char sur un processeur ne gérant pas les octets ?
gérer économiquement sa mémoire en utilisant des char codé sur un octet au lieu de 32 (voir 64) bits pour stocker le dit octet me semble plus rationnel tant qu'on utilise pas l'unicode32.

Reply

Marsh Posté le 22-09-2005 à 13:07:40    

db__ a écrit :

avant de faire du C j'ai fait et continue à faire de l'assembleur. Tous les processeurs que j'ai cotoyés, connaissait l'octet donc pour moi un char est un octet.


Alors tu ne connais pas les DSP[1] :

 

Motorola 56156 : CHAR_BIT = 32
Texas TMS320C54 : CHAR_BIT = 16

 

et il existe des machines anciennes (PDP11 ou un truc dans le genre) avec CHAR_BIT = 9

 

Bref, le langage C, qui a vocation universelle, a prévu le cas. Il impose un minimum de 8 bits, mais pas de maximum.

Citation :


 Si le standard C était bien foutu (je n'en sait rien) le compilateur devrait faire en sorte que les char soient des octets et gérer les problèmes d'extension de signe lorsque le problème se pose.


Ca ferait rajouter du code pas forcément utile et ça nuirait aux performances. Le C considère que le char fait la taille maximale possible, il gère l'extension de signe automatiquement, mais c'est au programmeur de faire les masques nécessaire pour ignorer les bits inutiles si besoin est. (Si on utilise des unsigned, comme il est recommandé avec les opérateurs bitwise, les masquages sont en principe inutiles)

Citation :


si on a un unsigned char qui vaut 0xff et que l'on fait un décalage à gauche de 4 bits, le résultat devrait être 0x00f0 et non 0x0ff0 sur un unsigned char codé sur 16 bits.


Oui. unsigned est le mot important.
--------------------------
[1]la mémoire interne des DSP est organisée en mots de 16 ou 32 bits qui interdisent les acces 8-bits. Normal, ils sont orientés calcul et non traitement de chaine. Cependant, ils savent traiter les chaines, mais elles occupent plus de mémoire que nécessaire. C'est tout. C'est pas grave, c'est pas leur vocation.

 


Message édité par Emmanuel Delahaye le 07-03-2008 à 23:26:12

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
Reply

Marsh Posté le 22-09-2005 à 16:37:11    

impressionnant !

Reply

Marsh Posté le 22-09-2005 à 16:37:11   

Reply

Marsh Posté le 23-09-2005 à 12:23:18    

Merci Emmanuel pour toutes ces précisions.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed