Hallo,
ich habe ein Problem mit dem freien SDCC Compiler. Ich setzte als IDE
Visual Studio ein, und lasse mir über ein Makefile mittels SDCC die
C-Dateien übersetzten. Controller: AT89C51CC03 Nun bekomme immer die
Warnung:
1>main.c:67: warning 110: conditional flow changed by optimizer: so said
EVELYN the modified DOG
Ich habe bereits in Erfahrung gebracht, dass der Compiler an dieser
Stelle etwas unsauber arbeitet, und nicht erkennt, wenn z.B. die
Variable einer Fallunterscheidung (SWITCH/CASE) in einer Interrupt
Routine verändert wurde.
Nun würde ich gerne von einem Profi wissen, wie ich am besten die
Optimierung für die Funktion die diese Fallunterscheidung enthält
deaktiviere. Irgendwie hat der Zusatz volatile bei der Variablen auch
nicht geholfen.
DANKE und Beste Grüße an alle Besucher der Foren und das Team von
www.mikrocontroller.net
TOM
Hallo,
eigentlich wollte ich gerne wissen, wie die Optimierung generell für ein
File bzw. eine Funktion abgeschaltet werden kann. Aber wenn unbedingt
Code gewünscht ist:
habe es auch schon mit diesen Pragmas versucht:
#pragma save /* save the current settings */
#pragma nogcse /* turnoff global subexpression elimination */
#pragma noinduction /* turn off induction optimizations */
----- C Code ------
#pragma restore /* turn the optimizations back on */
versucht, aber die Warnung mit der Optimierung verschwindet nicht!
Beste Grüße
TOM
die Warnung hat nicht mit voaltile oder Interrupts zu tun
cmd5 = NOP;
du änderst den wert, den du für das Switch verwendest. Was erwartest du
dann als Ergebnis?
Soll er dann den passenden Case ausführen oder nicht?
Hallo,
der CASE NOP würde dann als nächstes durchlaufen, wenn sich cmd5 nicht
mehr ändert. Aber das ist alles nicht mein Problem! Ich möchte die
Optimierung verhindern. Oder das ganz so umbauen, dass keine Optimierung
mehr stattfindet, aber ohne den Switch in der Funktion zu ändern.
Gruß
TOM
Peter II schrieb:> du änderst den wert, den du für das Switch verwendest. Was erwartest du> dann als Ergebnis?
Das kann aber nicht das Problem sein.
Das ist genau geregelt, wie das abläuft.
Der Wert von cmd5 wird genau hier
1
switch(cmd5)
einmalig ausgewertet und danach entschieden, welcher case anzuspringen
ist. Was danach mit cmd5 weiter passiert, ist für den switch
uninteressant.
Wenn das ein Problem wäre, dann hätten Millionen von Statemachines ein
ernstes Problem.
Tom schrieb:> 1>main.c:67: warning 110: conditional flow changed by optimizer: so said> EVELYN the modified DOG>> Ich habe bereits in Erfahrung gebracht, dass der Compiler an dieser> Stelle etwas unsauber arbeitet, und nicht erkennt, wenn z.B. die> Variable einer Fallunterscheidung (SWITCH/CASE) in einer Interrupt> Routine verändert wurde.
Das wäre aber schon ein Grund, mal ein ernstes Wörtchen mit dem
Compilerbauer zu sprechen. Solche Probleme dürfen in einem
professionellen Compiler nicht vorkommen.
> Nun würde ich gerne von einem Profi wissen, wie ich am besten die> Optimierung für die Funktion die diese Fallunterscheidung enthält> deaktiviere.
musst du in der Doku zum Compiler nachsehen.
Hast du schon mal probiert, mit einer Zwischenvariablen zu arbeiten?
1
tmp=cmd5;
2
switch(tmp){
3
....
spätestens jetzt darf der Compiler das volatile bei cmd5 nicht mehr
ignorieren. Wenn doch, dann verlang dein Geld zurück.
Hallo,
danke Karl-Heinz für die Klarstellung in Bezug auf den Switch! Ich habe
gerade eine Zwischenvariable probiert, leider auch ohne Erfolg. Der SDCC
ist ein freier Compiler, daher leider keine Chance auf Regress! ;-)
http://sdcc.sourceforge.net/
wenn ich:
1
.....
2
switch(4)
3
{
4
caseCMD_STOPP:(CMD_STOPPistderwert4)
5
.....
verwende dann läuft es durch! Aber was soll das, dann brauche ich keinen
Switch! In diesem Fall könnte er dann sinnvoller Weise wirklich den
Switch wegoptimieren! Naja, muss wohl mal eine neuere Version des SDCC
versuchen aufzutreiben.
Danke für die Mithilfe bis hier hin.
TOM
Karl Heinz schrieb:> Solche Probleme dürfen in einem professionellen Compiler nicht> vorkommen.
Genau das dürfte beim SDCC nicht der Fall sein: mit dem Bau dieses
Compilers verdient sich keiner seine Brötchen.
Allerdings verwechselst du wohl gerade „professionell“ mit
„qualitativ hochwertig“, fürchte ich. Es gibt ausreichend
professionelle Software, die letzteres eher nicht ist …
(Trotzdem sollte der Compiler im 21. Jahrhundert natürlich in der
Lage sein, “volatile” ordentlich zu verarbeiten.)
Hi,
sorry Leute! Ich muss alles zurücknehmen! Der Optimierer hatte recht!
Irgendwo im Projekt habe ich den Code
1
....
2
wait--;
3
}
4
else
5
{
6
if(!(cmd5==NOP))
7
{
8
doMot5();
9
}
10
}
11
....
gefunden, so dass der CASE NOP nie ausgeführt wurde! Ich habe diesen
CASE entfernt, und der Compiler läuft durch!
Tja bei fremdem Code sollte man halt genauer hinschauen! Sorry für die
Verschwendung eurer Zeit!
Falls aber jemand weiß wie (#Pragma oder anders) man die Optimierung für
Funktionen, Module, Dateien und generell abschalten kann, so wäre ich
über diese Info dankbar. In der Doc habe ich nichts derart gefunden,
oder überlesen!
Beste Grüße
TOM
Tom schrieb:> die Optimierung für> Funktionen, Module, Dateien und generell abschalten kann
Man schaltet sie nicht ab, denn es gibt immer eine Möglichkeit Code ans
Laufen zu bekommen mit eingeschalteter Optimierung.
Wenn Code mit eingeschalteter Optimierung nicht läuft, dann ist er
fehlerhaft (= verstößt gegen den Standard).
Rabe schrieb:> Wenn Code mit eingeschalteter Optimierung nicht läuft, dann ist er> fehlerhaft (= verstößt gegen den Standard).
Bei korrekt arbeitenden Compilern muss das so sein. Bei GCC wohl keine
Frage.
Bei SDCC würd ich das aber nicht unterschreiben.
Und bevor man die Entwickler da mit einen Bugreport für irgendeinen
seltenst auftretenden Grenzfall nervt: Lieber etwas umformulieren, oder
mit (RTFM)
#pragma nogcse
#pragma noloopreverse
#pragma nooverlay
usw. usf.
Exakt die Optimierung verhindern, die Probleme macht.
