|
Anzeige
|
Array aus Unions - geht das?
Gast
#616095
Kann ich in C ein Array von Unions anlegen und wie greife ich darauf zu?
Ich hab es so probiert:
typedef union
{
uint16_t i16;
struct
{
uint8_t l;
uint8_t h;
}i8;
} un_i16;
volatile un_i16 ust1_data[30];
folgender Zugriffsveruch klappt nicht:
SSP1BUF=ust1_data.i8.h[3];
Was tun?
Gast
#616099
(ust1_data[3]).h ?
Gast
#616103
>(ust1_data[3]).h ?
geht mit
ansonsten halt (ust1_data[3]).i8.h ...
Gast
#616106
Danke, guter Ansatz ust1_data[3].i8.h bringt keine Fehlermeldung mehr.
Gast
#616110
die klammern brauchst du nicht:
übrigens ist das keine gute idee, auf die beiden bytes eine 16-bit wertes zuzugreifen. besser:
Gast
#616113
Doch, seine Art, auf beide Byte zuzugreifen kostet keine Rechenzeit und verbraucht minimal Speicherplatz. Das kann man bei Deiner (insbesonder die Highbytevariante) nicht behaupten.
Gast
#616115
probier es mal so SSP1BUF=ust1_data[3].i8.h; Punktrichter wrote: > Doch, seine Art, auf beide Byte zuzugreifen kostet keine Rechenzeit und > verbraucht minimal Speicherplatz. > Das kann man bei Deiner (insbesonder die Highbytevariante) nicht > behaupten. Nein, weil das Ergebnis seiner Art nirgendwo festgelegt ist und Plattform und Compiler abhängig ist. Peter's Art verbraucht "normal" optimiert vermutlich genausolange - aber man hat kein Problem mehr mit Compilerabhängigem Gedönsel
Gast
#616120
ergibt:
daran sieht man ganz deutlich, dass die union-variante vorteile hat.
Gast
#616123
hmm, wer hat denn die doppelten ;; da reingemogelt? aendert aber eh nichts...
Gast
#616128
> daran sieht man ganz deutlich, dass die union-variante vorteile hat.
nein, daran sieht man, dass dein compiler nichts taugt.
Gast
#616129
achja, kompiliert mit avr-gcc, optimierung -Os
Gast
#616130
>nein, daran sieht man, dass dein compiler nichts taugt.
dann kompilier mein beispiel bitte mal mit deinem kompiler und poste das
asm-listing
Gast
#616137
> dann kompilier mein beispiel bitte mal mit deinem kompiler und poste das > asm-listing ich zeig dir mal'n output vom IAR für ARM:
ergibt:
Gast
#616140
>ich zeig dir mal'n output vom IAR für ARM:
aendert sich was, wenn x und y auch als volatile deklariert werden?
hier mal dein beispiel mit avr-gcc:
Gast
#616143
vorweg schonmal das ergebnis von avr-gcc mit x und y als volatile:
Gast
#616145
> aendert sich was, wenn x und y auch als volatile deklariert werden?
ja, es kommt jedesmal eine instruction dazu, weil der zugriff auf die
variablen ja jedesmal neu erfolgen muss.
btw, am besten siehts aus, wenn man die variablen nicht in der funktion
hat:
kein shift und keine und-verknüpfung. globale/statische objekte mögen wohl alle compiler lieber ;-) Mich würde mal interessieren welcher Compiler den in der Praxis Probleme mit der union Variante hat. Ich benutze eigentlich auch immer die union Variante. Die für mich entscheidenden Vorteile: - Garantiert eine kurze Laufzeit (unabhängig von Qualität des Compilers...) - Deutlich übersichtlicher als die mask/shift Variante. - Bisher hatte ich noch keine Probleme ;) Was ich mir problematisch vorstelle sind big/little endian Systeme. Aber da habe ich doch das selbe Problem auch beim shiften? Wenn das Probleme verursacht gewinnt aber auch hier wieder die union Variante, dann definiert man halt zwei unions, je nach endian. Beim shiften müsste man alles direkt im Code ändern
Gast
#616149
> Was ich mir problematisch vorstelle sind big/little endian Systeme. das ist der hauptgrund, weshalb man es nicht mit unions machen sollte. > Aber da habe ich doch das selbe Problem auch beim shiften? nein, shift und andere operatoren sind unabhängig von der internen repräsentation der daten.
Gast
#616150
nungut, ich geb mich geschlagen. (avr-)gcc braucht den umweg ueber die union, um (in diesem fall) effizienten code zu liefern. das einzige, womit ich nicht einverstanden bin ist die aussage von simon: >Peter's Art verbraucht "normal" optimiert vermutlich genausolange - aber >man hat kein Problem mehr mit Compilerabhängigem Gedönsel unions sind c-standard und nicht "compilerabhaengiges gedoensel". das man sie benutzen muss, um das gleiche ergebnis wie mit teuren bezahlkompilern zu erhalten ist aergerlich, aber funktionieren tuts mit beiden. so long, déjà vu.
Gast
#616152
so mach' ich das immer :-)
déjà vu wrote:
> unions sind c-standard und nicht "compilerabhaengiges gedoensel".
Ja, unions sind c-standard. Aber nur solange, wie man auf gleichen wegen
die Daten schreibt/liest. (Sprich: über die gleiche member-variable
reinschreibt, wie man rausliest)
Wenn man unterschiedliche Union-member zum schreiben und lesen benutzt
ist das Verhalten nicht mehr im C-Standard definiert.
Gast
#616155
nachtrag: rein interessehalber, wie siehts eigentlich andersrum aus?
im gegensatz zu:
kann iar auch das optimieren?
Gast
#616156
> unions sind c-standard und nicht "compilerabhaengiges gedoensel".
ja, aber es ist nicht alles genau definiert. der compiler könnte
padding-bytes einsetzen (um zugriffe zu optimieren) und schon passen
deine bytes nicht mehr. unions sind dazu da, speicherplatz zu sparen. so
wie du sie verwendest, ist das verhalten undefiniert (auch wenn's in der
realität oft gut geht).
Gast
#616157
>Wenn man unterschiedliche Union-member zum schreiben und lesen benutzt >ist das Verhalten nicht mehr im C-Standard definiert. wieder was gelernt.
Gast
#616158
>so mach' ich das immer :-) >#define LOBYTE(x) ((x)&0xff) >#define HIBYTE(x) ((x)>>8) das geht aber so dann nicht mehr:
oder? déjà vu wrote: >>so mach' ich das immer :-) >>#define LOBYTE(x) ((x)&0xff) >>#define HIBYTE(x) ((x)>>8) > > das geht aber so dann nicht mehr: >
> oder?
Stimmt. Wozu auch? ;)
Gast
#616164
>Stimmt. Wozu auch? ;)
dann eben so:
Gast
#616165
bzw, um im kontext zu bleiben:
mir ist schon klar, dass das nicht geht; aber gibts dafuer ein sinnvolles define?
geht naemlich nicht...
Gast
#616166
oder so
:-) Peter wrote: > oder so >
> :-)
Jou, oder mit weniger Funktionalität
Gast
#616170
> Jou, oder mit weniger Funktionalität > #define MAKEHI(x) ((x) << 8) hehe, wenn 'x' ein 'char' ist, gibt das immer 0 Peter wrote: >> Jou, oder mit weniger Funktionalität >> #define MAKEHI(x) ((x) << 8) > hehe, wenn 'x' ein 'char' ist, gibt das immer 0 Mist, da hast du recht.
Gast
#616176
ok, mal ein ein konkretes beispiel(vorraussetzung: union-trick notwendig, da avr-gcc):
gaebe es da ein #define, mit dem ich das schreiben koennte:
danach suche ich naemlich schon laenger.
funktioniert wiegesagt nur als r-value, nicht als l-value.
Gast
#616178
> HIBYTE(counter)++;
;-)
Gast
#616180
und unabhaengig davon:
das mach mir erstmal einer in c nach... ;)
Gast
#616181
>#define INCREMENT_HI_BYTE(x) ((x)+=0x100)
dann bleib ich lieber bei meinem "union gedoensel" :P
Gast
#616199
> ISR(TIMER0_OVF_vect) > { > register convert16to8_t counter; > counter.u8h = soft_counter; > counter.u8l = TCNT2; > if ( (TIFR & (1<<TOV2)) && (counter.u8l < 0x7f) ) > counter.u8h++; > pitch_value = counter.u16 - pitch_counter; > pitch_counter = counter.u16; > status_set(STATUS_PITCH); >} probier mal so:
oder so (mit 8 bit variable)
ich weiss natürlich nicht ob's noch geht (wegen des TCNT2)...
Gast
#616201
beide versionen machen die ISR nur laenger, war ja auch nicht anders zu erwarten. mir gings eigentlich auch um ein universelles #define fuer r- und l-values. das man das auch "konventionell" schreiben kann, war mir schon klar. trotzdem danke, dass du dir die muehe gemacht hast, meinen code umzuschreiben. aber "lesbarer" wirds dadurch nicht wirklich. das mit dem #define waere halt schoen, da man sich die .u16 sparen koennte. aber letztlich kommts ja eh nur auf den bytecode an. und den hab ich mir schon mit komischen c-konstrukten zurechtgebogen ;) der vollstaendigkeit halber:
so long, déjà vu.
Gast
#616203
> beide versionen machen die ISR nur laenger, war ja auch nicht anders zu > erwarten. ja, schade :-( den GCC sollte man eben mit vorsicht geniessen, aber wenn man die tricks kennt... Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
