Wie in C zum Quadrat?

Wenn eine weitere Zeile OK ist: x*=x;

Armin W. schrieb:
> dann muss er den langen term widerholen ;)

Ich meinte eher:

x=[...langer Term...];
x*=x;

Blähboy schrieb:
> Wie schreibe im in C einen längeren Ausdruck zum Quadrat?

Indem du diesen Term einmal berechnest, in eine Variable stopfst und 
dann diese mit sich selbst multiplizierst.

In was für einem Kindergarten sind wir denn hier???

W.S.

Fritz Kuckuck schrieb im Beitrag #6173046:
> W.S. schrieb:
>> In was für einem Kindergarten sind wir denn hier???
>>
>> W.S.
>
> Gereizte Leute viel ich find!
> Doch wo sind die, die reizend sind?

Und ich finde das war noch diplomatisch ausgedrückt.

wassn aus *math.h* geworden?
pow(x,2) 'd die nichtmehr in C?

M. K. schrieb:
> Frage nicht gelesen

auweh.. moi gehört in Morpheus Arme ;)

Sven B. schrieb:
> Hast du mal ein Beispiel für einen Compiler, der pow(x, 2) in x*x
> optimiert für x double? Ich kenne keinen der das tut.

GCC, Clang.

Wo ist jetzt das Problem?

Du kannst

1. eine eigene Funktion mit Y = X * X definieren  oder

2. (etwas komplizierter) Y = exp(log(x - x_mitte)*2);

Sven B. schrieb:
> Dirk B. schrieb:
>> Sven B. schrieb:
>>> pow(x, 2) ist viel langsamer als x*x
>>
>> Ja.
>> Das weiß auch der Compiler und optimiert das, wenn er darf.
>
> Hast du mal ein Beispiel für einen Compiler, der pow(x, 2) in x*x
> optimiert für x double? Ich kenne keinen der das tut.

1

#include <math.h>

2

3

int main(void)

4

{

5

    volatile double x = 42.0;

6

7

    volatile double y1 = x * x;

8

    volatile double y2 = pow(x, 2);

9

}

x86-64 gcc 9.2 mit -O3:

1

main:                                   # @main

2

        main:

3

        movsd   xmm0, QWORD PTR .LC0[rip]

4

        xor     eax, eax

5

        movsd   QWORD PTR [rsp-24], xmm0

6

        movsd   xmm0, QWORD PTR [rsp-24]

7

        movsd   xmm1, QWORD PTR [rsp-24]

8

        mulsd   xmm0, xmm1

9

        movsd   QWORD PTR [rsp-16], xmm0

10

        movsd   xmm0, QWORD PTR [rsp-24]

11

        mulsd   xmm0, xmm0

12

        movsd   QWORD PTR [rsp-8], xmm0

13

        ret

14

.LC0:

15

        .long   0

16

        .long   1078263808

https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(fontScale:14,j:1,lang:___c,selection:(endColumn:2,endLineNumber:9,positionColumn:2,positionLineNumber:9,selectionStartColumn:2,selectionStartLineNumber:9,startColumn:2,startLineNumber:9),source:'%23include+%3Cmath.h%3E%0A%0Aint+main(void)%0A%7B%0A++++volatile+double+x+%3D+42.0%3B%0A%0A++++volatile+double+y1+%3D+x+*+x%3B%0A++++volatile+double+y2+%3D+pow(x,+2)%3B%0A%7D'),l:'5',n:'0',o:'C+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:cg92,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'1',trim:'1'),fontScale:14,j:1,lang:___c,libs:!(),options:'-O3',selection:(endColumn:9,endLineNumber:10,positionColumn:9,positionLineNumber:10,selectionStartColumn:9,selectionStartLineNumber:10,startColumn:9,startLineNumber:10),source:1),l:'5',n:'0',o:'x86-64+gcc+9.2+(Editor+%231,+Compiler+%231)+C',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4

clang 9.2 x86-64 mit -O3:

1

main:                                   # @main

2

        movabs  rax, 4631107791820423168

3

        mov     qword ptr [rsp - 24], rax

4

        movsd   xmm0, qword ptr [rsp - 24] # xmm0 = mem[0],zero

5

        mulsd   xmm0, qword ptr [rsp - 24]

6

        movsd   qword ptr [rsp - 8], xmm0

7

        movsd   xmm0, qword ptr [rsp - 24] # xmm0 = mem[0],zero

8

        mulsd   xmm0, xmm0

9

        movsd   qword ptr [rsp - 16], xmm0

10

        xor     eax, eax

11

        ret

https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(fontScale:14,j:1,lang:___c,selection:(endColumn:2,endLineNumber:9,positionColumn:2,positionLineNumber:9,selectionStartColumn:2,selectionStartLineNumber:9,startColumn:2,startLineNumber:9),source:'%23include+%3Cmath.h%3E%0A%0Aint+main(void)%0A%7B%0A++++volatile+double+x+%3D+42.0%3B%0A%0A++++volatile+double+y1+%3D+x+*+x%3B%0A++++volatile+double+y2+%3D+pow(x,+2)%3B%0A%7D'),l:'5',n:'0',o:'C+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:cclang900,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'1',trim:'1'),fontScale:14,j:1,lang:___c,libs:!(),options:'-O3',selection:(endColumn:28,endLineNumber:6,positionColumn:28,positionLineNumber:6,selectionStartColumn:28,selectionStartLineNumber:6,startColumn:28,startLineNumber:6),source:1),l:'5',n:'0',o:'x86-64+clang+9.0.0+(Editor+%231,+Compiler+%231)+C',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4

Hmm,

1

 movsd   xmm0, QWORD PTR [rsp-24]

2

 movsd   xmm1, QWORD PTR [rsp-24]

3

 mulsd   xmm0, xmm1

das ist ja schon wieder irgendwie traurig...

Frank M. schrieb:
> Tim T. schrieb:
>> das ist ja schon wieder irgendwie traurig...
>
> Was ist daran traurig? Beachte das "volatile" im C-Source. Das wurde
> wohl gemacht, damit der Compiler nicht direkt selbst das Ergebnis
> ausrechnet.

Das traurige ist das der gcc nicht erkennt das er einfach ein

1

movsd   xmm0, QWORD PTR [rsp-24]

2

mulsd   xmm0, xmm0

oder auch ein

1

movsd   xmm0, QWORD PTR [rsp-24]

2

mulsd   xmm0, QWORD PTR [rsp-24]

machen könnte und stattdessen zwei Register lädt...

Macht der doch?  Jedenfalls wenn man das idiotische volatile 
weglaesst...
genauso der Intel Compiler.  MS cl hinkt allerdings wieder hinterher.


#include <math.h>

double sq1(double x)
{
    return x*x;
}

double sq2(double x)
{
    return pow(x, 2);
}

==>>

sq1:
  .seh_endprologue
  mulsd  %xmm0, %xmm0
  ret
  .seh_endproc
  .globl  sq2
  .def  sq2;  .scl  2;  .type  32;  .endef
  .seh_proc  sq2
sq2:
  .seh_endprologue
  mulsd  %xmm0, %xmm0
  ret
  .seh_endproc

Udo K. schrieb:
> Macht der doch?  Jedenfalls wenn man das idiotische volatile
> weglaesst...

Der Grund fürs volatile wurde ja schon oben angeführt, die Frage ist, 
warum macht er es bei volatile nicht?

S. R. schrieb:
> Tim T. schrieb:
>> Der Grund fürs volatile wurde ja schon oben angeführt,
>> die Frage ist, warum macht er es bei volatile nicht?
>
> Weil er es nicht darf. Wenn eine Variable "volatile" ist, dann ist sie
> bei jedem Zugriff neu zu lesen, sie könnte sich ja geändert haben.

Seufz:

1

movsd   xmm0, QWORD PTR [rsp-24]

2

movsd   xmm1, QWORD PTR [rsp-24]

3

mulsd   xmm0, xmm1

soll also besser sein als:

1

movsd   xmm0, QWORD PTR [rsp-24]

2

mulsd   xmm0, QWORD PTR [rsp-24]

Nope. Sobald du eine 2 Register Operation wie z.B. mul durchführst, geht 
das gar nicht anders als sich darauf zu verlassen das der Wert 
zwischenzeitlich nicht verändert wurde.

Abgesehen davon bekommt Clang das hin...

Ich gehe weiter und behaupte das ist schlicht undefiniertes Verhalten:

1

    volatile double x = 42.0;

2

    volatile double y1 = x * x;

1) Da x als volatile ausgewiesen ist, müssen beide Multiplikatoren 
individuell ausgewertet werden (C11 5.1.2.3 6)
2) Die genannten Auswertungen sind unsequenced (C11 6.5 3)
3) Zugriff auf eine volatile Variable ist ein side effect (C11 
5.1.2.3 2)
4) unsequenced side effects, die die gleiche Variable betreffen, sind 
undefiniertes Verhalten (C11 6.5 2)

Fazit: Finger weg von volatile

Tim T. schrieb:
> Hmm,
>  movsd   xmm0, QWORD PTR [rsp-24]
>  movsd   xmm1, QWORD PTR [rsp-24]
>  mulsd   xmm0, xmm1
>
> das ist ja schon wieder irgendwie traurig...

Was genau mach dich traurig daran? Ich hätte das "volatile" auch 
weglassen können, aber dann hätte der Compiler gleich 1764 daraus 
gemacht...

Tim T. schrieb:
> Frank M. schrieb:
>> Tim T. schrieb:
>>> das ist ja schon wieder irgendwie traurig...
>>
>> Was ist daran traurig? Beachte das "volatile" im C-Source. Das wurde
>> wohl gemacht, damit der Compiler nicht direkt selbst das Ergebnis
>> ausrechnet.
>
> Das traurige ist das der gcc nicht erkennt das er einfach ein
> movsd   xmm0, QWORD PTR [rsp-24]
> mulsd   xmm0, xmm0
>
> oder auch ein
> movsd   xmm0, QWORD PTR [rsp-24]
> mulsd   xmm0, QWORD PTR [rsp-24]
>
> machen könnte und stattdessen zwei Register lädt...

Natürlich erkennt er es. Du verstehst nur nicht, was "volatile" macht.

Udo K. schrieb:
> Macht der doch?  Jedenfalls wenn man das idiotische volatile
> weglaesst...

Was genau ist deiner Meinung nach idiotisch daran? Ohne "volatile" hätte 
der Compiler das Ergebnis gleich selbst ausgerechnet, eher ungeeignet, 
wenn man das Verhalten von pow() demonstriere will.
Hätte ich das "volatile" bei y1 und y2 auch weggelassen, hätte der 
Compiler gemerkt dass das Ergebnis eh nicht verwendet wird, und die 
ganze Rechnung rausgeworfen.

Tim T. schrieb:
> die Frage ist,
> warum macht er es bei volatile nicht?

Lies ein C-Buch.

Jemand schrieb:
> Fazit: Finger weg von volatile

Aber ohne volatile funktioniert das Beispiel halt nicht.

1

#include <math.h>

2

3

int main(void)

4

{

5

    double x = 42.0;

6

7

    volatile double y1 = x * x;

8

    volatile double y2 = pow(x, 2);

9

}

wird optimiert zu

1

main:

2

        movsd   xmm0, QWORD PTR .LC0[rip]

3

        xor     eax, eax

4

        movsd   QWORD PTR [rsp-16], xmm0

5

        movsd   QWORD PTR [rsp-8], xmm0

6

        ret

7

.LC0:

8

        .long   0

9

        .long   1083936768

1

#include <math.h>

2

3

int main(void)

4

{

5

    double x = 42.0;

6

7

    double y1 = x * x;

8

    double y2 = pow(x, 2);

9

}

wird gar zu

1

main:

2

        xor     eax, eax

3

        ret

Toll, wenn es darum geht in einem echten Programm unnötige 
Rechenoperationen einzusparen, aber eher schlecht, wenn man 
demonstrieren will, zu was pow(x, 2) im ungünstigen Fall kompiliert.

vn nn schrieb:
> Was genau mach dich traurig daran? Ich hätte das "volatile" auch
> weglassen können, aber dann hätte der Compiler gleich 1764 daraus
> gemacht...

Herr, schmeiß Hirn vom Himmel. Das ist absolut klar, darum muss ja das 
volatile da hin damit der Compiler nicht direkt das vorausberechnete 
Ergebnis einträgt.

> Natürlich erkennt er es. Du verstehst nur nicht, was "volatile" macht.

Ich bin mir absolut sicher das ich das deutlich besser verstehe als du, 
nur es macht einfach keinen Sinn diese Optimierung nicht zu machen, da 
sich ausserhalb der Sequenz für die Variable nichts dadurch ändert.

> Tim T. schrieb:
>> die Frage ist,
>> warum macht er es bei volatile nicht?
>
> Lies ein C-Buch.

Ob du es glaubst oder nicht, ich hab eins gelesen, genauer gesagt waren 
es einige, dazu noch Compilerbau, Rechnerarchitektur usw. Außerdem hab 
ich Assembler und Compiler für eigene CPU Architekturen gebaut und unter 
anderem Clang und GCC auf diese Architekturen portiert. Achja, 
irgendwann hab ich auch mal ein Studium in Elektrotechnik Fachrichtung 
Informationstechnologie (Mischung aus E-Technik und Informatik) 
abgeschlossen, wobei das mittlerweile auch schon ein paar Jahre her ist.

Aber um dich nicht zu überfordern stelle ich die Frage mal neu:

"Warum meint der GCC das er

1

movsd   xmm0, QWORD PTR [rsp-24]

2

mulsd   xmm0, QWORD PTR [rsp-24]

NICHT zwischen zwei Sequenzpunkte bekommt,

1

movsd   xmm0, QWORD PTR [rsp-24]

2

movsd   xmm1, QWORD PTR [rsp-24]

3

mulsd   xmm0, xmm1

aber schon?"

Und der Vollständigkeit halber:

1

int main(void)

2

{

3

    volatile double x = 42.0;

4

    volatile double y1 = x * x;

5

}

wird beim GCC mit -O3 zu:

1

main:

2

        movsd   xmm0, QWORD PTR .LC0[rip]

3

        xor     eax, eax

4

        movsd   QWORD PTR [rsp-16], xmm0

5

        movsd   xmm0, QWORD PTR [rsp-16]

6

        movsd   xmm1, QWORD PTR [rsp-16]

7

        mulsd   xmm0, xmm1

8

        movsd   QWORD PTR [rsp-8], xmm0

9

        ret

10

.LC0:

11

        .long   0

12

        .long   1078263808

und bei CLang mit -O3 (genauer sobald irgendeine Optimierung 
angeschaltet ist) zu:

1

main:                                   # @main

2

        movabs  rax, 4631107791820423168

3

        mov     qword ptr [rsp - 16], rax

4

        movsd   xmm0, qword ptr [rsp - 16] # xmm0 = mem[0],zero

5

        mulsd   xmm0, qword ptr [rsp - 16]

6

        movsd   qword ptr [rsp - 8], xmm0

7

        xor     eax, eax

8

        ret

Markus F. schrieb:
> vn nn schrieb:
>> Toll, wenn es darum geht in einem echten Programm unnötige
>> Rechenoperationen einzusparen, aber eher schlecht, wenn man
>> demonstrieren will, zu was pow(x, 2) im ungünstigen Fall kompiliert.
>
> wenn Du nachvollziehen willst, zu was pow(x, 2) compiliert wird,
> schreib' eine Funktion und compiliere die mit -c und schau' dir an, was
> der Compiler daraus macht.
> int isquare(int i)
> {
>     return pow(i, 2);
> }
>
> Da wird nix wegoptimiert. Die Übung überlasse ich dir.

Du hättest auch selbst drauf kommen können, dass ich bei goldbolt nicht 
einfach sagen kann "kompilier halt mit -c". Und ob er das bereits tut, 
hatte ich einfach keine Lust auszuprobieren.
Aber da du scheinbar zum Thema ja nix sinnvolles beizutragen hast, musst 
du dich halt jetzt auf ein "volatile" versteifen. Traurig.

Markus F. schrieb:
> gcc (zumindest, clang weiß ich nicht) macht die 'pow()'-Optimierung nur,
> wenn man nicht mit -ffreestanding übersetzt (was ja in einer
> µC-Umgebung durchaus eher mal der Fall ist).

War ja keine Zielplattform gefragt.

Tim T. schrieb:
>> Natürlich erkennt er es. Du verstehst nur nicht, was "volatile" macht.
>
> Ich bin mir absolut sicher das ich das deutlich besser verstehe als du,
> nur es macht einfach keinen Sinn diese Optimierung nicht zu machen, da
> sich ausserhalb der Sequenz für die Variable nichts dadurch ändert.

Leider macht dein Posting absoult keinen Sinn. Was genau meinst du zu 
verstehen, und welche Optimierung ist unabdingbar? Dir ist schon klar, 
dass die Oprimierung "trag einfach mal statisch 1764 ein" zwar auf einem 
realen System sinnvoll sein mag, nicht aber wenn man etwas demonstrieren 
will?

Tim T. schrieb:
> Ob du es glaubst oder nicht, ich hab eins gelesen, genauer gesagt waren
> es einige, dazu noch Compilerbau, Rechnerarchitektur usw. Außerdem hab
> ich Assembler und Compiler für eigene CPU Architekturen gebaut und unter
> anderem Clang und GCC auf diese Architekturen portiert. Achja,
> irgendwann hab ich auch mal ein Studium in Elektrotechnik Fachrichtung
> Informationstechnologie (Mischung aus E-Technik und Informatik)
> abgeschlossen, wobei das mittlerweile auch schon ein paar Jahre her ist.

Und trotzdem ist dir nicht klar, warum ein volatile an der Stelle nicht 
zu vereinbaren ist mit

Tim T. schrieb:
> Das traurige ist das der gcc nicht erkennt das er einfach ein
> movsd   xmm0, QWORD PTR [rsp-24]
> mulsd   xmm0, xmm0
>
> [...]
>
> machen könnte und stattdessen zwei Register lädt...

?
Interessant.

Tim T. schrieb:
> Aber um dich nicht zu überfordern stelle ich die Frage mal neu:
>
> "Warum meint der GCC das ermovsd   xmm0, QWORD PTR [rsp-24]
> mulsd   xmm0, QWORD PTR [rsp-24]
> NICHT zwischen zwei Sequenzpunkte bekommt,movsd   xmm0, QWORD PTR
> [rsp-24]
> movsd   xmm1, QWORD PTR [rsp-24]
> mulsd   xmm0, xmm1
> aber schon?"

Interessant, wie du deine "Frage" nun geringfügig abänderst, die Stelle, 
auf die ich mich bezog entfernst, um deinen Fehler zu vertuschen.
Natürlich nur "um mich nicht zu überfordern". Nicht, um durch 
Unflätigkeiten von deinen Fehlern abzulenken.

vn nn schrieb:
> Du hättest auch selbst drauf kommen können, dass ich bei goldbolt nicht
> einfach sagen kann "kompilier halt mit -c".

Was hindert dich denn daran?

Also mir ist es jetzt einfach zu doof weiter darauf einzugehen. Der 
Spezialist will es einfach nicht verstehen und ich hab sinnvolleres zu 
tun als mich mit einem Troll auseinander zusetzen. Für mich ist hier 
demnach EOD.

Dem Rest noch einen schönen Abend.

X² = X * X

S. R. schrieb:
> Tim T. schrieb:
>> Seufz:
>> movsd   xmm0, QWORD PTR [rsp-24]
>> movsd   xmm1, QWORD PTR [rsp-24]
>> mulsd   xmm0, xmm1
>>
>> soll also besser sein als:
>> movsd   xmm0, QWORD PTR [rsp-24]
>> mulsd   xmm0, QWORD PTR [rsp-24]
>
> Nein. Du hast keine Ahnung.

Wenn du das sagst, wird das wohl deine Meinung sein.

> Du erwartest, dass im ersten Fall immer xmm0 == xmm1 gilt.
> Das ist für volatile nicht garantiert, und der Compiler darf sich
> nicht darauf verlassen. Wenn die Adresse nämlich eine MMIO-Adresse
> ist, dann haben Lesevorgänge möglicherweise Nebeneffekte.

Brauch er auch nicht, wenn du einfach mal scharf hinschauen würdest, 
wird im zweiten Fall ebenfalls eine zweiter Lesezugriff auf die Adresse 
durchgeführt, nur werden die Daten nicht überflüssigerweise in einem 
Register zwischengelagert sondern direkt verwurstet.

>> Nope. Sobald du eine 2 Register Operation wie z.B. mul durchführst, geht
>> das gar nicht anders als sich darauf zu verlassen das der Wert
>> zwischenzeitlich nicht verändert wurde.
>
> Du hast keine Ahnung. Der Wert der Variablen kann sich ändern. Wenn da
> 2x "lies X aus dem Speicher" steht, dann muss der Compiler auch 2x X aus
> dem Speicher lesen, und er darf nicht annehmen, dass er 2x das gleiche
> gelesen hat.

Auch das hast du nicht verstanden, du MUSST einen Operanden vorab in ein 
Register laden und dich dann darauf verlassen dass der zweite Operand in 
der Zwischenzeit nicht verändert wurde. Im konkreten Beispiel eben dass 
an der Adresse von x immer noch der Wert 42 drin steht, ansonsten 
könntest du gar keine Multiplikation durchführen. Sowohl im ersten als 
auch im zweiten Codestück ist das der Fall. Was nur hinzukommt ist das 
der Codeabschnitt in eine Sequenz gepackt wird und so sicherstellt das 
allgemein keine Änderungen an den volatilen Variablen vorgenommen wird.

>> Abgesehen davon bekommt Clang das hin...
>
> Betrachte ich erstmal als Bug.

Auch das wird deine Meinung sein.

So, nun ist aber wirklich Schluss für mich, hab nur noch geantwortet 
weil du dir die Mühe gemacht hast eine Antwort zu basteln und dabei so 
kräftig vor die Wand gelaufen bist das ich Mitleid hatte.

Nur mal so aus Neugierde, wer quadriert hier eigentlich auf kleinen 
Mikrocontrollern doubles? Da möchte ich mal ne Anwendung sehen, die das 
braucht außer vielleicht nem Sextanten. Und dann nehm ich halt einen 
potenteren µC und überlasse das Optimieren der Toolchain. Um die paar 
Cents in Serienfertigung kanns wohl kaum gehen?

Tim T. schrieb:
> Brauch er auch nicht, wenn du einfach mal scharf hinschauen würdest,
> wird im zweiten Fall ebenfalls eine zweiter Lesezugriff auf die Adresse
> durchgeführt, nur werden die Daten nicht überflüssigerweise in einem
> Register zwischengelagert sondern direkt verwurstet.

LLVM hat ein Tool womit man die Performancecharakteristik von Kompilaten 
statisch bewerten kann: llvm-mca. Einen krassen Unterschied sehe ich 
zwischen den Versionen damit nicht.

1

{clang|gcc} -O3 test.c -march={Architektur} -S -o - | llvm-mca -mcpu={Architektur}

Wer hat denn jetzt den Längsten hier? +nurmalsogefragt+

Carsten schrieb:
> Um die paar
> Cents in Serienfertigung kanns wohl kaum gehen?

Kein Profi! ;-)

Frank M. schrieb:
> mysquare:                               # @mysquare
>         mulsd   xmm0, xmm0
>         ret
> mypow2:                                 # @mypow2
>         mulsd   xmm0, xmm0
>         ret
>
> gcc und clang liefern hier übrigens dasselbe Ergebnis.
>
> Ich denke, damit ist die Frage hinreichend beantwortet und ein jeder
> kann sich nun wieder wichtigeren Dingen zuwenden.

Danke liebe Leute für eure Hilfe. Btw. es ist keine uC Anwendung, 
sondern ein PC-Linux-C-Programm. Dort muss ich im innersten mehrerer 
verschachtelter Schleifen die Längen von Vektoren berechnen, Umrechnung 
Rechteck in Polarkoordinaten, einmal X,Y und dann noch im 
Farbvektorraum. So dachte ich, das der Gedanke an den Versuch einer 
Optimierung nicht ganz abwegig ist. Liebe Grüße

Icke schrieb:
> X² = X * X

Stimmt auffällig. AAABer:
hier geht es um

(X - Xmittel)².

Wenn ich jetzt dern Herrn Binomi(TM) bemühe ist das aber meines Wissens

(X - Xmittel)² = X² + 2*X*Xmittel - Xmittel²

oder liege ich da falsch?

Klugscheisser schrieb:
> (X - Xmittel)² = X² + 2*X*Xmittel - Xmittel²

Sorry... Vorzeichen falsch ;-)

Jemand schrieb:
> vn nn schrieb:
>> Du hättest auch selbst drauf kommen können, dass ich bei goldbolt nicht
>> einfach sagen kann "kompilier halt mit -c".
>
> Was hindert dich denn daran?

Dass ich ausprobieren wollte, zu was "pow(x, 2)" optimiert wird, und 
nicht, welchen Funktionsumfang godbolt unterstützt. Denn genau das ist 
Thema des Threads. Threadthema ist nämlich weder "was kann godbolt 
alles", noch "ist volatile an der Stelle undefined oder nicht".
Aber faszinierend, wie sich die geballte Foreninkopmpetenz auf ein 
"volatile" in einem Demobeispiel stürzt, weil sie zum eigentlichen Thema 
nix beizutragen hat.

Markus F. schrieb:
> vn nn schrieb:
>> Du hättest auch selbst drauf kommen können, dass ich bei goldbolt nicht
>> einfach sagen kann "kompilier halt mit -c".
>
> dann solltest Du das vielleicht mal probieren (so hättest Du dann
> wenigstens irgendwas dazugelernt).

Natürlich kann ich es. Aber da ich wissen wollte, wie "pow(x, 2)" 
optimiert wird, wollte ich mich halt nicht mit Nebenbaustellen 
beschäftigen.
Klar, du hingegen machst gezielt die Nebenbaustelle auf.

Markus F. schrieb:
> Abgesehen davon hätte ich naiv
> angenommen, daß jemand, der zu einer C-Frage den dicken Max macht,
> vielleicht eventuell tatsächlich einen eigenen Compiler hat?

Falls du es noch nicht gemerkt hast, der Sinn von godbolt an der Stelle 
ist, dass man darauf verlinken kann (wegen der Nachvollziehbarkeit 
wärs).
Aber eh klar, nachdem dich das eigentliche Threadthema nicht 
interessiert, und du nur stänkern willst, interessiert dich natürlich 
auch die Nachvollziehbarkeit von themenspezifischen Postings nicht.

Markus F. schrieb:
> vn nn schrieb:
>> War ja keine Zielplattform gefragt.
>
> Wie heisst das Forum hier gleich noch mal?

Genie. Embedded kann genau so gut x86 sein. Aber hellsichtig wie du 
bist, kannst du bestimmt eine konkrete Zielplattform vorschlagen. AVR? 
PIC? ARM? RISCV?

Tim T. schrieb:
> Also mir ist es jetzt einfach zu doof weiter darauf einzugehen. Der
> Spezialist will es einfach nicht verstehen und ich hab sinnvolleres zu
> tun als mich mit einem Troll auseinander zusetzen. Für mich ist hier
> demnach EOD.

Sehr gut. Dann können endlich wieder themenrelevante Dinge diskutiert 
werden, anstatt deines Unverständnisses was "volatile" so macht.
Bis dahin wundere dich einfach weiter, warum die Variable deswegen 
zweimal gelesen wird.

Tim T. schrieb:
> Brauch er auch nicht, wenn du einfach mal scharf hinschauen würdest,
> wird im zweiten Fall ebenfalls eine zweiter Lesezugriff auf die Adresse
> durchgeführt, nur werden die Daten nicht überflüssigerweise in einem
> Register zwischengelagert sondern direkt verwurstet.

Für den Fall, dass du es noch nicht gemerkt hast: es bezieht sich hier 
jeder auf den ersten von dir gelisteten Fall, den du eleganterweise 
jetzt einfach unter den Tisch fallen lässt.

Markus F. schrieb:
> Mir völlig unklar, wie man sich daran so dermaßen ereifern kann.
>
> [...]
>
> Kindergarten. Echt.

Ich vermute, du meinst mit "Kinergarten" so Aussagen wie "dann solltest 
Du das vielleicht mal probieren (so hättest Du dann
wenigstens irgendwas dazugelernt)"? Oder sowas wie "Wie heisst das Forum 
hier gleich noch mal?", und plötzlich stellt sich raus dass x86-64 doch 
nicht so falsch war?

Es ist immer wieder faszinierend, wie eine simple Programmierfrage einen 
tagelang andauernden Streit vom Zaun brechen kann.