Das kommt davon, wenn viele Leute an einem Projekt arbeiten und 
keinerlei Qualitätsmanagement vorhanden ist.

Sehe ich das richtig, dass dies bei einer früheren Version nicht so war? 
Weil dann ist es wirklich ein Hammer...

>Das ist wirklich ein dicker Hund, sowas.
>Weil dann ist es wirklich ein Hammer...

@peda:
was stört dich ?
Du hast zu keinem Zeitpunkt dem Compiler mitgeteilt, das ivar eine 
Variable ist die irgendwo anders benutzt wird (volatile). Somit DARF der 
Compiler, wenn er das Ergebnis einer Berechnung nicht ändert, 
Programmcode umstellen. Die Optimierung eine Berechnung erst 
auszuführen, wenn sie benötigt wird, hat das Potential einiges einsparen 
zu können. In deinem Mini-Beispiel tut sie es nicht. (selbst mit 
volatile wäre ich mir nicht sicher, ob der Compiler nicht trotzdem die 
Berechnung vorziehen dürfte)
C ist nicht Assembler, der Compiler darf SEHR weitgehend den 
Programmfluß ändern, wenn Ergebnisse dadurch nicht beeinflußt werden. 
Ergebnisse sind Ausgaben zur Außenwelt. Wie stark er dies tut kannst du 
dir in den GCC-internas durchlesen. Die Optimierung wird noch 
weitergehen. Es setzt allerdings voraus, zu wissen was garantiert ist 
und was nicht (C-Standard).
Das ist kein BUG sondern eine falsche Annahme von "garantierten" 
Abläufen deinerseits.
BTW: Über wieviel Takte sprechen wir hier eigentlich?

>*(volatile unsigned int *)&ivar = val;

Warum dürfte er die Berechnung von val dann nicht mehr vorziehen?

Mir ist unklar, wieso der Workaround (volatile unsigned int ivar) 
überhaupt funktioniert.

Auch ohne volatile ist der Schreibzugriff auf ivar erstens atomar und 
zweitens während der Interruptsperre.

Ist das "Zufall", d.h. kann das bei einem nicht so einfachen 
Codeschnippsel anders sein?

Peter, hast du mit Code Optimierung übersetzt und -O2, -O3 oder -Os 
benutzt?

Möglicherweise ist obiges Codebeispiel ein gutes Beispiel für die GCC 
Option -fno-reorder-blocks.

Das basiert darauf, dass durch die ASM-Makros cli() und sei() 
Blockgrenzen (Stichwort basic blocks Konzept bei Codeoptimierung im GCC) 
geschaffen werden (*). Und durch die Option das Reordering über diese 
Blockgrenzen verboten wird.

Eine neue Frage ist allerdings, wie man diese Option lokal nutzen 
könnte.

(*) Und wo in der Doku das Blocksplitting mit _asm_ dokumentiert ist. 
Ich habe bei einer kurzen Suche nur Inoffizielles gefunden:

A Practical GCC Trick To Use During Optimization
http://www.cellperformance.com/mike_acton/2006/04/...

Die Kontrolle der Position der Division hat IMHO nichts mit dem volatile 
bzw. dessen Fehlen zu tun.

Ich bin baff erstaunt, dass man durch -fno-reorder-blocks das nicht 
kontrollieren kann.

Leider steht in obigem Artikel von Mike Acton die GCC Version nicht 
drin. Vielleicht setzt _asm_ (im cli() Makro) in 4.1.1 doch keine 
Blockgrenze (mehr)?

> Mir ist unklar, wieso der Workaround (volatile unsigned int ivar)
> überhaupt funktioniert.

Weil er dann die Berechnung genau so wie angegeben machen muß.

> Auch ohne volatile ist der Schreibzugriff auf ivar erstens atomar und
> zweitens während der Interruptsperre.

Ohne volatile darf der Compiler diesen Schreibzugriff auch beliebig 
verschieben oder sogar komplett wegoptimieren. Daß irgendwo davor und 
irgendwo danach mal was volatile ist, spielt dabei keine Rolle.

>> Der Compiler hat (technisch gesehen) nicht den inline asm Code
>> verschoben, sondern die Division, da sie ja nur einmal gebraucht wird.
>
> Das sind Spitzfindigkeiten

Nein. Der Compiler selbst weiß nicht, daß das cli() und das sei() in 
einem Zusammenhang stehen. Er weiß auch nicht, daß der Code dazwischen 
auch in einem Zusammenhang dazu steht. Er weiß (durch volatile), daß er 
das cli() und das sei() so wie im Code ausführen muß, aber er weiß 
aufgrund des fehlenden volatile nicht, daß er das mit der Zuweisung und 
der Division auch tun muß.

> und ich glaube kaum, daß es irgendeinen nicht-GCC Compiler gibt, der
> sich sowas auch erlaubt.

Da gibt's bestimmt jede Menge, wenn vielleicht auch nicht für AVR.

> Es ist ja auch egal, ob ich mit 100km/h auf jemanden drauf fahre oder
> er auf mich, es kracht in beiden Fällen gleich schlimm.

Falls du überlebst, kann es für dich schon einen Unterschied machen, ob 
du wegen grober Fahlässigkeit ein paar Jahre in den Knast kommst und 
persönlich für den finanziellen Schaden aufkommen mußt, weil die 
Versicherung ihr Geld wiederhaben will. Es gibt eben nicht nur die 
offensichtlichen Folgen.

> Entweder die volatile Instruktion wird da ausgeführt wo sie steht oder
> nicht.

Sie wird.

> Sie hängt ja nicht im luftleeren Raum, sondern bezieht sich natürlich
> auf den Code davor und dahinter.

Und woher soll der Compiler das wissen?

> Dann kann man sich das volatile doch gleich sparen.

Im Gegenteil. Im obigen Code fehlt das volatile.

Ach noch was:

> Ich arbeite jetzt erstmal mit GCC 3.4.6 weiter.

Ich halte es für keine Gute Idee, bei einem Fehler im Programm auf eine 
Compiler-Version zu wechseln, die trotzdem das Erwartete tut, statt den 
Fehler zu beheben.

> -freorder-blocks ist laut Doku erst bei -O2 aktiv.  Der Effekt hier
> tritt aber schon bei -Os auf.

Danke. Ich wusste nicht, welche Optimierung Peter benutzt hatte bzw. 
kann es im Moment nicht ausprobieren. Deine Antwort spart mir heute 
abend den Test ;-)

Jörg Wunsch:

>Sieht mir so aus, als gäbe es im C-Standard einfach keine Methode,
>Peters Willen garantiert in dieser Form umzusetzen.

Keine Ahnung ob das hier eine standardkorrekte Methode ist, aber
zumindest funktioniert es:

void test( unsigned int val )
{
  volatile unsigned int vol_val = val;

  vol_val = 65535U / vol_val;

  cli();
  ivar = vol_val;
  sei();
}

Nachtrag:

Mein Vorschlag kam wohl schon... Hab nicht genau hingeschaut.

Ich kanns auch gerade nicht ausprobieren, aber nach der uralten 
C-Grundweisheit: "Lieber ein Paar Klammern zuviel als zuwenig" geht 
vielleicht das hier:

void test( unsigned int val )
{
  val = 65535U / val;
  {
   cli();
   ivar = val;
   sei();
  }
}

Oliver

>  volatile unsigned int vol_val = val;
>
>  vol_val = 65535U / vol_val;

Das ist keine gute Idee, weil der Compiler nun unnütze Load-/Store-
Instruktionen erzeugt. Noch schlimmer wird es, wenn weitere Operationen
über vol_val ausgeführt werden, z.B.:

  vol_val = 65535U / vol_val;
  vol_val += 2;
  vol_val -= 2;

wird zu:

        ldi r24,lo8(-1)
        ldi r25,hi8(-1)
        rcall __udivmodhi4
        std Y+2,r23
        std Y+1,r22
        ldd r24,Y+1
        ldd r25,Y+2
        adiw r24,2
        std Y+2,r25
        std Y+1,r24
        ldd r24,Y+1
        ldd r25,Y+2
        sbiw r24,2
        std Y+2,r25
        std Y+1,r24

Ist vol_val nicht volatile deklariert, so optimiert der Compiler
die letzten beiden Anweisungen komplett weg.

>> Ich arbeite jetzt erstmal mit GCC 3.4.6 weiter.

>Ich halte es für keine Gute Idee, bei einem Fehler im Programm auf eine
>Compiler-Version zu wechseln, die trotzdem das Erwartete tut

Also für mich steht noch nicht fest, dass dies ein fehler des 
"Programms" ist. Mir scheint eher dass hier ein wesentliches Feature für 
den AVR-GCC fehlt.

Es ist auch keine Lösung die Code Strecken um CLI() ... SEI() herum mit 
volatile zuzuballern nur dammit der Compiler keine Möglichkeit mehr hat 
Code zu verschieben.

Dies mag in einfachen Beispielen wie dem obigen noch möglich sein, aber 
man denke nur daran, dass dort auch beliebige Funktionsaufrufe mit 
inline Attribut stehen können und spätestens dann hat man keine Chance 
mehr.

Noch ne anmerkung zu Thema "Standard":
Es ist zwar schön und gut wenn ein Compiler sich mit einer 100% Standard 
Konformität brüsten kann, ist ja auch in vielen Bereichen sehr wichtig.
Aber für einen AVR C Compiler ist es mindesten so wichtig verlässlichen 
Code für die typischen Einsatzfälle eines AVR zu generieren.

Dies schlägt alle mal C-Standard Konformität.

Für einen normalen C Compiler ist nur Ergebnissgleicheit wichtig.
Für einen Microkontroller Programm ist aber eine Präzise Kontrolle über 
Ausführungszeitpunkt und Zeitdauer noch wichtiger, etwas was volatile 
wie man sieht nur unzureichend kontrolliert.

Für mich fehlt hier eher ein
    no-reorder { .... }
Block Konzept (ähnlich try{} catch{} ).

> Ich arbeite jetzt erstmal mit GCC 3.4.6 weiter

Also mir ist auch beim 3.4.6 schon öfters beim Studium des Assembler 
Listings aufgefallen dass nach der cli() Instruktion Befehle auftauchten 
die  zu Berechnungen Ausserhalb gehörten. Ist also keine Gewähr....

@andreas:
Die Frage ist wie lange diese "Umgehung des Problems" hält, ein 
zukünftiger Optimierer könnte inlinen.
@all:
Die Idee des Feature Request ist sehr gut. Wird nicht im Moment sowieso 
darüber nachgedacht wie man auf Funktionslevel Optimierungen 
kontrollierbar macht?

Hallo zusammen,

ich hab Peters Code heute auf Arbeit mal mit Imagecrafts ICC compiliert. 
Dieser Compiler bietet zwei Möglichkeiten: keine Optimierung und 
Optimierung auf kleinste Programmgröße.

----------------------------
Hier das Listing gänzlich ohne Optimierung:

void test( unsigned int val )
{
    val = 65535U / val;
    004E EF0F      LDI  R16,0xFF
    004F EF1F      LDI  R17,0xFF
    0050 019A      MOVW  R18,R20
    0051 940E0063  CALL  div16u            ; ca. 200 Takte
    0053 01A8      MOVW  R20,R16

    CLI();
    0054 94F8      BCLR  7

    ivar = val;
    0055 93500061  STS  ivar+1,R21
    0057 93400060  STS  ivar,R20

    SEI();
    0059 9478      BSET  7

    005A 940E0088  CALL  pop_gset1
    005C 9508      RET
}
----------------------------
Hier das Listing mit Optimierung auf kleinste Programmgröße:

void test( unsigned int val )
{
    val = 65535U / val;
    004E EF0F      LDI    R16,0xFF
    004F EF1F      LDI    R17,0xFF
    0050 019A      MOVW   R18,R20
    0051 D011      RCALL  div16u           ; ca. 200 Takte
    0052 0000      NOP
    0053 01A8      MOVW   R20,R16

    CLI();
    0054 94F8      BCLR   7

    ivar = val;
    0055 93500061  STS    ivar+1,R21
    0057 93400060  STS    ivar,R20

    SEI();
    0059 9478      BSET   7

    005A D02D      RCALL  pop_gset1
    005B 0000      NOP
    005C 9508      RET
}

----------------------------
Das sieht doch gut aus, zumindest was das atomare angeht.

MfG
Schorsch

>... "inlining verbieten"

Aber das kann doch allen Ernstes nicht Lösung des Grundproblems sein?
Jede atomare cli/sei Codingstrecke nochmals in eine eigene Funktion 
packen?

Ich verstehe wenn man in der konkreten Situation von Peter nach 
irgendwelchen Abhilfen sucht, aber als generelle Lösung?

Ich habe einige C++ Klassen die mir Timer, ADC,PC-Host Kommunikation 
etc. managen. Alle vollgespickt mit cli/sei um AVR-Kontrollregister und 
eigene Datenstrukturen konsistent zu halten.
Die meisten dieser Methoden selbst sind als inline deklariert damit nur 
wirklich der Code generiert wird, der für den konkreten Aufruf benötigt 
wird, was sehr viel bringt. Hier überall Zwischenfunktionen einzuführen 
würde zu sehr hässlichem Coding führen.

Auch wenn das GCC Design schlecht zum AVR passt, so tritter er doch mit 
dem Anspruch auf ein brauchbarer Compiler für den AVR zu sein 
(WinAVR/GCC unterstützung in AVRStudio).

Daher denke ich nach wie vor dass die elemnatare Notwendigkeit atomare 
codingstrecken spezifizieren zu können auch als "First Oder" 
Sprachkonstrukt vom Compiler unterstützt werden müsste und nicht durch 
irgend welche asm Einsprengsel unterhalb der Sichtbarkeitsschwelle des 
Compilers.

  block-interupts {            // <-- push SREG; cli;
                     ......
                     if(...)
                        return;// <-- pop SREG
                  }            // <-- pop SREG

block-interupts hätte automatisch das oben angesprochene no-reorder 
Attribut.

Etwas ähnliches habe ich mir als C++ Klasse gebastelt:

    class BLOCK
    {
  UC      sreg;
    public:
  BLOCK()    { sreg = SREG; cli(); };// disable all interupts
  ~BLOCK()  { SREG = sreg;};        // reestablish prior interupt
                                                              enable 
state
    };
//usage:
   {
   ...
   BLOCK intrpts;      // cli called
   ...
      if(...) return;  // destructor called here
   ...
   }                   // destructor called here

Dies hat jedoch den grossen Nachteil dass sreg auf dem Stack landet, 
auch wennn genügend Register frei sind und auf das reoder Problem hat 
das natürlich auch keinen Einfluss.

Was haltet ihr von folgender Lösung?

void test( unsigned int val )
{
  val = 65535U / val;

  asm volatile (""::"r"(val));
  cli();

  ivar = val;

  sei();
}

Die asm-Anweisung erzeugt eine leere Assembler-Instruktion, die - so 
mache ich es dem Compiler zumindest weis - val als Eingabewert benutzt. 
Dadurch wird erzwungen, dass val bereits an dieser Stelle den neuen Wert 
hat, die Division also vor dem asm und damit vor dem cli ausgeführt 
wird.

Der erzeugte Code der, den sich Peter vorgestellt hat.

Die Methode ist natürlich nicht ganz universell, da die asm-Anweisung 
spezifisch an den Code zwischen cli und sei angepasst werden muss. Dafür 
greift sie nur minimal in die Optimierungsmöglichkeiten des Compilers 
ein.

Wenn ich diesen Text richig verstanden habe, würde es reichen, wenn man 
cli() und sei() aus interrupt.h entfern und in die Bibliothek 
implementiert.

Well, Lock comes from a threading library, so we can assume it either 
dictates enough restrictions in its specification or embeds enough magic 
in its implementation to work without needing volatile. This is the case 
with all threading libraries that we know of. In essence, use of 
entities (e.g., objects, functions, etc.) from threading libraries leads 
to the imposition of “hard sequence points” in a program—sequence points 
that apply to all threads. For purposes of this article, we assume that 
such “hard sequence points” act as firm barriers to instruction 
reordering during code optimization: instructions corresponding to 
source statements preceding use of the library entity in the source code 
may not be moved after the instructions corresponding to use of the 
entity, and instructions corresponding to source statements following 
use of such entities in the source code may not be moved before the 
instructions corresponding to their use.

Quelle : http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

>> block-interupts hätte automatisch das oben angesprochene no-reorder
>> Attribut.
>Das alles hilft dir gar nichts.  Die Operation, um die es geht, lag ja
>komplett außerhalb dessen, was bei dir "block-interrupts" wäre.  Damit
>ist sie völlig ungeschützt.

Vielleicht konnte ich mich nich richtig ausdrücken und no-reorder ist 
auch vielleicht nicht sugestive genug gewählt, aber ich meine damit was 
du hiermit andeutest:

>dass man bestimmte Blöcke von Code als nicht verschiebbar deklarieren kann
>also gewissermaßen ein "volatile" qualifier für einen Block

nähmlich der "no-reoder" block soll ohne import von ausserhalb liegenden 
Codeteilen als auch export nach ausserhalb übersetzt werden, also 
möglichst nahe an dem was hingeschrieben wird.
Als Programmierer habe ich letzendlich nur Kontrolle über den Block 
selbst, nicht jedoch was durch verschiedene Einsatszenarien im 
Wechselspiel mit den Compileroptimierungen an Coding davor oder danach 
zu liegen kommt.
Oder reden wir hier aneinander vorbei?

Ein no-interupt block Konzept wäre dann nur das Sahnehäubchen oben drauf 
um das lästige und Fehleranfällige push sreg;cli; pop sreg; effizienter 
und für den Leser übersichtlicher Compiler erledigen zu lassen.

>Damit verlässt du eben nur das Terrain der Programmiersprache C.

Ja das ist ja mein Argument:
Es bringt nichts so zu tun als wär ein Microkontroller Programm auch 
nichts anders als ein x-beliebiges PC Programm in C, in dem es gilt ein 
paar Bytes von links nach rechts zu schubsen.

Interuptgetriebenes Programmieren unter harten zeitlichen 
Randbedingungen und 20MIPS erfordert halt manchmal Sonderwege mit 
entsprechender Elementarunterstützung durch die Sprache.
Die Aussage
  "der C Standard sieht das aber nicht vor, also darf es nicht 
unterstützt
   werden"
wird für mich der Problemklasse nicht gerecht und dass andere Compiler 
noch weniger das Problem erkannt haben ist nur ein schwacher Trost.

Wie soll man denn zu höheren Steuerungssystem z.B. in der Robotik 
kommen, wenn man bei jeder Codeänderung das Assembler Listing 
nachkontrollieren muss?

> Es bringt nichts so zu tun als wär ein Microkontroller Programm auch
> nichts anders als ein x-beliebiges PC Programm in C, in dem es gilt ein
> paar Bytes von links nach rechts zu schubsen.

Genau das ist der Punkt. Und wenn das verstanden wurde, wird es auch 
endlich ein avr-gcc geben, der ein "void main(void)" ohne Warnung 
kompiliert. Wo gibt's denn sowas, µC-Programm und eine main() mit "int" 
als Rückgabewert. Da jemand so gar nicht gedacht...

Warum ist bis jetzt keiner auf die Lösung von yalu eingegangen?

Das ist doch ein gangbarer Weg, da zum ersten Mal dem Compiler 
mitgeteilt wird das da eine "Beziehung" zwischen cli und der Variable 
val besteht.

Die Frage ist muß das in den C-Compiler oder in die avrlibc
Sowas wie ein Makro "atomar" atomar( code, Zugewiesene Variablen)
das

atomar(
ivar = val;
,val)

umformt nach:

asm volatile (""::"r"(val));
  cli();

  ivar = val;
sei()

Sind Makros mit einer Variablen Anzahl von Parametern eigentlich 
möglich?
Prinzipiell hat Jörg recht, das sind 0,xx1 % der Fälle, wo so etwas 
interessiert. Man sollte nur abklären ab eine derartige Lösung den 
Compiler dauerhaft davon abhält , Berechnungen in den atomaren Abschnitt 
"reinzuziehen".

Jörg, ich verstehe es nicht. Du wirst doch selbst zugeben müssen, dass 
ein Rückgabewert von "main" auf einem µC sinnfrei ist. Warum wird das 
denn dann nicht einfach in den avr-gcc fest eingebaut? Wäre das einfach 
zu viel Arbeit? Ich habe keine Vorstellung davon, wieviel Aufwand hinter 
so einem Projekt steht, daher halt meine Frage. Es ist klar, dass es den 
gcc für viele Prozessoren gibt aber es muß doch auch irgendwo eine Datei 
oder was auch immer geben, in der prozessortypisches festgelegt ist.

Mal ganz naiv gedacht:

if(uctype == AVR)
  expectreturnvalue = FALSE;

{...}

if(!expectreturnvalue)
  suppresswarning();


Ende Geländer.


Ich kenne keinen kommerzeillen Compiler für µCs, der einen Rückgabewert 
in main erwartet. Ich freue mich auf deine Erläuterungen.

Ich stimme da Peter zu. Bei mir bleibt das ungute Bauchgefühl 
"Ausnahmslos jedes Assemblermacro [kann davon betroffen sein] muss 
anschliessend im ASM-Listing kontrolliert werden !".

Ich konnte nicht herausfinden, was für diese speziellen Optimierung von 
GCC verantwortlich ist, die bereits bei -O Optimierung stattfindet.

Man kann die Codeerzeugung von GCC selbst debuggen (z.B. -dB Option 
u.a.) und sich Textdateien ausgeben lassen, die zeigen, wie GCC die 
Source erkennt. Allerdings erkenne ich in der Debugausgabe zwischen 
3.4.5 und 4.1.1 nicht den Punkt "Bingo! Ah, deshalb!".

Es handelt sind nicht um ein Umarrangieren von "basic blocks". _asm_ 
macht auch keinen basic block auf, weder bei 3.4.5 noch bei 4.1.1.

Es handelt sich dabei um ein Verschieben einer sog. "insn" 
("Instruktion"). Es gibt in GCC das Konzept insns zu verschieben, um 
z.B. knappe Registerresourcen oder teuere Speicherzugriffe besser 
auszunutzen. Dieses Scheduling ist bereits bei -O aktiv, aber es ist im 
konkreten Fall nicht der Auslöser.

Komischerweise ist keine der bei -O defaultmässig eingeschalteten 
Optimierungsoptionen (Default -f...) der Auslöser bzw. kann das 
Umarrangement nicht durch -fno-... unterdrückt werden.

>> Prinzipiell hat Jörg recht, das sind 0,xx1 % der Fälle, wo so etwas
>> interessiert.
>Wie kommst Du denn darauf ?
0,xx1 % Im Bezug auf die C-Programme des GCC

>Ausnahmslos jedes Assemblermacro kann davon betroffen sein !
Konkret sind Konstellationen C gemischt mit Assembler, wobei die C 
Anweisungen einen impliziten Bezug zu den Assembler Anweisungen haben. 
Hier muß es Möglickeiten geben dies dem Compiler mitzuteilen. Sachen wie 
SLEEP mit explizitem Timing( nur x Takte bis zur SLEEP Anweisung) sind 
am besten in Assembler zu lösen.

Ich denke, das eine Notwendigkeit in der Systemprogrammierung für eine 
Lösung besteht steht fest.
@peda: Ich gehe davon aus du hast noch keinen Bugreport/Featurerequest
gesendet.

Man kann ja erstmal hier im Forum mögliche Lösungsansätze diskutieren.
Deshalb verstehe ich nicht warum keiner sich auf die Lösung von @yalu 
bezieht.
Sie geht das Problem da an, wo es besteht: Dem Compiler ist nicht 
bewußt, daß eine Beziehung zwischen den Anweisungen besteht.
Beispiel:
a=1;b=2;c=3;
sind genauso Anweisungen ohne Beziehung, damit kann der Compiler auch 
umordnen ala c=3;a=1;b=2;
und genau unter dem Aspekt sieht er auch cli();ivar=...; sei();
es sei denn ich teile ihm mit daß da eine Beziehung besteht. Mit dem 
asm...
geht das erstmal.
Bezüglich reordering:
Ich würde dem Compiler nicht prinzipiell das reordering verbieten
Wir sind in C nicht in Basic. Da muß sich der Programmierer schon bewußt 
sein, wenn er etwas kritisches tut und sollte es dem Compiler mitteilen 
(können). Also deswegen automatisch bei asm reordering auszuschalten 
halte ich nicht für sinnvoll.
Ich muß sagen, wenn ich meine Programme auf dem avr betrachte, dann 
betrifft dieses Problem nur 1%-0.1%. Die wirklich (Zeitkritischen) 
Routinen sind im untersten Abstraktionslayer. Alles darüber hat sowieso 
keinen Hardwarebezug. Allerdings sehe ich sehr wohl die Möglichkeit 
durch die stärkere Optimierung, daß dies irgendwann keinen "Schutz" mehr 
darstellt.

> Deshalb verstehe ich nicht warum keiner sich auf die Lösung von
> @yalu bezieht.

Habe ich mich auch schon gefragt, da das die exakt richtige Lösung ist. 
Wem die aus ästhetischen Gründen missfällt, der versteckt sie eben in 
einem Macro.

Wahrscheinlich wäre es vielen lieber, sie könnten sich stets drauf 
verlassen, dass der Code in exakt der Reihenfolge ausgeführt wird, wie 
er im Quellcode steht. Tja nun, der GCC muss sich ja auch mit 
SPEC-Benches rumschlagen - aus dem Eck kommt er ja - und solche 
Optimierungsaspekte sind unabhängig von der Zielmaschine und sind daher 
auch nicht Bestandteil der AVR-Spezifikation im Compiler.

Wer GCC einsetzt, muss mit Überraschungen hinsichtlich Umordnung 
rechnen. Die sind sein Job und das Ergebnis von Jahrzehnten Forschung im 
Compilerbau. Feature-Requests zum Thema "Rückbau" halte ich für 
dementsprechend aussichtslos.

Man wird daher nicht darum herum kommen, dem Compiler nicht sichtbare 
Abhängigkeiten explizit in den Code reinzuschreiben.

>Wahrscheinlich wäre es vielen lieber, sie könnten sich stets drauf
>verlassen, dass der Code in exakt der Reihenfolge ausgeführt wird..
Das ist schon eine ganze Weile nicht mehr so, auch wenn einige erst 
jetzt darüber stolpern.

>unabhängig von der Zielmaschine und sind daher auch nicht Bestandteil der 
>AVR-Spezifikation im Compiler.
Richtig ,allerdings "Problem" der Systemprogrammierung, deshalb frage 
ich mich ob die avrlibc nicht "Thread/Interruptischre" Makros bieten 
sollte, eh jeder sein eigenes strikt.

>Man wird daher nicht darum herum kommen, dem Compiler nicht sichtbare
>Abhängigkeiten explizit in den Code reinzuschreiben.
genau, Frage ist könnte die avrlibc das alleine (mit der vorgeschlagenen 
Lsg oder braucht sie Unterstützung. @Jörg?
Ist die Lösung "resistent" gegenüber späteren stärkeren 
Optimierungsversuchen des Compilers? Sonst ist ein Feature request 
wirklich nötig.

Ich denke die Sache muß sowieso zu den GCC Developern. Man könnte nur 
etwas Arbeit abnehmen, wenn das hier schonmal vordiskutiert wird und 
ausformuliert wird.

Was für eine Feature könnte das Problem lösen? Änderung bestehender 
Verhaltensweisen sollte man besser vergessen, damit löst man das Problem 
einer Person zu Lasten von zwei anderen, die grad das bisherige 
Verhalten benötigen.

Sinnvoll wäre vielleicht eine Art "reorder barrier", evtl als Attribut 
einer "asm" Operation, mit dem der Code konsequent in ein Davor und ein 
Dahinter getrennt wird. Wie einfach das zu realisieren ist, ist eine 
andere Frage. Jedenfalls ist das keine Sache der AVR-Portierung sondern 
ist im Kern von GCC anzusiedeln.

>"reorder barrier", evtl als Attribut einer "asm" Operation, mit dem der Code
>konsequent in ein Davor und ein Dahinter getrennt wird..
Für die angegebenen Variablen

Bsp:
cli();
ivar=var;
c=1;
sti;

c=1 (c nicht volatile) hat keine Probleme bei einer Verschiebung.
Deshalb sollte der Programmierer angeben können auf welche Variablen er 
Wert legt. Wie bei Lösung mit asm

Warum c1 nicht an anderer Stelle? Für eine gute Lesbarkeit will ich 
zusammengehörende Variablen an einer Stelle im Programmcode ändern (muß 
nicht unbedingt im Programmablauf so sein). Zukünftige Optimierungen 
könnten durchaus auch zu so einer Vereinfachung führen, auch hier muß 
der Compiler nur wissen auf welche Variable ich für eine atomare 
Operation Wert lege.

Siehe http://www.ecos.sourceware.org/docs-1.3.1/ref/ecos..., 
HAL_REORDER_BARRIER().

Implementiert als
   asm volatile ( "" : : : "memory" ).
Vielleicht hilft es ja.

@peda: Geht mir auch so, ein Grund mehr das ganze ansatzweise 
Auszudiskutieren. Nichtdestotrotz ist ein solches Posting letzten Endes 
nötig da es wohl auch ARM,ColdFire Echtzeit-Linux? betreffen könnte die 
darüber stolpern könnten...
Sehr interessantes Thema das du da angebracht hast, auch wenn ich auf 
keinen Fall für einen Rückschritt bin. Da muß der Programmierer dazu 
lernen (wie er das dem Compiler sagt) oder die avrlibc bietet es ihm an. 
Ich male mir gerade die ganzen Postings aus, wenn der Compiler noch 
stärker optimiert und aus 6 Takten >2000 werden. Da sind die "volatile" 
Postings gar nichts, nur das steht in der Spec. Deshalb muß eine Info 
sein und eine Lösung zum Umgang mit der Problematik gefunden werden. 
Möglicherweise haben wir die ja schon.

>Ist irgendwie komplizierter, als in nem Forum zu posten.
>Geht wohl alles nur über E-Mail und mit Anmeldung.
Hat eigentlich irgendjemand diesen Zugang?

Also, wenn ich den weiter oben gennanten Artikel

http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

richtig verstehe, dann lässt sich das Problem nur auf lib-Ebene lösen, 
da das Sprachkonzept von C (und C++) Interrupts und Threads nunmal nicht 
kennt, und es damit auch keine Aufgabe des Compilers sein kann, das 
irgendwie zu berücksichtigen. Trotzdem gibt es "threadsichere" libs, die 
auch die Ausführungsreihenfolgeoptimierung des Compilers entsprechend 
beeinflussen, wobei die Threadsicherheit da nur per Assembler eingebaut 
werden konnte - eben, weil es mit C gar nicht geht.

Inwieweit man jetzt cli() und sei() in der avr-libc vergleichbar 
implemetieren kann, kann ich leider überhaupt nicht beurteilen.

Oliver

Hallo Peter

versuch doch mal den CVAVR ich glaube der kneift sich derlei. Jedenfalls 
ist's mir seither nicht aufgefallen. Und ich binde hauptsächlich gerade 
zur IRQ Steurung #asm("cli") und #asm ("sei") mit dem Inlineassembler 
ein.

Im übrigen sehe ich das genau wie Du. Gerade bei der Interruptbehandlung 
hat sich ein Compiler an die Vorgaben des Programmierers zu halten, und 
kann nicht Codeoptimierung betreiben. Da komt es auf Zeitoptimierung an.
Aber vielleicht ist das ja auch Einstellungssache.

Da fällt mir auf: "Kann ein Compiler überhaupt und dieser im Speziellen 
die Optimierung nach dem Interruptstatus ausrichten? Wäre doch sinvoll 
wie an diesem Beispiel zu sehen. Und wenn ja erkennte er beim 
compilieren was eine ISR ist und woran. Gibt es besondere Pragmen?"

> asm volatile ( "" : : : "memory" ).
> Vielleicht hilft es ja.

Hört sich vielversprechend an.

Allerdings wird val im Register gehalten und ein Hinweis auf schmutzigen 
Speicher löst vielleicht nicht die gewünschte Aktion aus.

Man könnte dann die clobber list (1) durch die Register ergänzen, die 
von GCC als lokale Arbeitsregister verwendet werden. Bzw. auch um das 
condition code register cc (wenn das auf dem AVR verwendet wird) oder 
"brutal" alle Register...

(1) 
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Extend...

> Implementiert als
>    asm volatile ( "" : : : "memory" ).
> Vielleicht hilft es ja.

"memory" zeigt dem Compiler, dass das asm-Konstrukt Änderung im
Hauptspeicher vornimmt. Der Compiler wird deswegen Inhalte von
Variablen, die im Hauptspeicher liegen, während der Ausführung der
Assembleranweisungen nicht in Registern cachen, sondern vor dem asm in
den Speicher zurückschreiben und hinterher ggf. wieder einlesen.

Dies löst nicht das ursprüngliche Problem dieses Threads, dafür aber
andere, noch schwerwiegendere.

Während Peters Problem ein Perfomanceproblem (das aufgrund der
endlichen Ausführungsgeschwindigkeit natürlich auch die Funktion eines
Programms beeinträchtigen kann), gibt es Fälle, wo das Cachen von
Hauptspeichervariablen in Registern zu Race-Conditions und damit zu
echten Fehlern (unabhängig von der Ausführungsgeschwindigkeit) führen
können.

Deswegen ist im Linux-Kernel "memory" generell in der Clobber-List der
Interrupt-Enable/Disable-Funktionen vorhanden (Auszug aus 2.16.20):

static inline void raw_local_irq_disable(void)
{
  __asm__ __volatile__("cli" : : : "memory");
}

static inline void raw_local_irq_enable(void)
{
  __asm__ __volatile__("sti" : : : "memory");
}

Wann es ohne die "memory"s schief gehen kann (und tatsächlich auch
schon schief gegangen ist), kann man hier  beim Gott persönlich
nachlesen:

  http://lkml.org/lkml/1996/5/2/87

>>> Deshalb verstehe ich nicht warum keiner sich auf die Lösung von
>>> @yalu bezieht.

>> Habe ich mich auch schon gefragt, da das die exakt richtige Lösung ist.
>> Wem die aus ästhetischen Gründen missfällt, der versteckt sie eben in
>> einem Macro.

> Ich finde sie auch OK.  Könnte gut sein, dass ein entsprechender
> feature request mit genau sowas beantwortet wird.


Das ist zwar eine Lösung im speziellen fall.
Aber keine generelle wie er selbst darstellt:

> Die Methode ist natürlich nicht ganz universell, da die asm-Anweisung
> spezifisch an den Code zwischen cli und sei angepasst werden muss

Die braucht es aber ,mit derlei problemen umzugehen. Ich denke hier ist 
es notwendig auf die Optimirungsmethode einfluss zu nehmen.

Man kann zwar bei den meißten Compilern zuvor einstellen ob zeit- oder 
speicheroptimierter Code erzeugt werden soll. Mir ist jedoch nicht 
bekannt, ob man dies per Pragma im sourcecode der momentanen 
Programmablaufsituation anpassen oder gar ein und ausschalten kann?
Ich denke hier liegt ein grundlegender Klärungsbedarf vor, da das Timing 
sehr wohl über die Qualität der Arbeit des Programmierers mit 
entscheidet.

Wohl nichtzuletzt immer wieder ein Argument auch der 
Hochsprachenkritiker.

>http://lkml.org/lkml/1996/5/2/87
>Essentially, think of the "memory" thing as a serializing flag rather than as
>a "this instruction changes memory" flag. It is extremely important that gcc
>_not_ re-order memory instructions across these serializing instructions,

Wenn ich das richtig lese hatte die das gleiche Problem der 
Serialisierung
Wenn ich "asm volatile ( "" : : : "memory" )" verwende kann ich aber es 
nicht verhindern das die Modulooperation über das cli hinweg verschoben 
wird.
Könnte es sein das sich da noch ein größeres Problem in einer der 
Hauptarchitekturen zeigt???

Man sollte nicht aus den Augen verlieren, dass es sich beim skizzierten 
Problem der verschobenen Division um ein ungünstiges, aber trotzdem 
vollkommen korrektes Verhalten handelt. Es wird korrekt alles 
ausgeführt, nur verschlechtert sich das Zeitverhalten von Interrupts.

Memory barriers hingegen stellen korrektes Verhalten sicher. Es kann, 
wie im o.A. Torvalds-Text gezeigt, für ein Programm absolut wesentlich 
sein, ob Speicheroperationen vor oder nach dem Aus- oder Einschalten von 
Interrupts stattfinden. Finden sie zum falschen Zeitpunkt statt, kann 
das Programm sich falsch verhalten.

Allerdings ist die Doku zum eCos HAL irreführend. Sie suggeriert, dass 
über diese Barriere keine Reorganisation stattfindet. Das ist falsch. 
Damit wird lediglich erreicht, dass keine speicherbezogene 
Reorganisation stattfinden - was in den Registern passiert, bleibt davon 
unberührt. Für Korrektheit reicht das aus, für ein gewünschtes 
Zeitverhalten nicht.

> Könnte es sein das sich da noch ein größeres Problem in einer der
> Hauptarchitekturen zeigt???

Das Problem hat so gut wie nichts mit irgendwelchen Architekturen zu 
tun. Einzig Architekturen, die fast oder ganz auf Register verzichten, 
bleiben davon verschont.

Jörg Wunsch schrieb:

> Hatten wir für die avr-libc auch schon mal diskutiert, war dann aber
> wieder verworfen worden.  Der einzige Fall, für den Björn Haase
> das gefordert hatte, stellte sich als lokaler Compilerbug bei ihm
> heraus.

Das ist m. E. auch ok so. Denn die Fälle, wo das "memory" wirklich
gebraucht wird, sind wahrscheinlich deutlich seltener, als diejenigen,
wo dadurch unnötigerweise Programmspeicher und Taktzyklen verschwendet
werden, zumal dadurch ja nicht jedes Problem gelöst wird.

Inline-Assembly (ob direkt oder oder in schöne Makros verpackt) ist
nun einmal ein schwieriges Thema, das nur dann sauber und ohne
Perfomance-Einbußen in den Griff zu kriegen ist, wenn eine der
folgenden Voraussetzungen gegeben ist:

- Der Compiler ist in der Lage, sämtliche Abhängigkeiten und
  (Seiten-)Effekte des Assembler-Codes zu erkennen. Dann wäre jedoch
  die Assembler-Sprache de facto Bestandteil der Sprache C, was nicht
  realistisch ist.

- Der Programmierer ist in der Lage, sämtliche Abhängigkeiten und
  (Seiten-)Effekte des Assembler-Codes zu erkennen und der Compiler
  bietet eine Möglichkeit, diese Informationen entgegenzunehmen. Das
  Extended Asm des GCC ist der richtige Ansatz dafür, deckt aber
  sicher (noch) nicht jedes noch so exotische Problem ab.

Natürlich sind andere Wege denkbar (wie von verschiedenen Thread-
Teilnehmern bereits vorgschlagen), die weniger Nachdenken des
Programmierers erfordern, dafür aber die Optimierungsmöglichkeiten
(zumindest die lokalen) des Compilers einschränken.

<etwaswenigerernst>
Vielleicht wäre es klüger, die harmlos aussehenden cli/sei-Makros aus
der avr-libc wegzulassen. Während des Eintippens einer kompliziert
aussehende Anweisung wie

  __asm__ __volatile__ ("cli");

hat man mehr Zeit, sich ein paar Gedanken darüber zu machen, was da
überhaupt abgeht, und vielleicht sogar mal den Onkel Google zu fragen,
was anderer Leute Erfahrung damit ist.
</etwaswenigerernst>

> Der Compiler ist in der Lage, sämtliche Abhängigkeiten und
> (Seiten-)Effekte des Assembler-Codes zu erkennen.

Das kann er im hier beschriebene Fall schon prinzipiell nicht, da keine 
technische Abhängigkeit gegeben ist, sondern nur in einem erwünschten 
Zeitverhalten besteht.

Wolfram schrieb:
> Könnte es sein das sich da noch ein größeres Problem in einer der
> Hauptarchitekturen zeigt???

A.K. schrieb:
> Man sollte nicht aus den Augen verlieren, dass es sich beim
> skizzierten Problem der verschobenen Division um ein ungünstiges,
> aber trotzdem vollkommen korrektes Verhalten handelt. Es wird
> korrekt alles ausgeführt, nur verschlechtert sich das Zeitverhalten
> von Interrupts.

Vollkommen richtig. Mich würde in diesem Zusammenhang aber mal
interessieren, wie oft die Kernel-Hacker (egal ob Linux, BSD oder
Windows) einen Blick auf den vom Compiler generierten Assembler-Code
werfen, um solche Probleme wie das von Peter beschriebene zu erkennen
und ggf.Gegenmaßnahmen zu treffen.

Allerdings vermute ich, dass sich bei den Desktop-/Server-
Betriebssystemen der verschobene Code innerhalb eines cli/sei-Paares
nicht all zu sehr auswirkt, da dadurch keine Prozessorzyklen
verschenkt werden. Es wird ja zu jedem Zeitpunkt Code ausgeführt, der
sowieso ausgeführt werden muss. Lediglich das Echtzeitverhalten, d. h.
die Raktionszeit auf Interrupts wird dadurch negativ beeinflusst.
Deswegen wäre es interessant zu wissen, wie die Programmierer von
Echtzeitsystemen mit diesem Problem umgehen.

>> Der Compiler ist in der Lage, sämtliche Abhängigkeiten und
>> (Seiten-)Effekte des Assembler-Codes zu erkennen.
>
> Das kann er im hier beschriebene Fall schon prinzipiell nicht, da
> keine technische Abhängigkeit gegeben ist, sondern nur in einem
> erwünschten Zeitverhalten besteht.

Es gibt keine Abhängigkeiten, aber Seiteneffekte. Der Seiteneffekt
besteht in diesm Fall darin, dass die Interrupts gesperrt sind, was
die Reaktionszeit auf externe Ereignisse verschlechtert, was wiederum
ein guter Optimierer zu Anlass nehmen könnte, die Zeitdauer dieses
(zwar nicht destruktiven, aber doch schädlichen) Seiteneffekts auf ein
Minimum zu reduzieren.

@Patrick Dohmen

>also kann auch kein Optimierungsprogramm Annahmen darüber treffen. Ich
>fürchte, daß es auf einen nicht portablen (aus ANSI/ISO-Sicht) Hack
>hinauslaufen wird.

Warum? Es wurde doch schon eine vollkommen standardkonforme Lösung mit 
einer volatile Variable beschrieben. Fertig aus.

MfG
Falk

> Es gibt keine Abhängigkeiten, aber Seiteneffekte.

Mit diesem Gedanken näherst du dich stark dem allseits gewünschten 
DWIM,NWIS Compiler (Do What I Mean, Not What I Say).

> Ob das jetzt bedeutet, dass innerhalb
> dieses Blocks überhaupt keine Optimierungen mehr stattfinden,
> oder ob das nur als Barriere fungieren soll: Ich diskutiere
> da noch mit mir selbst :-)

Das ergibt so keinen Sinn. Mehr Sinn ergäbe es, wenn über die Grenzen 
eines solchen Blocks keinerlei reordering stattfinden darf, innerhalb 
jedoch schon.

Sowas kannst du machen, wenn du die Hoheit über den Compiler besitzt. 
Bau dir deine eigene Version vom GCC, bau das in SDCC ein, was auch 
immer. Aber erwarte nicht, dass sowas jemals in der offiziellen Distro 
aufkreuzt.

@Patrick Dohmen

>Aha! Warum ist dann hier nicht "Fertig aus"?

Weil mal wieder

a) die eierlegende Wollmilchsau gesucht wird
b) jeder 2. Thread nach spätestens einem Dutzend Postings ins 
Philosophische abdriftet

MFG
Falk

P.S. Oink Oink!

Nicht
   volatile {
     cli();
     i = j;
     sei();
   }
sondern
   cli();
   volatile {
     i = j;
   }
   sei();

Oder, in der narrensicheren Version:
  volatile {
   cli();
   volatile {
     i = j;
   }
   sei();
  }

@Patrick Dohmen

>Das sehe ich in diesem Thread aber nicht. Ich kann schon verstehen, daß
>man weder alle Optimierungen verbieten will, noch eine -
>möglicherweise - hundertfache Ausführungszeit hinnehmen möchte. Es fehlt
>ein Mittelding, was wohl der Grossteil der Poster in diesem Thread
>genauso sieht.

Ja.

>> P.S. Oink Oink!
>Würdest Du mich diesbezüglich aufklären?

Das war ein Gruss an die eierlegende Wollmilchsau. ;-) Never mind.

MFG
Falk

>Aha! Warum ist dann hier nicht "Fertig aus"?

Weil nicht sicher ist, das die Lösung auch für andere (zukünftige) 
Optimierungen sicher ist.
Das ist aber nur mit einem Eintrag im Bugzilla zu klären.

> Du wirst doch selbst zugeben müssen, dass ein Rückgabewert von "main"
> auf einem µC sinnfrei ist. Warum wird das denn dann nicht einfach in
> den avr-gcc fest eingebaut?

Also statt einfach die konforme und universelle Variante zu verwenden, 
soll im GCC extra für AVR eine Sonderbehandlung eingebaut werden, nur 
damit er dann auch die nicht konforme Variante, die keinerlei Vorteile 
hat, akzeptiert?

> Siehe http://www.ecos.sourceware.org/docs-1.3.1/ref/ecos...
> HAL_REORDER_BARRIER().
>
> Implementiert als
>   asm volatile ( "" : : : "memory" ).

Genau das macht doch auch schon die im Compiler eingebaute Funkton 
__sync_synchronize().

Ich sehe da schon einen Unterschied:

   asm volatile ( "" : : : "memory" ).
erzeugt keinen Code, sondern steuert das Verhalten des Compilers 
hinsichtlich Optimierung von Speicherzugriffen.

   __sync_synchronize
hingegen erzeugt, sofern überhaupt vorhanden, zusätzlich 
Prozessorbefehle, die dafür sorgen, dass auch seitens der Maschine kein 
reordering über diese Grenze stattfindet.

Ist das obige Problem u.U. nicht auch zum Großteil hausgemacht?

CLI ist der Vorschlaghammer, der immer den kompletten Prozessor lahm 
legt. Es wäre doch geschickter, nur die Interruptquelle zu sperren, die 
den Zugriff auf 'ivar' stören könnte. Und dann ist die Frage, ob das 
Problem der Ausführungsreihenfolge überhaupt noch relevant ist.

>Es könnten dann sämtliche anderen Interrupts, die in der Pollingsequenz
dahinter liegen, dazwischen hauen und in der Summe eine zu hohe
Latenzzeit bewirken.>

Dann stellt sich die Frage, ob der Prozessor nicht generell 'ne Nummer 
zu klein gewählt wurde.

@Profibauer

>>Es könnten dann sämtliche anderen Interrupts, die in der Pollingsequenz
>>dahinter liegen, dazwischen hauen und in der Summe eine zu hohe
>>Latenzzeit bewirken.>

>Dann stellt sich die Frage, ob der Prozessor nicht generell 'ne Nummer
>zu klein gewählt wurde.

Quark! Das läuft alles wunderbar, solange der Compiler nicht so "schlau" 
ist, und lange Operationen "illegal" in einen Block schiebt, in dem die 
Interrupts gesperrt sind. Hier ist ausnahmsweise mal der Compiler 
"Schuld", weil er versucht schlauer zu sein als der Programmierer. Hier 
gehts schief.

MFG
Falk

>Das ist sein Job.
>Wenn man das haben will, muss man in Assembler programmieren.

So sehe ich das auch. Wie groß wäre das Getöse, wenn der Compiler nicht 
optimieren würde. Und irgendwo muß man die Hinweise auch 'mal ernst 
nehmen, daß die Reihenfolge der Abarbeitung eben nicht so ist, wie man 
es eintippt.
Aus der Diskussion lerne ich: was der Compiler macht ist kein schwerer 
Bug, sondern ein Kompromiß, den man als 'erfahrener Programmierer' 
kennen sollte. Dafür werden wir ja schließlich bezahlt ;-)
Und um die 200 Taktzyklen einzuschätzen: bei 16MHz dauern die etwa 13µs. 
Gut, müßte nicht unbedingt sein, aber damit sollte man leben können. Und 
wenn man dies absolut nicht akzeptieren kann, dann werden eben ein paar 
Zeilen Assembler eingetippt.

Deshalb Änderungen am Compiler vorzunehmen würde ich nicht fordern.

> Den Compiler trifft keine Schuld. Hier sind die Möglichkeiten
> von C an sich nicht ausreichend.

Warum schafft es dann der ICC?

>Warum schafft es dann der ICC?

Der optimiert (noch) nicht so stark, wie IAR und GCC?!

>Krass gesagt: weil er so schlecht optimiert, dass er gar nicht erst
>auf die Idee kommt, die Division überhaupt zu verschieben.

So kann man sich natürlich auch aus der Affäre ziehen. Dass der Compiler 
einfach gut ist und erkennt, dass ein Verschieben an dieser Stelle nicht 
sinnvoll ist, kommt wohl überhaupt nicht Frage, wie?

Du mußt es so sehen, ICC ist kein Wald- und Wiesencompiler, den es für 
10000 Architekturen gibt. Der ICC ist für Mikrocontroller entwickelt 
worden, und wird weiter für solche optimiert und erweitert, erfolgreich 
derzeit mit Version 7. Siehst du ja schon daran, dass ein "int 
main(void)" nicht erwartet wird. Scheiß auf den C-Standard, er stammt 
aus einer Zeit, als noch niemand ansatzweise daran gedacht hat, µCs in C 
zu programmieren. Und sämtliche Erweiterungen des Standards haben es 
nicht wirklich gebracht.

@Patrick Dohmen

>Oho, jetzt kommt die Militante Fraktion und wirft den gesamten
>Gesprächsverlauf wieder zurück ins Mittelalter...

;-)
Naja, nicht ganz. Aber die Jungs die den AVR-Port geschrieben haben 
sollten/müssen schon ein paar Besonderheiten von uCs beachten. Und man 
hätte ja in den Macros sei() und cli() die diversen, schon vorhandenen, 
Macros für volatile, memory block und weissderTeufelwas einbauen 
könen/müssen, um eben solche "Optimierungen" zu verhindern. Schliesslich 
sind sämtliche Register im AVR auch als volatile gekennzeichnet.

MfG
Falk

@Jörg Wunsch

>Es ist aber, unabhängig davon, eben verdammt schwierig, die Intention
>des Programmierers nur an Hand dessen zu entscheiden und die richtige
>Wahl zu treffen.  Du willst ja nicht grundsätzlich, während die
>Interrupts verboten sind, auf jegliche Optimierung verzichten -- das
>wäre genauso am Ziel vorbei geschossen:
>  cli();
>  /* 500 Lines of code */
>  sei();

Ja. Aber es wurde doch schon mehrfach gesagt, dass man dem Compiler 
beibigen muss, cli() und sei() auasi als Sequence Point oder wie auch 
immer das heisst aufzufassen und über diesen Punkt darf nix verschoben 
werden. Wenn ich das richtig verstanden haben gibts beim GCC schon 
einige "geheime" Schalter/Attribute, die das machen. Und selbst wenn 
derBlcok zwischen cli() und sei() nicht optimiert wird, sollte das wnig 
Einfluss auf die Performance haben, da diese Befehle sinnvollerweise nur 
sparsam eingesetzt werden.

MFG
Falk

> Aber die Jungs die den AVR-Port geschrieben haben
> sollten/müssen schon ein paar Besonderheiten von uCs beachten.

Das Wörtchen "müssen" reduziert die Wahrscheinlichkeit, dass sich jemand 
eines solchen Themas überhaupt annimmt. Open source wie GCC heisst: Nimm 
was da ist, oder löse dein Problem selbst oder hoffe, dass jemand so 
nett ist es zu tun. Aber verlange nicht von anderen, für Lau dein 
Problem zu lösen, auch nicht wenn du es für wirklich sinnvoll, nötig, 
unverzichtbar hältst.

Wie oben schon gelegentlich angeführt, hat die Spezifikation der 
Zielmaschine im GCC herzlich wenig Einfluss auf maschinenunabhängige 
Optimierungen wie diese Verschiebung der Division.

Wenn eine Portierung auf eine bestimmte Zielmaschine im 
maschinenunabhängigen Kern des Compiler rumferkelt, dann reduziert das 
dementsprechend das Wahrscheinlichkeit einer Übernahme in den 
offiziellen Quellcode. Mal abgesehen davon, dass es entsprechend mehr 
Kenntnis seitens des Programmierers verlangt also sonst nötig.

Speicherbezogene barriers sind einfach, wie hier schon gesehen, auch als 
Bestandteil von cli/sei möglich (siehe dazu Jörgs Kommentar), aber lösen 
das hier beschriebene Problem nicht.

Falls ein Compiler anbieten würde, zwischen cli() und sei() mal zu 
optimieren und mal nicht, bleibt es letztlich doch am Programmierer 
hängen, diese Situation überhaupt zu erkennen und entsprechende Optionen 
anzufordern. Automatisch wird es wohl nicht funktionieren (können).

@Profibauer

>Falls ein Compiler anbieten würde, zwischen cli() und sei() mal zu
>optimieren und mal nicht, bleibt es letztlich doch am Programmierer
>hängen, diese Situation überhaupt zu erkennen und entsprechende Optionen
>anzufordern. Automatisch wird es wohl nicht funktionieren (können).

Das wäre IMHO vollkommen OK.

MFG
Falk

Ein anderer, offensichtlicher Workaround: Übersetze diese Source ohne 
-O* Optimierung!

Packe den Codeteil, der auf die cli/sei-Klammer angewiesen ist, in ein 
eigenes Sourcefile. Übersetze dieses ohne Optimierung.

Den Rest der Source kommt in andere Quelldateien, die dann mit 
Optimierung übersetzt werden können.

Objektdateien zusammenlinken und fertisch.

Mich stört mehr, dass man (ich) nicht aus der GCC Doku erfahre, welche 
Optimierungsstrategie für das Verzögern der ersten Anweisung 
verantwortlich ist.

Die -f... Schalter bei den -O Optionen beeinflussen diese Art der 
Optimierung nicht. D.h. man kann genau diese Optimierung nicht selektiv 
ab- oder abschalten und man hat nur die Holzhammer-Methode oben.

@Stefan

>Packe den Codeteil, der auf die cli/sei-Klammer angewiesen ist, in ein
>eigenes Sourcefile. Übersetze dieses ohne Optimierung.

Na DAS ist weiss Gott ein Würg-Around!

>ab- oder abschalten und man hat nur die Holzhammer-Methode oben.

Das mit der volatilen temporären Variablen fand ich äusserst schmerzarm.

MFg
Falk

> Allerdings vermute ich, dass sich bei den Desktop-/Server-
> Betriebssystemen der verschobene Code innerhalb eines cli/sei-Paares
> nicht all zu sehr auswirkt, da dadurch keine Prozessorzyklen
> verschenkt werden. Es wird ja zu jedem Zeitpunkt Code ausgeführt, der
> sowieso ausgeführt werden muss. Lediglich das Echtzeitverhalten, d. h.
> die Raktionszeit auf Interrupts wird dadurch negativ beeinflusst.
> Deswegen wäre es interessant zu wissen, wie die Programmierer von
> Echtzeitsystemen mit diesem Problem umgehen.

Auch dort gibt es Situationen in denen das Zeitverhalten kritisch ist 
und z.B. beim Zugriff auf Peripheriegeräte bestimmte Reihenfolgen und 
Timings eingehalten werden müssen (auf dem AVR z.B. 
EEPROM/Watchdog-Zugriffe)

Beispiel:
http://lkml.org/lkml/2006/11/1/254

Falls man noch (standardkonforme) Wünsche äussern darf
#pragma atomic|interruptable|monitor on|off
und
#pragma reorder on|off

....
womit wir entlich beim richtigen Ansatz sind.

benötigt wird:

#pragma opt(imice) on
#pragma opt(imice) off
#pragma opt(imice) time
#pragma opt(imice) memory

Diese vier Pragmen sollte ein Compiler für wohl jeden µC (ich behaupte 
gar jeden Prozessor) beherschen und zur not das gesamte pipelinig nebst 
Cash neuordnen können wenn es der Programierer so will!

Schließlich muss der Programmierer (Mensch) Herr über das System bleiben 
und nicht sein Sklave.

Dies All Jenen ins Stammbuch, welche glauben der Programmierer ist 
schuld, weil er etwas logisches vom Tool erwartet, was für jedoch dessen 
Direktiven widerspricht. Hier sind die Direktiven die Falschen nicht der 
Programmierer, der Herr des Codes sein muß.

Ein Tool sollte ein Hilfsmittel bleiben. seine Direktiven sind den 
Erfordernissen anpassbar zu gestallten. Tut man dies nicht, so verfehlt 
das Tool seine Aufgabenstellung und wird dem Markt nicht gerecht. Dies 
als kleine philosophische Anmerkung.

Generischer Ansatz für Interrupt-feste Zuweisungen, basierend auf yalu's 
Lösung ("poor man's template" - in C++ sieht sowas hübscher aus). 
[--std=gnu99]

#include <avr/interrupt.h>

#define safe_assign(dst,src) \
  { typeof(src) x = (src); \
    asm volatile (""::"r"(x)); \
    cli(); \
    dst = x; \
    sei(); \
  }

unsigned int ivar;

void test( unsigned int val )
{
    safe_assign(ivar,  65535U / val);
}

Korrektur:

#define safe_assign(dst,src) \
  { typeof(dst) x = (src); \
    asm volatile (""::"r"(x)); \
    cli(); \
    dst = x; \
    sei(); \
  }

>Seltsam ist nur, dass man diejenigen, die hier die schlauesten Reden
>schwingen, nie sieht, wenn's um das Lösen von Problemen geht...
>Geschweige denn dabei, sich auch nur mal annähernd ein Stück
>Compilercode anzugucken. (*)


Sorry ich bnutze CVAVR und habe das Problem nicht, obgleich auch dieser 
optimiert.

Compiler baue ich auch (noch) nicht, aber ich weiß was ich benötige und 
das suche ich mir.

Meine eigenen von CVAVR compilierten Code studiere ich sehr wohl, 
fremdes eher selten (da fremden Gedanken zu folgen oft schwerer ist noch 
dazu wen noch werd drüber ist), schon um zuerfahren was er draus macht, 
seine Funktion zu verstehen und daraus zu lernen.

Ich bin seit 37 Jahren Autodidakt in Sachen Elektronik und 
Programierung, während ich in Sachen Philosophie tatsächlich ein paar 
Semester hatte. Ohne dieses eigenständige Hinter_die_Kulissen schauen 
wäre ich ein typischer Mediamarktkunde(Blödmann, Mausschubser)

Nun zum Eesentlichen: Der einzige Grund warum ich nicht die fertige 
Lösung anstrebe ist ein Mangel an Zeit. An Ehrgeiz oder Neugier 
jedenfalls mangelt es mir nicht. Und das notwendige Wissen würde ich mir 
erwerben, schon um das Problem zu lösen und eine Beitrag zu leisten. Nur 
glaube ich, dass wer da bereits drinnen steckt diese Anregung wesentlich 
schneller und leichter umsetzen kann als ich, der ich mich erst 
einarbeiten müßte.

Ich weis 99% sind Fleiss, aber ohne 1% Idee läuft halt gar nichts.

keep smile ;-))

Hallo, ich habe diesen langen Thread nicht komplett durchgelesen und nur 
überflogen.

Die angesprochenen Optimierungen im GCC können wirklich ein Ärgernis 
sein, vor allem, wenn sie zu fehlerfhaftem Code führen (zB nicht-atomare 
Port-Zugriffe wegen CSE-Optimierung).

Ob die neuen SSA-Optimierungsstrategien in GCC besseren Code bewirken, 
bleibt abzuwarten. Ich für meinen Teil bin da eher skeptisch und 
verwende weiterhin die stabile 3.4.6, die dichten Code erzeugt (dichter 
als 4.x). Optimierungen sind nämlich nur in wenigen Ausnahmefällen 
maschinenunabhängig...

Wie auch immer.

Zum Workaround können Barrieren dienen, über die GCC nicht hinweg 
optimiert -- aus welchen Gründen auch immer.

Eine dieser Barrieren wurde schon genannt:

#define MEM_BARRIER \
    __asm volatile ("; Barrier " ::: "memory")

Eine zweite Barrier lässt die CSE stolpern, was in folgendem Link näher 
beleuchtet wird und zum Fix nicht-atomarer SFR-Zugriffe verwendet werden 
kann: 
http://www.roboternetz.de/wissen/index.php/Avr-gcc...

#define CSE_BARRIER \
    __asm volatile ("; CSE-Barrier " ::)

Eine weitere Barriere stellt das explizite reloaden eines Wertes in eine 
bestimme Registerklasse dar. RELOAD lässt GCC vergessen, welchen Wert 
eine bestimmte Variable hat:

#define RELOAD(reg,var) \
  __asm__ __volatile (";RELOAD " reg " with " #var : "=" reg (var) : "0" (var))

Dieses Makro löst zB folgendermassen auf:

void foo (void)
{
    display_t * dis = &display;
    
    RELOAD ("r", dis);
    
    dis->digit[0] = '0';
    dis->digit[1] = '0';
    dis->digit[2] = '0';
    dis->digit[3] = '0';
}

// *.i
    __asm__ __volatile (";RELOAD " "r" " with " "dis" : "=" "r" (dis) : "0" 

Ohne RELOAD wählt GCC absoluten Zugriff, weil er die Adresse zur C-Zeit 
berechnen kann. (zwar nicht als Konstante, aber als Immediate).

foo:
  ldi r24,lo8(48)   ;  tmp42,
  sts display,r24   ;  <variable>.digit, tmp42
  sts display+1,r24   ;  <variable>.digit, tmp42
  sts display+2,r24   ;  <variable>.digit, tmp42
  sts display+3,r24   ;  <variable>.digit, tmp42
  ret

Mit RELOAD muss der Zugriff indirekt erfolgen:

foo:
  ldi r30,lo8(display)   ;  dis,
  ldi r31,hi8(display)   ;  dis,
/* #APP */
  ;RELOAD z with dis
/* #NOAPP */
  ldi r24,lo8(48)   ;  tmp42,
  st Z,r24   ;  <variable>.digit, tmp42
  std Z+1,r24   ;  <variable>.digit, tmp42
  std Z+2,r24   ;  <variable>.digit, tmp42
  std Z+3,r24   ;  <variable>.digit, tmp42
  ret

Mit RELOAD kann übrigens nicht erzwungen werden, daß eine Variable in 
einem bestimmten Register angelegt wird. Wählt man als Constraint etwa 
"z", dann hätte das bewirkt nur, daß sich 'dis' zum Zeitpunkt des asm im 
Z Register befindet. Es bedeutet nicht, daß 'dis' im Z-Register lebt!

MfG Georg-Johann

Zielkonflikt. Da <ivar> üblicherweise volatile sein wird, ist Version 1 
doch sinnvoller, sonst erbt <x> diese Eigenschaft und steckt im 
Speicher. Nur sollte dann keine aufwendige Typkonvertierung in der 
Zuweisung drin sein. Also besser nicht double x = safe_assign(1).

@SprinterSB: Interessanter Ansatz. Aber wird man sich auf CSE_BARRIER 
verlassen können? Dieses asm-statement ist ja ein ziemliches Nichts. 
Wenn das also nicht offiziell so definiert ist, könnte dieses Verhalten 
irgendwann wieder verschwinden.

>Korrektur:
>
>#define safe_assign(dst,src) \
>  { typeof(dst) x = (src); \
>    asm volatile (""::"r"(x)); \
>    cli(); \
>    dst = x; \
>    sei(); \
>  }

Dies ist nicht korrekt. x ist hier nut Input-Operand des asm. Das mag in 
einigen Fällen das Problem lösen, garantiert es aber nicht.

Hier hilft das eben beschriebene RELOAD:

#define RELOAD(reg,var) \
  __asm__ __volatile (";RELOAD " reg " with " #var : "=" reg (var) : "0" (var))

... 

   RELOAD ("r", x);

> Sorry, aber die Optimierung ist mittlerweile einfach mal viel zu
> komplex geworden, als dass sich ein Compilerhersteller noch darauf
> einlassen könnte, sie irgendwo zwischen zwei Quellzeilen mal nur
> so auf die Schnelle umschalten zu können.  Mittlerweile optimieren
> die Compiler über komplette Projekte hinweg (also über mehr als eine
> Quelldatei).

Ob man das auch für jede einzelne Zeile festlegen muss, nein, solange 
man Inlining, bei Bedarf, erzwingen kann.
ICC und VC lassen es zumindest zu das man die Optimierungsstufe auf 
Funktionsebene festlegt.

Und mal als Demonstration, warum C++ bei Microcontrollern durchaus 
sinnvoll sein kann:

#include <avr/interrupt.h>

#define RELOAD(reg,var) __asm__ __volatile (";RELOAD " reg " with " #var : "=" reg (var) : "0" (var))

template<class t> class safe_var {
public:
    void operator= (t rhs) {
  t tmp = rhs;
  RELOAD("r", rhs);
  cli();
  value = tmp;
  sei();
    }
    operator t () {
  cli();
  t tmp = value;
  sei();
  return tmp;
    }
private:
    volatile t value;
};

safe_var<unsigned> ivar;

void test()
{
    ivar = 65535U / ivar;
}

Sämtliche Zugriffe auf <ivar> sind so automatisch Interrupt-fest, ob 
lesend oder schreibend.

_Z4testv:
        cli
        lds r22,ivar
        lds r23,(ivar)+1
        sei
        ldi r24,lo8(-1)
        ldi r25,hi8(-1)
        rcall __udivmodhi4
        mov r25,r23
        mov r24,r22
        cli
        sts (ivar)+1,r23
        sts ivar,r22
        sei
        ret

Naja - eher so:

    void operator= (t rhs) {
        RELOAD("r", rhs);
        cli();
        value = rhs;
        sei();
    }

> BTW: Zudem hat das sei() einen Nebeneffekt auf SREG.

Verstehe nicht, was du damit sagen willst.

Gänzlich korrekt ist natürlich eine Variante mit gerettetem SREG statt 
sei(). Und wird Interrupts, weil es um Effizienz geht, eher ungesicherte 
Zugriffe direkt auf <value> verwenden wollen.

Hallo Peter

Hast du dein Problem inzwischen gelößt bekommen?
Und hast du es mit dem externen Objekt erschlagen oder Hast du einen 
Kompfortableren Weg gefunden?

Auch sonst würde mich iteressieren was sich aus dieser Diskussion 
entwickelt oder ob sie nur im Sande verläuft. Ist dort noch wer am Ball 
geblieben?

so jetz wollt ich es wissen, was CVAVR daraus macht

void test( unsigned int val )
{
  val = 65535 / val;

 #asm("cli");

  ivar = val;

 #asm("sei");
}   

hier das Ergebnis:

....

  .MACRO __GETWRS
  LDD  R@0,Y+@2
  LDD  R@1,Y+@2+1
  .ENDM

.....

  .CSEG
_test:
;         32   val = 65535 / val;
;  val -> Y+0
  LD   R30,Y
  LDD  R31,Y+1
  LDI  R26,LOW(65535)
  LDI  R27,HIGH(65535)
  CALL __DIVW21U
  ST   Y,R30
  STD  Y+1,R31
;         33 
;         34  #asm("cli");
  cli
;         35 
;         36   ivar = val;
  __GETWRS 4,5,0
;         37 
;         38  #asm("sei");
  sei
;         39 }     
  ADIW R28,2
  RET

man sieht sehr deutlich: CVAVR hält sich trotzt Optimierung an die 
vorgegebenen zeitlichen Abläufe

Sicher entspricht dieses Verhalten nicht nur meinen sondern auch Peters 
Erwartungen.

ich behaupte mal das CVAVR damit klar punktet
Bbei bedarf kann ich gern die kompletten Files meines Testprojektes 
einstellen  aber das wesentliche ist wohl schon zusehen.

> CVAVR hält sich trotzt Optimierung an die
> vorgegebenen zeitlichen Abläufe

Kunststück. Nach diesem Code zu schliessen, ist dessen Optimierung in 
den 80ern stecken geblieben. Erstens ergibt sich aus dem Code, dass 
Parameter immer im Speicher übergeben werden, was bei einer derart 
registerorientierten CPU ziemlicher Unfug ist. Zweitens kommt dabei 
ungefähr das heraus, was GCC bei "volatile var" erzeugt.

PS: In anderen Worten: Ein schlecht optimierender Compiler wird folglich 
deinen Vorstellungen eher entsprechen als ein gut optimierender. Weil er 
ziemlich schematisch vorgeht und nicht umordnet. Bei Mikrocontrollern 
mag das eben deshalb sogar tatsächlich von Vorteil sein. Nur sollte man 
dann eben nicht über mangelnde Optimierung meckern.

nun,
an dem Code gibt es nicht viel zu optimieren und GCC scheint einfaches 
eher zu "verschlimmbessern"

Jedenfalls  weis ich hier was passiert und vermag mich darauf 
einzustellen.

Ich weiß nicht warum, aber ich mag es nicht wenn ein Programm seine 
Interessen über die Meinen hängt.

Habe die Diskussion aus Interesse mal verfolgt und bin mir jetzt sicher:

mein Umstieg zu C ist endgültig abgewählt, ich bleibe bei ASM, da weiss 
ich was passiert, wenn CLI steht, wird auch CLI ausgeführt ...basta, und 
ich bekomm nicht irgendwelche Befehle untergemogelt, die unnötig sind, 
nur um den Flash vollzubekommen.
Wenn da schon Profis wie Peter D. bei bestimmten Sachen das Handtuch 
werfen, dann hab ich wahrscheinlich mein erstes C-programm erst zur 
Rente am laufen (und bis dahin sind es noch paar Jahre).

>mein Umstieg zu C ist endgültig abgewählt, ich bleibe bei ASM

Warum meinen eigentlich viele dass C eine "Fortsetzung" von ASM ist, und 
alles was mit ASM geht auch in C geht ? Das gleiche gilt für C / C++, 
Opel / VW, Blond / Brunette, Äpfel / Birnen, etc.

Wenn du nur Projekte machst die in ASM besser realisierbar sind, fein. 
Für mich sieht's zwar so aus als ob du krampfhaft nach einem Grund 
suchst nicht auch noch C zu lernen, aber das ist nun eine rein 
subjektive boshafte Unterstellung.
Bei mir ist es fast umgekehrt: Ich kann (leider) kein ASM, aber bei 
manchen Projekten habe ich mir schon gesagt, man, das wäre in ASM gerade 
einfach besser. Nun könnte ich einerseits sagen ASM lerne ich nicht, 
weil mit C ja eh alles viel besser ist, oder ich könnte einfach sagen: 
Entweder ASM lernen oder "einfach mal die Fresse halten" (Zitat Ende)

P.S.
Warum gibt's eigentlich Toastbrot ? Laugenbrötchen schmecken doch viel 
besser!

@Jörg
Wenn man sich die Zeit nimmt, solltest Du lieber schreiben.
Ich habe 1980 auch ein Z80-System gelötet (fädeln mit ROM, D-RAM und 
Peripherie) und anschließend in Assembler programmiert, da ein 
C-Compiler zu teuer war und man sich die Zeit genommen hat.
Nachdem ich die kleinen MCU’s entdeckt hatte, die keine solchen 
Ansprüche wie ein Z80 stellen, habe ich zu Begin auch nur Assembler 
programmiert. Stellt man dann aber fest, das sich der Prozessor nur in 
Warteschleifen befindet, will man mehr. Eine Ausgabe mit Hilfe einer LED 
reicht nicht, es muss dann schon ein LCD- oder gar TFT-Display und Menue 
gesteuert sein, was natürlich nicht mehr oder nur mit großem Aufwand in 
Assembler erledigt werden kann. Bis man dann irgendwann feststellt, das 
man eigentlich nur Funktionalitäten in einer MCU reinbaut, die 
eigentlich nicht gerade sinnvoll oder schon in anderer Form billiger und 
fertig zu haben sind.
Hat man aber Zeitkritische Dinge zu verrichten, macht eigentlich 
Assembler schon Sinn, wenn man sich nicht auf die angegebenen Zeilen 
bzw. die Reihenfolge der Abarbeitung in C verlassen kann.
Ich kann nicht nachvollziehen, warum mich ein Compiler/Linker nicht 
fragt, ob die Zeilen wichtig sind oder wegoptimiert werden können.
Warum fragt mich der Compiler/Linker  nicht, ob ich Wert auf die 
Reihenfolge der Befehle lege, so wie ich es geschrieben habe, oder Der 
Compiler/Linker die Blöcke optimieren darf.
Warum arbeitet ein solcher Compiler/Linker immer im Stillen?
Warum muss ich nach 2 Jahren meine Programme überarbeiten, da sich die 
Funktionen und Libraries geändert haben und sich keine meiner Programme 
mehr ohne Fehlermeldungen und Compiler/Linker-Abbrüche übersetzen lässt? 
In ASM habe ich solche Probleme eigentlich nicht!

@Peter
Dem Peter möchte ich noch danken, das dieser Fehler hier bekannt wurde. 
Daraufhin habe ich bei mir nachgeschaut und mein Fehler beim EEPROM 
schreiben gefunden. Ich bin auch diesem Problem/Fehler aufgesessen.

Hi,

Excuse for my english, i can't write in german, so i think that a simple 
aproach can be taken, a memory barrier, that is:

void test( unsigned int val )
{
  val = 65535U /  val;

  _asm__ __volatile_ ( "" : : "memory" (val));

  cli();
  ivar = val;
  sei();
}

This will tell gcc thet you need the val at this point, so it will make 
it avaliable before the cli(), it's a little work arround that can be a 
macro to bariier any memory var, :) :

void test( unsigned int val )
{
 182:  bc 01         movw  r22, r24
  val = 65535U /  val;
 184:  8f ef         ldi  r24, 0xFF  ; 255
 186:  9f ef         ldi  r25, 0xFF  ; 255
 188:  0e 94 4e 01   call  0x29c  ; 0x29c <__udivmodhi4>

  _asm__ __volatile_ ( "" : : "memory" (val));

  cli();
 18c:  f8 94         cli

  ivar = val;
 18e:  70 93 25 02   sts  0x0225, r23
 192:  60 93 24 02   sts  0x0224, r22

  sei();
 196:  78 94         sei
}
 198:  08 95         ret