Bonjour,
je programme en C, et afin d'optimiser le "gain de place" au point de vue du programme, je souhaiterai déclarer 2 variables, "ligne" qui aura pour valeur un nombre entier de 0 à 7 et "batt" qui aura pour valeur 1,2 ou 3.
Comment me conseillez vous de déclarer ces 2 variables?
Merci d'avance
Bonne journée
Salut,
Le format qui prend le moins de place c'est short int (2 octets) et sa suffit largement vu les valeurs que tu va donner à tes variables
Je te remercie...
Si tu veux vraiment gagner un max de place, tu peux les déclarer comme des champs de bits (bit field). Un octet devrait suffire en tout et pour tout.
A+
Merci pour le conseil jack...mais pourrais tu etre plus clair...
un exemple par exemple...
merci d'avance
http://www.tastalian.org/scar/article-100.html
4 bits pour mémoriser ligne et 3 bits pour mémoriser batt, ça doit tenir dans un octet tout ça !
A+
Je viens de relire en détail le lien que je viens de te donner. Il y est dit que les bitsfields sont stockés dans l'unité de stockage élémentaire, c'est à dire un int, en principe 16 bits sur un petit µContrôleur.
Du coup, aucun intérêt finalement à utiliser les bitfields. 2 octets suffiront:
A+Code:unsigned char ligne, batt;
Je te remercie pour ces infos.
A bientôt.
Fais des MACRO SET et GET pour chacune de tes variables ... donc 1 octet pour tes 2 variables, et pas de déclaration tordue ...
Tu gagne 1 octet de RAM, mais ton code est plus lent et plus gros ... à toi de voir si ça vaut le coup ...
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Je ne te suis pas trop. Tu peux détailler?Envoyé par Seb.26
Fais des MACRO SET et GET pour chacune de tes variables ... donc 1 octet pour tes 2 variables, et pas de déclaration tordue ...
Tu gagne 1 octet de RAM, mais ton code est plus lent et plus gros ... à toi de voir si ça vaut le coup ...
A+
Salut à tous
A mon avis les champs de bits sont codés par défaut sur 8 bits sur les pics (les articles de tastalian sont plutôt sur la programmation sur pc). Mais pour en être sûr il faut faire un sizeof( nom_champ_bit ).
Et de toute façon je pense que le µp fait un masque à chaque fois qu'on utilise les champs de bits. Et pour ne pas s'emmêler les pinceaux, on peut effectivement faire des macros de ce genre:
(Avec variable en unsigned char regroupant [0;batt;ligne])Code:#define SET_LIGNE(valeur) variable = variable | (valeur & 0x0F) #define GET_LIGNE variable & 0x0F
( Et je pense aussi que les champs de bit sur PIC sont sur 1 octet, mais pas sûr à 100% ... disons 90% AMA )
AMA : Sauf quand il ne manipule qu'1 bit à la fois, car là les instructions dédiés existent ...Et de toute façon je pense que le µp fait un masque à chaque fois qu'on utilise les champs de bits.
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Sur mon compilo, un champ de bit peut effectivement prendre un octet (on notera que le compilateur a optimisé puisque c'est lui qui a fait le calcul et pas le programme. C'est normal d'ailleurs puisque le résultat est toujours connu à la compilation avec sizeof.
Concernant le code généré, ça marche effectivement par masque, ce qui est normal aussi.
Ex:
les 2 dernières ligne étant traduites en asm ainsi:Code:struct { unsigned char ch1:4; unsigned char ch2:3; } ch_bit; int taille; ..... taille = sizeof(ch_bit); ch_bit.ch1 = 5; ch_bit.ch2 = 2;
conclusion: c'est jouable pour optimiser la mémoire. Il faut juste vérifier sue le compilo du picCode:0003 ae01 [2] LDX #1 0005 8c [1] CLRH 0006 960000 [5] STHX taille 18: ch_bit.ch1 = 5; 0009 450000 [3] LDHX @ch_bit 000c f6 [3] LDA ,X 000d a4f0 [2] AND #-16 000f aa05 [2] ORA #5 0011 f7 [2] STA ,X 19: ch_bit.ch2 = 2; 0012 a48f [2] AND #-113 0014 aa20 [2] ORA #32 0016 f7 [2] STA ,X
A+
Dernière modification par Jack ; 02/06/2008 à 18h28.
Effectivement j'ai un peu trop généralisé. C'est sur que quand on a 1 ou 2 bits à modifier, c'est plus efficace. Mais pour ici des mots 4 bits, les masques sont plus intéressants...
( Et je pense aussi que les champs de bit sur PIC sont sur 1 octet, mais pas sûr à 100% ... disons 90% AMA )
AMA : Sauf quand il ne manipule qu'1 bit à la fois, car là les instructions dédiés existent ...
Eh bien surprise (en tout cas pour moi) MC18 (version avec optimisations encore activées) donne ça:
Code:8: struct { 9: unsigned char ch1:4; 10: unsigned char ch2:3; 11: } ch_bit; 12: int taille; 13: 14: taille = sizeof(ch_bit); 00D6 0E01 MOVLW 0x1 00D8 6EF3 MOVWF 0xff3, ACCESS 00DA CFF3 MOVFF 0xff3, 0xfdb 00DC FFDB NOP 00DE 0E02 MOVLW 0x2 00E0 6ADB CLRF 0xfdb, ACCESS 15: ch_bit.ch1 = 5; 00E2 80DF BSF 0xfdf, 0, ACCESS 00E4 92DF BCF 0xfdf, 0x1, ACCESS 00E6 84DF BSF 0xfdf, 0x2, ACCESS 00E8 96DF BCF 0xfdf, 0x3, ACCESS 16: ch_bit.ch2 = 2; 00EA 98DF BCF 0xfdf, 0x4, ACCESS 00EC 8ADF BSF 0xfdf, 0x5, ACCESS 00EE 9CDF BCF 0xfdf, 0x6, ACCESS 17: }
Marrant, il fait du bit à bit.
Je ne connais pas assez les pics pour savoir si c'est plus efficace, mais il me semble tout de même que l'utilisation d'un masque irait plus vite.
A+
Sur du 16F, il me semble qu'a part les sauts, toutes les instructions prennent 1 cycle ...
Voilà ce que donne SDCC :
NB: 0x45 = adr de la variableCode:// ch_bit.ch1 = 5; BCF 0x3, 0x5 MOVF 0x45, W ANDLW 0xf0 IORLW 0x5 // ch_bit.ch2 = 2; MOVWF 0x45 ANDLW 0x8f IORLW 0x20 MOVWF 0x45
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Comme ça ;
ça fonctionne pas ?
Code:char ligne; char batt; ligne.0 = 1; ligne.7 = 1; PORTA = ligne; ligne.0 = 0; ligne.7 = 0; PORTA = ligne; batt.0 = 1; batt.0 = 0; PORTB = batt;
Je ne vois pas comment c'est possible en C, vu qu'un identificateur ne peut commencer par un chiffre.ligne.0 = 1;
De plus l'écriture qui utilise le point (ligne.0 = 1
A+
