Optimierung im code ein- und ausschalten

Ein gangbarer Mittelweg ist u.U. -O1.

Auf Funktionsebene lässt sich Optimierung mittels 
Pragma/Function-Attribut umstellen -- entsprechende GCC-Version 
vorausgesetzt.

http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas

Wenn die 2 C-Instruktionen in einem separaten Sourcefile - umgewandelt 
mit der erforderlichen Optimierung - stehen, dann sollte es doch 
funktionieren.
Alternative: Assembler.

Bernhard

Alexxx schrieb:

> Was ich mich nur frage, warum GCC ohne Optimierung einen so extrem
> umständlichen Code produziert??

Weil er erst einmal nur formal den Algorithmus herunter codiert.

> Registerverschwendung und Codegröße maximal!

Dafür gibt's doch schließlich die Optimierung, deren Aufgabe ist es,
den formalen und umständlichen Code in einen möglichst kleinen und/
oder schnellen zu wandeln.  Wenn du diese aber explizit ausschaltest,
weil entweder du oder dein Debugger nicht in der Lage sind, dem
optimierten Code noch zu folgen, dann brauchst du dich doch aber nicht
beschweren: du hast es dann explizit so verlangt.

Lass die Optimierung an und gewöhn dich dran, den Code in der Form zu
debuggen, wie er später auch verwendet werden soll.  Dazu gehört halt
auch, dass man sich ein paar Methoden erarbeitet, wie man sich
dieses Debuggen organisiert, bspw. das zwischenzeitliche Einfügen von
"Fixpunkten" in den Code (z. B. Ausgabe auf IO-Port), an denen man mit
Sicherheit den Debugger auch anhalten lassen kann, oder das
vorübergehende Speichern interessanter Zwischenwerte in volatile
markierten Variablen, oder einfach das mentale Erfassen des vom
Compiler generierten Assemblercodes um zu sehen, wohin der Compiler
welche Zwischenwerte abgelegt hat, sodass man sich diese zur Laufzeit
aus den Registern kramen kann.  (Das lss-File ist meiner Meinung nach
dabei eher verwirrend denn helfend.  Viel sinnvoller ist es, ein
reines Assembler- oder Disassemblerlisting zu nehmen und den C-Code
daneben zu halten um zu sehen, was der Compiler denn so "gedacht"
hat.)

Ja, das ist Arbeit.  "Einfach mal durchsteppen" geht in der Regel dann
nicht mehr.

Wenn unsere PC-CPUs nicht so strohdoof konzipiert wären, wie es der
i386++ nun mal ist, hättest du dort genau das gleiche Problem.  Been
there, done that, auf einer Motorola m88100 RISC-CPU, viele Jahre
zuvor.

p.s.: Wenn du optimierungsunabhängig eine zeitliche Reihenfolge von
irgendwas garantieren willst, solltest du über inline asm nachdenken.
Aus diesem Grunde liefert die avr-libc in dieser Richtung bereits
einiges von Haus aus mit.  Vermutlich sollte sie das auch für das
von dir hier gewünschte Subsystem tun, das hat halt nur noch keiner
zusammengeschrieben.