AVR C implizite Typkonvertierung, fehlerträchtig oder falsch?

[DerAltePete (Gast)]

unsigned short setup() {
        return millis() / 65536U;
}

wird zu

        rcall millis
        mov r23,r25
        mov r22,r24
        lsl r25
        sbc r24,r24
        sbc r25,r25
        ret

laut

http://avr-gcc.senthilthecoder.com/#g:!((g:!((g:!((h:codeEditor,i:(j:1,options:(colouriseAsm:%270%27,compileOnChange:%270%27),source:%27//+Type+your+code+here,+or+load+an+example.%0A%23include+%3Cstdint.h%3E%0A%0Avolatile+uint32_t+timer%3B%0Auint32_t+millis(void)+%7B+return+timer%3B+%7D%0A%0Avoid+delay_1(void)+%7B%0A++++uint32_t+timeout+%3D+millis()+%2B+1000%3B%0A++while+(+(int32_t)(timeout+-+millis())+%3E+0)%3B%0A%7D%0A%0Avoid+delay_2(void)+%7B%0A++uint32_t+start_time+%3D+millis()%3B%0A++while+(+(uint32_t)(millis()+-+start_time)+%3C+1000)+%3B%0A%7D%27),l:%275%27,n:%271%27,o:%27C+source+%231%27,t:%270%27)),k:50,l:%274%27,n:%270%27,o:%27%27,s:0,t:%270%27),(g:!((h:compiler,i:(compiler:a354,filters:(b:%270%27,commentOnly:%270%27,directives:%270%27,intel:%270%27),fontScale:0.9,options:%27-O2%27),l:%275%27,n:%270%27,o:%27%231+with+Atmel+3.5.4+(gcc+4.9.2)%27,t:%270%27)),k:50,l:%274%27,n:%270%27,o:%27%27,s:0,t:%270%27)),l:%272%27,n:%270%27,o:%27%27,t:%270%27)),version:4

Aber

unsigned short setup() {
        return millis() >> 16;
}

liefert eine Warnung und wird zu

        rcall millis
        lsl r25
        sbc r24,r24
        mov r25,r24
        ret

Kann jemand dieses Verhalten logisch erklären und die Zeile mit Shift in 
C so formulieren, dass das Erwartete herauskommt?

[DerAltePete (Gast)]

Falscher Link, sorry. Hier der richtige:

http://avr-gcc.senthilthecoder.com/#g:!((g:!((g:!((h:codeEditor,i:(j:1,options:(colouriseAsm:'0',compileOnChange:'0'),source:'unsigned+short+setup()+%7B%0A++++++++return+millis()+%3E%3E+16%3B%0A%7D'),l:'5',n:'1',o:'C+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:fsf6,filters:(b:'0',commentOnly:'0',directives:'0',intel:'0'),fontScale:0.9,options:'-O1'),l:'5',n:'0',o:'%231+with+gcc-6-branch',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4

[Rufus Τ. F. (rufus)]

Welchen Typ hat der Rückgabewert Deiner Funktion millis?

[Peter D. (peda)]

DerAltePete schrieb:
> liefert eine Warnung

Und deren Wortlaut ist?

[DerAltePete (Gast)]

Danke für den Tip. Ich dachte millis() ist bekannt, aber woher denn 
auch?!

Es gelingt mir allerdings nicht, eine Pseudo-millis() zu definieren, die 
unsigned long liefert, so dass das Gesamtergebnis stimmt.

[C-Frickler (Gast)]

DerAltePete schrieb:

> Aber
>

> unsigned short setup() {
>         return millis() >> 16;
> }
>

> liefert eine Warnung und wird zu

Die Warnung hättest du ruhig mal im Posting nennen können: millis() ist 
nicht deklariert. Der Compiler wird daher annehmen, dass es einen int 
zurückliefert und da der auf AVR nur 16 Bit breit ist, schiebst du den 
Wert komplett raus und bekommst als Rückgabewert nur noch 0 oder -1 je 
nach Vorzeichen.

> Kann jemand dieses Verhalten logisch erklären und die Zeile mit Shift in
> C so formulieren, dass das Erwartete herauskommt?

Das Problem ist erstmal nicht die Zeile mit dem Shift, sondern die 
fehlende Deklaration von millis().

[(prx) A. K. (prx)]

DerAltePete schrieb:
>         lsl r25
>         sbc r24,r24
>         mov r25,r24
>
> Kann jemand dieses Verhalten logisch erklären und die Zeile mit Shift in
> C so formulieren, dass das Erwartete herauskommt?

r25:r24 = (r25 < 0) : -1 : 0.

Das kommt raus, wenn du eine 16-Bit Integer mit Vorzeichen durch 65536 
dividierst. Ausser dem Vorzeichen bleibt nichts mehr übrig.

[DerAltePete (Gast)]

Danke A. K. und C-Frickler, völlig richtig und auf der blöden falschen 
Annahme von mir basierend, dass "unsigned long millis()" bekannt sein 
müßte, was es natürlich nicht ist.

Aber mit meinen Versuchen, eine Pseudo-"unsigned long millis()" zu 
definieren, so dass ich den Assembler-Code testen kann, bin ich bisher 
im Godbolt gescheitert. Vielleicht helft Ihr kurz?

[(prx) A. K. (prx)]

Peter D. schrieb:
>> liefert eine Warnung
>
> Und deren Wortlaut ist?

Ich tippe auf sowas wie "Missing declaration". Bei millis kommt 
eigentlich "unsigned long" raus, aber ohne Deklaration geht der Compiler 
von "int" aus.

[C-Frickler (Gast)]

DerAltePete schrieb:

> Aber mit meinen Versuchen, eine Pseudo-"unsigned long millis()" zu
> definieren, so dass ich den Assembler-Code testen kann, bin ich bisher
> im Godbolt gescheitert. Vielleicht helft Ihr kurz?

"unsigned long millis();" wäre die einfachste Möglichkeit, wenn dem 
Compiler der Funktionsinhalt unbekannt sein soll.

Ansonsten halt wie im ersten Link mit einem "return timer;" drin und 
geeigneter Definition von timer?

Es wäre einfacher dir zu helfen, wenn du mal erklären würdest warum du 
den Assemblercode anschaust und was das dahinterstehende Problem ist.

[Axel S. (a-za-z0-9)]

C-Frickler schrieb:
> Es wäre einfacher dir zu helfen, wenn du mal erklären würdest warum du
> den Assemblercode anschaust und was das dahinterstehende Problem ist.

Das "Problem" ist Größenwahnsinn bzw. mindestens Überheblichkeit, die 
ihn den Fehler beim Compiler suchen läßt. Statt vor dem Bildschirm, wo 
er mit 99% Wahrscheinlichkeit zu finden wäre.

[DerAltePete (Gast)]

Kein Fehler im Programm, pures Interesse, was der Compiler aus dem 
C-Code macht, weil ich durch einen Post hier das Tool von Godbolt 
entdecken durfte.

Nun tu ich mich aber zunächst schwer, es korrekt in Betrieb zu nehmen.

Deswegen hatte ich um Anschubförderung gebeten und keine bösartigen 
Unterstellungen erwartet.

[Oliver S. (oliverso)]

godbolt musst du nicht in Betrieb nehmen, weder korrekt noch sonstwie. 
Das macht der Betreiber für dich.

Ansonsten ist das, wie auch alle Compiler, ein SiSo-Tool. Shit in, shit 
out.

Oliver

[DerAltePete (Gast)]

Oliver S. schrieb:
> Das macht der Betreiber für dich.

Geile Wortklauberei, Hochachtung. Und so hilfreich!

DerAltePete schrieb:
> Falscher Link, sorry. Hier der richtige:
>
> 
http://avr-gcc.senthilthecoder.com/#g:!((g:!((g:!((h:codeEditor,i:(j:1,options:(colouriseAsm:'0',compileOnChange:'0'),source:'unsigned+short+setup()+%7B%0A++++++++return+millis()+%3E%3E+16%3B%0A%7D'),l:'5',n:'1',o:'C+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:fsf6,filters:(b:'0',commentOnly:'0',directives:'0',intel:'0'),fontScale:0.9,options:'-O1'),l:'5',n:'0',o:'%231+with+gcc-6-branch',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4

Hier nochmal der Link mit meinem Versuch. Wäre echt freundlich, wenn 
jemand das so ändert, dass dort ein vernünftiger unsigned long 
millis()-Dummy aufgerufen wird, da sonst der Compiler zuviel optimiert.

[Theor (Gast)]

@ DerAltePete

Du solltest Dir klarmachen, dass Compiler Werkzeuge sind, auf deren 
korrekter Funktion sich eine sehr große Anzahl Softwareentwickler 
verlassen und verlassen müssen. So ein Fehler (in so einem grundlegenden 
Zusammenhang) wäre ein ernsthaftes Alarmzeichen! Ungefähr wie in einem 
überfüllten Raum "Feuer" rufen!

Kurz: Bitte sei sehr sorgfältig und gewissenhaft, mit solchen Aussagen 
bzw. Fragen. Es ist zwar möglich und schon vorgekommen, aber äusserst 
unwahrscheinlich, dass Fehler in eher simplen Zusammenhängen in 
Compilern auftreten.

[DerAltePete (Gast)]

Hier einer meiner Versuche, der einfach zeigt, dass der Compiler 
wenigstens merkwürdige Dinge tut:

http://avr-gcc.senthilthecoder.com/#g:!((g:!((g:!((h:codeEditor,i:(j:1,options:(colouriseAsm:'0',compileOnChange:'0'),source:'unsigned+long+millis()+%7B%0A++return+(unsigned+long)micros()+%2B+micros()%3C%3C16%3B%0A%7D%0A%0Aunsigned+short+setup()+%7B%0A++unsigned+long+x+%3D+millis()%3E%3E16%3B%0A++return+x+%2Bx%3B%0A%7D'),l:'5',n:'1',o:'C+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:a354,filters:(b:'0',commentOnly:'0',directives:'0',intel:'0'),fontScale:0.9,options:'-O1'),l:'5',n:'0',o:'%231+with+Atmel+3.5.4+(gcc+4.9.2)',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4

[Theor (Gast)]

DerAltePete schrieb:
> Hier einer meiner Versuche, der einfach zeigt, dass der Compiler
> wenigstens merkwürdige Dinge tut:

Ja ja. Suprafluide Substanzen sind auch merkwürdig.

[DerAltePete (Gast)]

Theor schrieb:
> Bitte sei sehr sorgfältig und gewissenhaft, mit solchen Aussagen
> bzw. Fragen.

Ja, das war dumm von mir und ich würde wenn ich könnte den Titel ändern 
in z.B. "Godbolt dazu bringen, Arduino Machienencode zu erzeuge" oder 
so... Sorry

Ich habs jetzt auch geschaft, den Compiler soweit zu überlisten und ja, 
er tut was er soll:

http://avr-gcc.senthilthecoder.com/#g:!((g:!((g:!((h:codeEditor,i:(j:1,options:(colouriseAsm:'0',compileOnChange:'0'),source:'unsigned+long+millis()+%7B%0A++return+(unsigned+long)micros()+%2B+micros()%3C%3C16%3B%0A%7D%0A%0Aunsigned+short+setup()+%7B%0A++unsigned+long+y+%3D+millis()%3B%0A++%0A++unsigned+short+x+%3D+millis()%3E%3E16%3B%0A++return+x+%2Bx+/+y%3B%0A%7D'),l:'5',n:'1',o:'C+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:a354,filters:(b:'0',commentOnly:'0',directives:'0',intel:'0'),fontScale:0.9,options:'-O1'),l:'5',n:'0',o:'%231+with+Atmel+3.5.4+(gcc+4.9.2)',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4

  unsigned long x = millis()>>16;

wird zu

        rcall millis
        mov r13,r25
        mov r12,r24
        clr r14
        clr r15

[(prx) A. K. (prx)]

DerAltePete schrieb:
> Hier einer meiner Versuche, der einfach zeigt, dass der Compiler
> wenigstens merkwürdige Dinge tut:

Wenn der Compiler die Wahl hat, das zu tun was du sagst, und das zu tun 
was du meinst, entscheidet er sich eigentlich immer für Ersteres.

[Nico W. (nico_w)]

Wo ist denn das Problem das Millis aus meinem Beispiel zu übernehmen?

[Rufus Τ. F. (rufus)]

DerAltePete schrieb:
> Danke für den Tip. Ich dachte millis() ist bekannt, aber woher denn
> auch?!

Willst Du, daß man Dir bei Deinem Problem hift?

Ich benutze nicht Deinen Programmcode und Dein Entwicklungssystem, aber 
ich finde, daß Du auf meine Frage Dir die geschätzt 30 Sekunden Zeit 
spendieren können solltest, die Antwort herauszufinden und zu posten.

Ich bin mir recht sicher, daß Dein Problem genau damit zu tun haben 
wird, und genau deswegen habe ich Dir die Frage gestellt.

[Axel S. (a-za-z0-9)]

DerAltePete schrieb:
> mit meinen Versuchen, eine Pseudo-"unsigned long millis()" zu
> definieren, so dass ich den Assembler-Code testen kann, bin ich bisher
> im Godbolt gescheitert

Ernsthaft?

unsigned long millis();

unsigned short setup() {
        return millis() >> 16;
}

Das war dir zu schwierig? Eventuell willst du ja auch nochmal den 
Unterschied zwischen Deklaration und Definition in C nachlesen.


DerAltePete schrieb:
> Hier einer meiner Versuche, der einfach zeigt, dass der Compiler
> wenigstens merkwürdige Dinge tut

Merkwürdigkeit liegt im Auge des Betrachters. Der Compiler tut schon das 
Richtige. Nur gilt eben: garbage in - garbage out. Auch der beste Koch 
kann aus ScheiXXe kein wohlschmeckendes Kompott zaubern.

[Eric B. (beric)]

Axel S. schrieb:
> Ernsthaft?

Je nachdem wie man millis() in Godbolt definiert, declariert oder 
implementiert, und welche Optimierungsoptionen man einstellt, ändert 
sich auch der generierte Code von "setup". Für Menschen die den AVR 
nicht von innen und aussen kennen, kann das schon für Verwirrung sorgen.

unsigned long millis() {
  // Damit millis() nichts konstantes zurückliefert
  // und nicht wegoptimiert werden kann
  static long x;
  return ++x;
}

unsigned short setup() {
        return millis() >> 16;
}

[(prx) A. K. (prx)]

Eric B. schrieb:
> unsigned long millis() {
>   // Damit millis() nichts konstantes zurückliefert

So gehts einfacher: extern unsigned long millis(void);

Generell würde ich in C von f() abraten, f(void) ist besser.

[Axel S. (a-za-z0-9)]

Eric B. schrieb:
>
> Je nachdem wie man millis() in Godbolt definiert, declariert oder
> implementiert, und welche Optimierungsoptionen man einstellt, ändert
> sich auch der generierte Code von "setup".

Jein. So lange millis() in der aktuellen Übersetzungseinheit lediglich 
deklariert, aber nicht definiert ist, hat der Compiler keine andere 
Option, als einen rcall zu millis() zu generieren und dann das Ergebnis 
wie gefordert zu manipulieren. Was - aufgrund des avr-gcc ABI [1] - auf 
eine Nulloperation hinausläuft. Denn millis() liefert sein unsigned long 
Resultat in R25..R22 zurück mit dem MSB in R25. setup() liefert sein 
unsigned int Resultat in R25:R24 zurück, was erfreulicherweise schon 
genau die gewünschten beiden höherwertigen Bytes des Rückgabewerts von 
millis() enthält. Sowohl die Schiebeoperation als auch die Division 
durch 65536 optimiert der Compiler zu - nichts. In jeder 
Optimierungsstufe außer O0 - da kopiert er die Daten ein bißchen im 
Kreis herum.

> Für Menschen die den AVR nicht von innen und aussen kennen, kann
> das schon für Verwirrung sorgen.

Wenn man den Anspruch hat, den von avr-gcc generierten Code verstehen 
und gar dessen Korrektheit oder Qualität beurteilen zu wollen, dann 
muß man mindestens die Aufrufkonventionen des Compilers kennen.


[1] https://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage

[DerAltePete (Gast)]

Rufus Τ. F. schrieb:
> Welchen Typ hat der Rückgabewert Deiner Funktion millis?

DerAltePete schrieb:
> Danke für den Tip. Ich dachte millis() ist bekannt, aber woher
> denn
> auch?!

Rufus Τ. F. schrieb:
> Ich bin mir recht sicher, daß Dein Problem genau damit zu tun haben
> wird, und genau deswegen habe ich Dir die Frage gestellt.

Ja, hatte es und deswegen hatte ich ja auch "Danke für den Tip" gesagt. 
Das war der Kern des Problems.

Alles andere war nur noch meine Unfähigkeit, den Godbolt zu beherrschen 
und eine vernünftige Herumprobierumgebung zu schaffen.

Es hat ja am Schluss geklappt, und

Nico W. schrieb:
> Wo ist denn das Problem das Millis aus meinem Beispiel zu
> übernehmen?

ja, das hätte ich mal tun sollen. Und Eric B. und A. K. haben auch gute 
Vorschläge. Und schön, dass Axel S. mir wieder ein paar Dinge 
wachgerufen hat.

Das einzige Problem ist, der zu oft unterschwellig unfreundliche und 
leicht überhebliche Ton. In keinem anderen Forum der Welt nehmen sich 
die Mitglieder diesen "Gotteston", Tenor "Du kleiner Wurm, freu Dich, 
dass ich Dich nicht zerquetsche" heraus.

Man wird wie ein Idiot behandelt und es spielt auch keine Rolle, dass 
ich in meinem Leben >1Mio Zeilen C-Code geschrieben habe. Mir bleibt 
also nur noch, wie so vielen anderen hier, mich irgendwann wieder als 
Gast mit neuer Identität anzumelden. Nette Leute gibts hier auch, aber 
sie sind so selten

[Stefan F. (Gast)]

DerAltePete schrieb:
> Das einzige Problem ist, der zu oft unterschwellig
> unfreundliche und leicht überhebliche Ton.

Du bist aber auch nicht viel besser. Hast damit angefangen, Fehler im 
Compiler herauf zu beschwören. Dabei wissen wir alle, dass der Fehler in 
99% der Fälle vor dem Bildschirm sitzt.

> In keinem anderen Forum der Welt nehmen sich die Mitglieder
> diesen [ton] ... heraus.

Doch. Nicht überall aber in vielen Foren. Zum Beispiel im Heise Forum, 
oft auch auf Tagesschau.de und in diversen Beauty Foren die meine Frau 
nutzt geht es auch heftig ab.

[DerAltePete (Gast)]

Stefanus F. schrieb:
>> In keinem anderen Forum der Welt nehmen sich die Mitglieder
>> diesen [ton] ... heraus.
>
> Doch. Nicht überall aber in vielen Foren. Zum Beispiel im Heise Forum,
> oft auch auf Tagesschau.de und in diversen Beauty Foren die meine Frau
> nutzt geht es auch heftig ab.

Na dann ist ja alles im Lot.

Adieu