Fragezeichen in C-Code - was ist das?

[roehrevorheizer (Gast)]

Hallo ,


ich bin beim Experimentieren mit Code für GLCDs auf solche Passagen 
gestoßen und wundere mich über das Fragezeichen:


http://members.chello.at/~easyfilter/bresenham.html

 xx += sx; xx *= sx = x0 < x2 ? 1 : -1;          /* x step direction */
      yy += sy; yy *= sy = y0 < y2 ? 1 : -1;          /* y step 
direction */


Was für eine Konstruktion ist das da mit dem Fragezeichen und dem 
Doppelpunkt?
Wo könnte man darüber etwas nachlesen?


Wäre für Tipps dankbar.


mit freundlichem Gruß

[Mike (Gast)]

Gucke hier...

http://gd.tuwien.ac.at/languages/c/cref-mleslie/master_index.html

[roehrevorheizer (Gast)]

schon geguckt - - danke.

http://gd.tuwien.ac.at/languages/c/cref-mleslie/SYNTAX/conditional.html

[roehrevorheizer (Gast)]

am wichtigsten ist dies hier:

Unless you are writing time critical code (and lets face it, thats 
unlikely) the more efficent code is not much of a reason to use this 
construct. I feel that it has its uses, but should not be lost into some 
complex statement, but, since when did C programmers worry if anyone 
else could read their code ;-)

[Michael R. (Firma: Brainit GmbH) (fisa)]

Wobei ich in dem Code die 'conditional expression' wesentlich weniger 
schlimm finde (eigentlich gar nicht) als das hier:

xx *= sx = x0 < x2 ? 1 : -1;

Zuweisungen als Operanden mag ich gar nicht :-)

[Peter S. (psavr)]

xx += sx; xx *= sx = x0 < x2 ? 1 : -1;

oder besser...

xx += sx;
if (x0 < x2)
{
  sx  = 1;
}
else
{
  sx  = -1;
}
xx *= sx;

[Oliver S. (oliverso)]

roehrevorheizer schrieb:
> am wichtigsten ist dies hier:
> Unless you are writing time critical code

Der Teil ist allerdings mit aktuellen Compilern Unsinn. Der 
Fragezeichenoperator führt zu keinem schnelleren Code, als eine 
if/else-Konstruktion.

Oliver

[Markus F. (mfro)]

Das mit dem ternary operator ist m.E. nicht schwieriger zu lesen als ein 
if-Konstrukt. Ist halt so wie mit vielen Dingen: "was der Bauer nicht 
kennt, das frißt er nicht".

Es gibt eine Sache, die der ternary operator besser/mehr kann als 
if/else:

const int m = (a > b) ? a : b;

Das geht mit if/else so nicht.

[Dussel (Gast)]

Markus F. schrieb:
> Das mit dem ternary operator ist m.E. nicht schwieriger zu lesen als ein
> if-Konstrukt. Ist halt so wie mit vielen Dingen: "was der Bauer nicht
> kennt, das frißt er nicht".
Genau das. In vielen Fällen ist es deutlich einfacher zu lesen. Vor 
Allem, wenn auch noch sinnvoll kommentiert ist.

[Random .. (thorstendb)]

Wieder mal mein Lieblingsbeispiel :-)

led_out(1 << (ledCnt = ++ledCnt<8 ? ledCnt : 0));

Normalerweise benutze ich diesen Operator aber nur für true/false.

[Dussel (Gast)]

Random ... schrieb:
> Wieder mal mein Lieblingsbeispiel :-)
>

led_out(1 << (ledCnt = ++ledCnt<8 ? ledCnt : 0));

>
> Normalerweise benutze ich diesen Operator aber nur für true/false.
Kurz, übersichtlich und für einen erfahrenen C- oder Java-Programmierer 
problemlos zu lesen. So sollte man Operatoren meiner Meinung nach 
nutzen.

[Peter D. (peda)]

Oliver S. schrieb:
> Der Teil ist allerdings mit aktuellen Compilern Unsinn. Der
> Fragezeichenoperator führt zu keinem schnelleren Code, als eine
> if/else-Konstruktion.

Es gibt keinen Deckel, der auf alle Töpfe paßt.
Manchmal ist ?: schneller und manchmal if/else.

[Oliver S. (oliverso)]

Peter Dannegger schrieb:
> Manchmal ist ?: schneller und manchmal if/else.

Na ja, jeder einigermaßen anständige Compiler sollte für beide Varianten 
gleich schnellen Code erzeugen. Semnatisch ist das schließlich absolut 
identisch.

Oliver

[Peter II (Gast)]

Oliver S. schrieb:
> Na ja, jeder einigermaßen anständige Compiler sollte für beide Varianten
> gleich schnellen Code erzeugen. Semnatisch ist das schließlich absolut
> identisch.

ja nach Anwendung aber nicht.

if ( a<b ) 
  foo( a )
else 
  foo( b );

vs

foo( a<b ? a : b )

hier könnte ich mir durchaus vorstellen das nicht der gleiche asm code 
generiert wird.

[Oliver S. (oliverso)]

Peter II schrieb:
> hier könnte ich mir durchaus vorstellen

Kannst du.

Peter II schrieb:
> das nicht der gleiche asm code
> generiert wird.

Warum? Wenn du es genau wissen willst, prüf es doch einfach nach, mit 
eingeschalteter Optimierung.

Oliver

[Peter II (Gast)]

Oliver S. schrieb:
> Warum?

weil es 2 verschiedene dinge sind, beim IF sind 2 funktionsaufrufe beim 
? nur einer.

> Wenn du es genau wissen willst, prüf es doch einfach nach, mit
> eingeschalteter Optimierung.
dafür habe ich hier kein passendes System am laufen.

[plex (Gast)]

Random ... schrieb:
> Wieder mal mein Lieblingsbeispiel :-)led_out(1 << (ledCnt = ++ledCnt<8 ?
> ledCnt : 0));
>
> Normalerweise benutze ich diesen Operator aber nur für true/false.
Das ist aber schon ein ziemliches Stückchen. Auch wenn ich nicht ganz 
unerfahren bin, bevorzuge ich den langen Weg. Die Kurzschreibweise muß 
ich ja schließlich auch im Kopf wieder "unfolden", um dahinter zu 
steigen. Da ist eine ordentliche lange Schreibweise sehr viel 
einleuchtender, insbesondere, wenn keine Kommentare im Quelltext 
vorhanden sind. Hatte das schon und das macht keinen Spaß, wenn der 
Urheber von kryptischem Code der Meinung ist, daß alles sich nach ihm zu 
richten hat und "the code is the comment" oberste Prämisse ist. Das kann 
sich im Projekt sehr verzögernd auswirken.
Mir kann auch keiner erzählen, daß er nach einem halben Jahr noch gena 
weiß, was er an so einer üblen Stelle bewirken wollte, ohne mehrfach 
über den Code zu gehen. Deshalb: Der lange Weg ist der bessere.

Peter II schrieb:
> weil es 2 verschiedene dinge sind, beim IF sind 2 funktionsaufrufe beim
> ? nur einer.
Das ist doch Quark. Der ASM macht einen Branch oder so je nach Prozessor 
draus. Denkst du nicht, daß der Compiler beide Varianten in dieselbe 
Form überführt, bevor er es übersetzt? Beides hat dieselbe Wirkung. Du 
machst dir damit um den Preis der "Coolness" nur selber das Leben 
schwer.

[Peter II (Gast)]

plex schrieb:
> Das ist doch Quark. Der ASM macht einen Branch oder so je nach Prozessor
> draus.

nein macht er nicht.

Version mit IF

        call    rand
        movl    $20, %edi
        movl    %eax, %ebx
        xorl    %eax, %eax
        call    rand
        cmpl    %eax, %ebx
        jl      .L8
        movl    %eax, %edi
        call    foo
        popq    %rbx
        .cfi_remember_state
        .cfi_def_cfa_offset 8
        .p2align 4,,3
        ret
.L8:
        .cfi_restore_state
        movl    %ebx, %edi
        call    foo
        popq    %rbx
        .cfi_def_cfa_offset 8
        .p2align 4,,5
        ret
        .cfi_endproc

Version mit ?

        call    rand
        movl    $20, %edi
        movl    %eax, %ebx
        xorl    %eax, %eax
        call    rand
        cmpl    %ebx, %eax
        cmovle  %eax, %ebx
        movl    %ebx, %edi
        call    foo
        popq    %rbx
        .cfi_def_cfa_offset 8
        ret

#include <stdio.h>

void __attribute__ ((noinline))  foo( int x )
{
   printf("x = %d\n");
}

int main()
{
  int a = rand(10);
  int b = rand(20);
/*
  if ( a<b )
     foo( a );
  else
     foo( b );
*/
  foo( a < b ? a : b );
}

gcc test.c -S -O2

[SF (Gast)]

Wenn du aber denselben Test mit -Os machst

avr-gcc test.c -S -Os

so kommt beim Winavr2010 beides mal derselbe Assembler Code raus:

foo:
/* prologue: function */
/* frame size = 0 */
  rcall .
  ldi r24,lo8(.LC0)
  ldi r25,hi8(.LC0)
  in r30,__SP_L__
  in r31,__SP_H__
  std Z+2,r25
  std Z+1,r24
  rcall printf
  pop __tmp_reg__
  pop __tmp_reg__
/* epilogue start */
  ret
  .size  foo, .-foo
.global  main
  .type  main, @function
main:
  push r28
  push r29
/* prologue: function */
/* frame size = 0 */
  ldi r24,lo8(10)
  ldi r25,hi8(10)
  rcall rand
  mov r28,r24
  mov r29,r25
  ldi r24,lo8(20)
  ldi r25,hi8(20)
  rcall rand
  cp r28,r24
  cpc r29,r25
  brge .L4
  mov r24,r28
  mov r25,r29
.L4:
  rcall foo
/* epilogue start */
  pop r29
  pop r28
  ret

D.H. mit den richtigen Optimierungseinstellungen verhält sich der 
Compiler, so wie erwartet.

[Peter D. (peda)]

plex schrieb:
> Das ist doch Quark. Der ASM macht einen Branch oder so je nach Prozessor
> draus.

Nö, der Assemblercode kann manchmal gleich sein, ist es aber oft nicht.
Es gibt 2 Hauptunterschiede:
Der ? Operator ist ein Sequence point.
Der ? Operator hat einen Wert, if aber nicht.

[Peter II (Gast)]

SF schrieb:
> D.H. mit den richtigen Optimierungseinstellungen verhält sich der
> Compiler, so wie erwartet.

was ist an -Os richtiger als -Os - wird sind bei GCC nicht beim µC. 
Außerdem ist es auch mit -Os auf einen PC nicht gleich. Und nicht so wie 
du erwartest.

[Torsten (Gast)]

plex schrieb:

> Mir kann auch keiner erzählen, daß er nach einem halben Jahr noch gena
> weiß, was er an so einer üblen Stelle bewirken wollte, ohne mehrfach
> über den Code zu gehen. Deshalb: Der lange Weg ist der bessere.

der Code sollte so geschrieben werden, dass Kollegen ihn lesen können. 
Das bedeutet nicht, dass ihn jeder Berufsanfänger lesen können muss, der 
sich nicht die Mühe macht, eine Sprache vor der Verwendung zu lernen.

?: ist ein Operator, mit dem sich z.B: auch Konstanten initialisieren 
lassen:

const int f = a ? b : c;

das geht nicht:

const int f = b;
if (!a)
  f = c;

[Vlad T. (vlad_tepesch)]

plex schrieb:
> Der ASM macht einen Branch oder so je nach Prozessor
> draus.

eventuell aber auch einen "conditional move", der exakt der Semantik von

int f = a ? b : c;

entspricht, auch wenn der Kompiler eventuell auch so clever ist, ein if 
else dahingehend zu überführen

int f;
if (a)
  f = b;
else
  f = c;

ich finde ersteres lesbarer

[plex (Gast)]

Peter II schrieb:
> was ist an -Os richtiger als -Os - wird sind bei GCC nicht beim µC.
Du warst bei -O2 und das ist nun mal was anderes als -Os.
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

> Außerdem ist es auch mit -Os auf einen PC nicht gleich. Und nicht so wie
> du erwartest.
Und warum reitest du dann auf dem anders generierten ASM Code rum? Kann 
dir doch egal sein was beim PC-ASM rauskommt, wenn Codesize keine Rolle 
spielt und das Ergebnis stimmt.

[Peter II (Gast)]

plex schrieb:
> Und warum reitest du dann auf dem anders generierten ASM Code rum? Kann
> dir doch egal sein was beim PC-ASM rauskommt, wenn Codesize keine Rolle
> spielt und das Ergebnis stimmt.

Ich wollte nur zeigen das mit am dem ? auch schnelleren code als mit if 
schreiben kann. Oben hat jemand behauptet  hat, in beiden Fälle kommt 
der gleiche code raus - das stimmt nicht.

es bezog sich alles auf

Peter II schrieb:
> weil es 2 verschiedene dinge sind, beim IF sind 2 funktionsaufrufe beim
> ? nur einer.
Das ist doch Quark. Der ASM macht einen Branch oder so je nach Prozessor
draus. Denkst du nicht, daß der Compiler beide Varianten in dieselbe
Form überführt, bevor er es übersetzt?

[Michael R. (Firma: Brainit GmbH) (fisa)]

Peter II schrieb:
> Das ist doch Quark. Der ASM macht einen Branch oder so je nach Prozessor
> draus. Denkst du nicht, daß der Compiler beide Varianten in dieselbe
> Form überführt, bevor er es übersetzt?

Wer lesen kann, ist strategisch im Vorteil:

Peter Dannegger schrieb:
> Der ? Operator ist ein Sequence point.
> Der ? Operator hat einen Wert, if aber nicht.

[Oliver S. (oliverso)]

Peter Dannegger schrieb:
> Der ? Operator ist ein Sequence point.
Genauso wie die "Controlling Expression" im if-statement. Kein 
Unterschied.

> Der ? Operator hat einen Wert, if aber nicht.
Richtig. Genau deshalb gibt es den Operator. Drückt man das mit if/else 
aus, braucht es dafür eine lokale Variable. Da es in Assembler aber 
"einen Wert" nicht gibt, da muß alles irgendwo abgelegt werden, egal, ob 
"Wert" oder "Variable", gibt es deshalb alleine keinen Grund, 
unterschiedlichen Assemblercode zu erzeugen.

Oliver

[plex (Gast)]

Torsten schrieb:

 const int f = a ? b : c;

> das geht nicht:

const int f = b;
if (!a)
   f = c;

Das stimmt aber so nicht ganz. Wenn du es richtig nach deiner 
"contition" ausformulieren würdest, kämest du auf:

const int f;
if (a)
  f = b;
else
  f = a;

So wäre das richtig verwendet und steht deinem Ausdruck in nichts nach. 
Ohne Voodoo und dazu noch übersichtlich.
Mit dem "!" (not) kann man gehörig auf die Nase fallen, wenn es sich 
nicht um true/false Werte handelt. Alles schon gesehen.

[avr (Gast)]

plex schrieb:
> const int f;
> if (a)
>   f = b;
> else
>   f = a;
> So wäre das richtig verwendet und steht deinem Ausdruck in nichts nach.
> Ohne Voodoo und dazu noch übersichtlich.

Nicht wirklich. Eher redudanter Code und dazu deutlich länger.

> Mit dem "!" (not) kann man gehörig auf die Nase fallen, wenn es sich
> nicht um true/false Werte handelt. Alles schon gesehen.

Das wäre mir neu. Aber wer denkt true == 1, dem kann das schon 
passieren.

[Oliver S. (oliverso)]

Torsten schrieb:
> das geht nicht

plex schrieb:
> const int f;
> if (a)
>   f = b;
> else
>   f = a;
> ... und steht deinem Ausdruck in nichts nach.

Stimmt. Geht genauso wenig.

Oliver

[plex (Gast)]

Oliver S. schrieb:
> Stimmt. Geht genauso wenig.
Jup, da habe ich mich wohl zu schnell blenden lassen. Hast recht :-)

[plex (Gast)]

avr schrieb:
> Nicht wirklich. Eher redudanter Code und dazu deutlich länger.
Führt aber zu weniger Verwirrung und schnellerer Erfassung der Aufgabe 
des Codes. Und jetzt komm hier nicht mit Redundanz und Sourcecodelänge 
in Zeiten von Terabyte Festplatten um die Ecke. Da kann man Kommentare 
auch gleich weglassen und sofort binär programmieren. Das ist nun gar 
kein Argument.

[Karl H. (kbuchegg)]

plex schrieb:
> avr schrieb:
>> Nicht wirklich. Eher redudanter Code und dazu deutlich länger.
> Führt aber zu weniger Verwirrung und schnellerer Erfassung der Aufgabe
> des Codes.

  if( haveError )
    penColor = RED;
  else
    penColor = BLACK;

  if( isOutputPin )
    penStyle = NORMAL;
  else
    penStyle = ITALIC;

  if( isAboveMaximum )
    strcpy( fontName, "Times Roman" );
  else
    strcpy( fontName, "Arial" );

  drawText( pinName, penColor, penStyle, fontName );

versus

  drawText( pinName,
            haveError ? RED : BLACK,
            isOutputPin ? NORMAL : ITALIC,
            isAboveMaximum ? "Times Roman" : "Arial"
          );

die Variante ohne Hilfsvariablen mit ineinander geschaltelten if-else 
Konstrukten, die in 6 unterschiedlichen Aufrufen von DrawText münden, 
will ich mir erst gar nicht ausmalen.

Wie immer gilt: man kann jedes Sprachkonstrukt zum Vorteil des 
Programmierers ausnutzen. Man kann es aber auch übertreiben und dann 
dreht sich der Effekt ins Gegenteil um.

[plex (Gast)]

Karl Heinz schrieb:
> Wie immer gilt: man kann jedes Sprachkonstrukt zum Vorteil des
> Programmierers ausnutzen. Man kann es aber auch übertreiben und dann
> dreht sich der Effekt ins Gegenteil um.
Hier muß ich dir beipflichten. Eine Sache noch: Wie sieht es beim Debug 
aus? Meiner Erfahrung nach sind die Kurzkonstrukte da wirklich nicht 
hilfreich, weil einfach die Übersicht fehlt (und auch die 
Hilfsvariablen), wenn der Marker nur in derselben Zeile herumtanzt. Da 
sind mir - wenn auch verschachtelte - if-Konstrukte sehr viel lieber. 
Kann ja sein, daß nur ich und wenige Andere schlechte Erfahrungen mit 
der Kurzschreibweise gemacht habe.

[Jörg W. (dl8dtl) (Moderator)]

plex schrieb:
> Wie sieht es beim Debug aus? ... (und auch die Hilfsvariablen)

Hilfsvariablen optimiert der Compiler sowieso gnadenlos weg, auf die
brauchst du also beim Debuggen nicht zu zählen.

Wenn du dir Zwischenwerte fürs Debuggen merken willst, dann musst
du entweder den Code verfolgen (in welchem CPU-Register steht was?),
oder du legst dir eine temporäre Variable an, die du “volatile”
markierst, und lässt den Compiler dahin den Wert schreiben.

Gleiches trifft auf die verschachtelten if-Konstrukte zu: wie wir
oben schon gesehen haben, ist die Chance groß, dass sie ohnehin den
gleichen Code produzieren wie die ?:-Operatoren, damit ist auch
klar, dass sich beim Debuggen keins vom anderen unterscheiden wird.

Je neuer der Compiler und je besser die CPU, um so größer die Chance,
dass man nichts mehr „geradlinig“ debuggen kann.  „Bessere“ CPUs sind
hier Dinge wie ARM oder AVR im Vergleich zum alten i386, denn sie
haben deutlich mehr freie Register, die der Compiler nutzen kann.
Damit steigt aber die Chance, dass er eben auch im Codefluss deutlich
vom niedergeschriebenen C-Code abweichen kann.

[Detlef K. (adenin)]

Jörg Wunsch schrieb:
> „Bessere“ CPUs sind
> hier Dinge wie ARM oder AVR im Vergleich zum alten i386, denn sie
> haben deutlich mehr freie Register, die der Compiler nutzen kann.

Du vergleichst da zwei unterschiedliche Rechnerarchitekturen: CISC 
(i386) und RISC (ARM, AVR).
Das hat aber nichts mit "Besserer" CPU zu tun.

[Jörg W. (dl8dtl) (Moderator)]

Detlef Kunz schrieb:
> Das hat aber nichts mit "Besserer" CPU zu tun.

Aber mit dem, was der Compiler im Codeablauf für Freiheiten genießt.
Daher habe ich das „besser“ auch in Anführungszeichen geschrieben.

Außerdem ist ein AVR nicht so ganz ernsthaft RISC (im Sinne der
ursprünglichen RISC-Definition), und auch ein amd64 hat deutlich
mehr freie Register für den Compiler als ein i386, obwohl er wohl
nun ganz eindeutig CISC ist.

[Peter II (Gast)]

Jörg Wunsch schrieb:
> und auch ein amd64 hat deutlich
> mehr freie Register für den Compiler als ein i386, obwohl er wohl
> nun ganz eindeutig CISC ist.

sicher?

so eindeutig ist das ganze schon lange nicht mehr.

Google: "i7 CISC oder risc"

[Torsten (Gast)]

Hallo plex,

plex schrieb:

> Führt aber zu weniger Verwirrung und schnellerer Erfassung der Aufgabe
> des Codes.

das ist wirklich eine Übungssache. Anfänger können sich oft auch nicht 
die Operator precedence merken und machen dann vorsichtshalber mal um 
alles eine Klammer. Natürlich auch der Lesbarkeit wegen. Ein erfahrener 
Entwickler fragt sich, warum da Klammern sind, nimmt die Klammern in 
Gedanken weg und ist erstaunt darüber, dass die Klammer überflüssig 
waren und damit keine Aussage getroffen haben. Kleine Anekdote: Ein 
Kollege von mir hat immer Klammer um den Rückgabewert einer Funktion 
gemacht. Als er meinte, dass es so übersichtlicher wäre, habe ich Ihm 
gesagt, er solle zwei Klammern drum machen, damit es noch 
übersichtlicher wird ;-)

Also immer:

return ((result));

> Da kann man Kommentare
> auch gleich weglassen und sofort binär programmieren.

Das gleiche gilt für Kommentare. Wenn der Programmfluss mit Kommentaren 
erklärt werden muss, es also kein Mittel gibt, diesen auch ohne 
Kommentar klar erkennbar zu machen, dann ist das was "kompliziert". 
Redundante Kommentare neigen dazu, sehr schnell zu altern, mit dem 
Effekt, dass man dann Kommentare hat, die nicht mehr zu Code passen und 
man sich fragt, was von beiden nun richtig ist.

Den schlimmsten Kode, den ich bis jetzt gesehen habe, hat sich vor 
allem, durch viele Kommentare ausgezeichnet :-(

mfg Torsten

[Karl H. (kbuchegg)]

Torsten schrieb:

> Kleine Anekdote: Ein
> Kollege von mir hat immer Klammer um den Rückgabewert einer Funktion
> gemacht.

Konsequenterweise müsste er dann auch schreiben

  i = ( 5 );

das ist dann genau aus dem gleichen Grund übersichtlicher :-)

[steffen (Gast)]

Gut geschriebener C-Code ist selbsterklärend und braucht keine 
Kommentare:

http://www.ioccc.org/2011/goren/goren.c

[steffen (Gast)]

Hier ist noch ein schöneres Programm:
http://www.ioccc.org/2011/hou/hou.c

[Norbert (Gast)]

Karl Heinz schrieb:
>
> Konsequenterweise müsste er dann auch schreiben
>

   i = ( 5 );

>
> das ist dann genau aus dem gleichen Grund übersichtlicher :-)

Finde ich gut, da weiss man auf jeden Fall in welcher Reihenfolge die 5 
ausgewertet wird! ;-)

[bäh (Gast)]

c ist eine Sprache oder eine Krankheit?
Zum Glück nicht Ansteckend!

[roehrenvorheizer (Gast)]

Hallo Leute,

na, mit so einer Frage zu einem seltenen Operator kann man aber eine 
ganz schöne Lawine los treten!

Deshalb hier im Foto noch ein Beispiel für einen Operator oder einen 
anderen. Aus Zeiten vor C.

Danke für die Zuschriften auch der Moderatoren und die Erweiterung 
meines Wissens.
mfG

[Fer T. (fer_t)]

Also ich habe auch noch bisher keinen Fall erlebt wo ? oder if sich im 
Assembler unterschieden hätte (mit Optimierung an).
Sehe auch nicht den Grund warum das der Fall sein sollte, ich würde auch 
als Compiler ? und if gleichsetzen.

Ich persönlich nutze den ? Operator aber selber auch gerne, wenn auch 
eigentlich nur für bedingte Zuweisungen alla:

a = d < f ? d : f;

PS hab mal mein Beispiel angegangen (kompiliert mit gcc -O2 -S).