AVRX und GCC -> allgemeiner Kompilierfehler

Hallo! Ich habe eine kleine Schaltung mit einem ATMega32 aufgebaut. Auf diesem AVR laufen verschiedene Tasks die mit dem freien Multitasking System AVRX und dem GCC (Vers: 24.04.2003) compiliert wurden. Mir ist jetzt folgendes aufgefallen:

Aus einem "switch-case" Statement macht der Kompiler manchmal die tollsten Sachen und zwar immer dann wenn man bei dem "case"-Teil die zugehörigen Programmteile nicht in einem Block definiert:

Wird Stellenweise falsch kompiliert: uint8_t i=2; uint8_t a=0; switch(i) { case 0: // Einsprung wenn i=0 print("i=0"); if(a) print("----"); break; case 1: // Einsprung wenn i=1 print("i=1"); if(a>4) print("====="); break; case 2: // Einsprung wenn i=2 print("i=2"); a=4; case 3: // Einsprung wenn i=2 und i=3 print("i=2 oder 3"); if(a==3) print("a=3"); break; } Wenn ich den obigen Programmteil unter AVRX ausführe, werden die "break" Anweisungen teilweise einfach über sprungen. Wenn ich die Anweisungen hinter den case-Statements aber mit "{}" blocke, wird alles richtig kompiliert:

Wird richtig kompiliert und auch ausgeführt: uint8_t i=2; uint8_t a=0; switch(i) { case 0: { // Einsprung wenn i=0 print("i=0"); if(a) print("----"); break; } case 1: { // Einsprung wenn i=1 print("i=1"); if(a>4) print("====="); break; } case 2: { // Einsprung wenn i=2 print("i=2"); a=4; } case 3: { // Einsprung wenn i=2 und i=3 print("i=2 oder 3"); if(a==3) print("a=3"); break; } }

Ist euch das auch schon mal aufgefallen?

Gruß,

Artur

Reply to
Artur Pundsack
Loading thread data ...

...

hast du dir mal den generierten ASM Source angeschaut? Die {} machen m.E. nur neue Stackframes auf, man sollte die Unterschiede im Assembler recht einfach finden. Stack ist ausreichend bemessen? Speziell auch für die printf() Funktion?

Um auf deine Frage zu kommen: noch nichts derartiges bemerkt..

Gruss Andreas

Reply to
Andreas Miesner

Hö? Wieso soll ein neuer {}-Skopus einen Stackframe erzeugen? Wofür? Ein Stackframe enthält doch den alten Base-Pointer und ne Rücksprungadresse normalerweise, beides wirklich völlig überflüssig. Finde ich macht sehr wenig Sinn... und ich glaube auch nicht das je gesehen zu haben.

Gruß Johannes

--
One can look at the designs of a bridge, realize it's built of tongue
depressers and bubble gum, and from this conclude that it is, indeed,
junk, without once having to take the actual suicidal risk of driving
across it. We do the same with your code.  Your code is crap.  [...]
                    - Kelsey Bjarnason in COLA about Jeff Relf's X.EXE
Reply to
Johannes Bauer

der Code war nur ein Beispiel. Innerhalb der einzelnen "case"-Anweisungen verwende ich kein printf(). Ich habe zunächst auch vermutet das ich den Stackbereich den ich für diesen Task reserviert habe überschritten habe und in den Stackbereich eines anderen Tasks gerutscht bin. Also habe ich den Stack für diesen Task mal vergrößert... ...brachte aber keine Verbesserung auch wenn ich andere Tasks und somit deren Stacknutzung auskommentiert habe. Seltsamer Weise tritt dieser Effekt auch nur jeweils in einem switch()-case Konstrukt auf.

Bisher ist mir das Problem auch noch nie aufgefallen. Erst seit dem ich avrX verwende tritt dieser Fehler auf. Ich denke mal das irgendwie die Taskeinsprung- adressen bei einem Taskwechsel falsch berechnet werden wenn man sich zu diesem Zeitpunkt direkt in einem switch()-case Konstrukt befindet.

Na ja, zumindest funktioniert es mit der "Blockbildung".

Artur

Reply to
Artur Pundsack

Hast recht, ich habs heute im avrgcc und msdev6 angeschaut dem ist nicht so. Hätte schwören können so etwas schon einmal gesehen zu haben. Anyway...

Gruss Andreas

Reply to
Andreas Miesner

Ich hätte dazu zwei Fragen: Tritt dieser Effekt auch im Simulator auf? Kannst du ein paar Codezeilen posten, bei denen der Fehler reproduzierbar auftritt (bisher hast du immer von "tritt teilweise auf" gesprochen")?

Gruß, Christoph

Reply to
Christoph Dittmann

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.