|
Anzeige
|
Problem mit atomic FunktionenIch hab mal versucht, die neuen atomic Funktionen des WINAVR zu benutzen. Der Code wird auch korrekt compiliert, aber es gibt leider eine Fehlermeldung: ATOMIC.C: In function 'test': ATOMIC.C:10: warning: control reaches end of non-void function Hier der Code:
Peter
Gast
#1098283
Nur mal als Anmerkung:
Das nutzen eines Backslash hier ist wirklich eine üble Unsitte, die sich unter Windows-Programmierern leider eingebürgert hat. Der Backslash dient in C (und auch im PreProcessor) eigentlich als Escape.
Gast
#1098289
ich habe zwar keine ahnung was das atomic auf einem Atmel macht aber die
Warnung kommt weil die Funktion ein ende ohne return hat.
int test( void )
{
ATOMIC_BLOCK(ATOMIC_FORCEON){
return var;
}
return 0;
}
jetzt sollte die Warnung weg sein.
Peter wrote: > ich habe zwar keine ahnung was das atomic auf einem Atmel macht Du hast also bisher noch nie Interrupts benutzt? Atomic macht die notwendige CLI/SEI-Klammerung für den Zugriff auf Interruptvariablen im Main. > jetzt sollte die Warnung weg sein. Sieht zwar etwas irritierend aus, aber die Warnung ist weg. Das "return 0;" wird auch wieder wegoptimiert. Peter
Gast
#1098296
>aber die Warnung kommt weil die Funktion ein ende ohne return hat.
Genaugenommen kommt die Warnung wohl, weil der Compiler nicht versteht,
daß return(var) immer erreicht wird.
Oliver
Gast
#1098299
> > ich habe zwar keine ahnung was das atomic auf einem Atmel macht > Du hast also bisher noch nie Interrupts benutzt? Doch habe ich, aber ich ziehe es bisher vor, selber zu entscheiden wenn ich die Interrupts abschalte und wann nicht. Peter wrote: > Doch habe ich, aber ich ziehe es bisher vor, selber zu entscheiden wenn > ich die Interrupts abschalte und wann nicht. Eigentlich wollte ich mit den atomic Funktionen die Lesbarkeit verbessern. Aber das "return 0;" ist kontraproduktiv, weil es suggeriert, es könnte 0 statt val zurückgegeben werden. Peter
Gast
#1098326
dann mach es mit
int test( void )
{
int tmp;
ATOMIC_BLOCK(ATOMIC_FORCEON){
tmp=var;
}
return tmp;
}
Gast
#1098327
oh da kommt bestimmt die Warnung das eine nicht initalisierte Variable genutzt wird. Also 2. Versuch
Peter Dannegger schrob:
>
Ist das denn überhaupt sinnvoll? Wenn zB der Block vor dem return ein CLI und danach ein SEI einfügt, dann wird das SEI nie mehr ausgeführt (bzw, Restaurierung des I-Flags). BTW dürften das keine Funktionen sein sondern Makros, also einfach mal anschauen was der Präprozessor draus macht bzw. ein Blick in die Doku wagen. Das Atomic-Zeug ist wohl für blöcke gedacht, die die schliessende } auch erreichen und nicht per goto oder return oder sonstwas den atomic block verlassen. Johann L. wrote: > Wenn zB der Block vor dem return ein CLI und danach ein SEI einfügt, > dann wird das SEI nie mehr ausgeführt (bzw, Restaurierung des I-Flags). > > BTW dürften das keine Funktionen sein sondern Makros, also einfach mal > anschauen was der Präprozessor draus macht bzw. ein Blick in die Doku > wagen. > > Das Atomic-Zeug ist wohl für blöcke gedacht, die die schliessende } auch > erreichen und nicht per goto oder return oder sonstwas den atomic block > verlassen. Nicht nach der Dokumentation: These macros operate via automatic manipulation of the Global Interrupt Status (I) bit of the SREG register. Exit paths from both block types are all managed automatically without the need for special considerations, i. e. the interrupt status will be restored to the same value it has been when entering the respective block. Man beachte hier das > Exit paths from both block types are all managed automatically Wie das genau erreicht wird, habe ich mir aber noch nicht angeschaut. Stefan Ernst schrob: > Nicht nach der Dokumentation: > These macros operate via automatic manipulation of the Global Interrupt > Status (I) bit of the SREG register. Exit paths from both block types > are all managed automatically without the need for special > considerations, i. e. the interrupt status will be restored to the same > value it has been when entering the respective block. > > Man beachte hier das >> Exit paths from both block types are all managed automatically > > Wie das genau erreicht wird, habe ich mir aber noch nicht angeschaut. Stimmt, wird recht geschickt über __attribute__((_cleanup_)) gemacht, sehr interessant das. Kannte ich noch garnicht.
Jedenfalls wird korrekter Code erzeugt, und IMHO kommt die Warnung hier fälschlicher Weise, wenn es auch nichst einfach sein dürfte das im Compiler zu fixen; dazu müsste die Warnung in einem späteres Pass kommen als sie es jetzt tut.
Gast
#1098696
> Stimmt, wird recht geschickt über __attribute__((cleanup)) gemacht, > sehr interessant das. Kannte ich noch garnicht. Ist an sich das RAII-Prinzip, wie es in C++ gerne eingesetzt wird. In C (mit gcc) muß man sich halt mit dem cleanup-Attribut helfen, weil es da keine Destruktoren gibt. > int test( void ) > { > for ( uint8_t sreg_save __attribute__((__cleanup__(__iSeiParam))) = 0, > __ToDo = __iCliRetVal(); __ToDo ; __ToDo = 0 ){ > return var; > } > } > > Jedenfalls wird korrekter Code erzeugt, und IMHO kommt die Warnung > hierfälschlicher Weise, Ich schätze, er erkennt nicht, daß die for-Schleife immer genau einmal ausgeführt wird.
Gast
#1188616
Woher bekommt man denn die atomic.h Datei? Antwort schreiben |
Anzeige
|
