Multiply-Add Instruktion ist langsam

Das Ergebnis ist genauer, wenn erst abschliessend gerundet wird:
https://de.wikipedia.org/wiki/Fused_multiply-add

Es wird ein Zwischenregister eingespart.

PS: Lies auch die Fussnoten: "Floating-point arithmetic data processing 
instructions, such as add, subtract, multiply, divide, square-root, all 
forms of multiply with accumulate, as well as conversions of all types 
take one cycle longer if their result is consumed by the following 
instruction."
  FMUL
  FADD
  ..use result..
hat 2 Straftakte drin und kommt damit auf 4 Takte, während
  VMLA
  ..use result..
nur einen Straftakt hat und damit gleichauf liegt.

FPUs mit Pipelining könnten mit FMA effizienter umgehen als mit 
getrennten Operationen, und damit schneller sein. Das betrifft den M4F 
nicht, aber der Befehlssatz ist möglicherweise darauf ausgerichtet.

Das klingt schon mal logisch. Besten Dank.

Ich habe die Reihenfolge der Statements in der Schleife jetzt mal 
geändert (siehe unten). Ich dachte ich könnte so einen Strafzyklus 
notwendig machen, weil der vfma Befehl jetzt das Resultat des vadd 
Befehls vor ihm braucht. Aber der Compiler hat geschickterweise die subs 
Instruktion vorgezogen.

1

  int32_t start=micros() ;

2

  for(int k=0 ; k<nn ; k++){ 

3

    fy += 1.2 ;

4

    fz += 1.3 ;

5

    fx += fy * fz ;

6

    }

7

  int32_t stop=micros() ;

8

/*

9

   50e: ee37 7a06   vadd.f32  s14, s14, s12    1 Zyklus

10

   512: ee77 7aa5   vadd.f32  s15, s15, s11    1 Zyklus

11

   516: 3b01        subs  r3, #1               1 Zyklus

12

   518: eee7 6a27   vfma.f32  s13, s14, s15    3 Zyklen

13

   51c: d1f7        bne.n 50e <setup+0x9e>     2 Zyklen

14

*/

Jetzt verstehe ich folgendes nicht: Meine Laufzeitmessung sagt, dass ein 
Schleifendurchlauf 7 Zyklen braucht. Ich komme aber auf 8 Zyklen, wo 
mache ich einen Fehler ?

void schrieb:
> Wilde Vermutung: bne.n hat unterschiedliche Ausführungszeit für branch
> taken und branch not taken

Die hat er mit 2 Takten schon eingerechnet. Aber ohne nun beim M4 
konkret nachgesehen zu haben könnte es sein, dass das Gesamtsystem ihm 
noch einen Takt für nichtsequentiellen Zugriff oder schlecht aligntes 
Sprungziel zusätzlich drauf haut.

Und ich hatte das verkehrt herum gelesen...

Martin O. schrieb:
> Ich komme aber auf 8 Zyklen, wo
> mache ich einen Fehler ?

Bei der Adresse. 0x50E ist nicht auf 4 Bytes ausgerichtet - das gibt 
hier den Staftakt, denn dort steht ein 4 Bytes langer Befehl.

Mach mal ein __NOP(); vor die Schleife..

So hatte ich das auch erst gelesen. Er beschwert sich aber über einen 
Takt zu wenig.

A. K. schrieb:
> So hatte ich das auch erst gelesen. Er beschwert sich aber über einen
> Takt zu wenig.

vielleicht braucht das VMLA doch weniger als 3 Takte und die genannten 
Effekte (alignment,...) traten bei der allerersten Messung auf?

Die Pipeline widmet sich bereits dem Sprungbefehl und dessen Ziel, 
während der VMLA Befehl noch läuft. Das ist zwar spekulativ, aber 
dadurch reduziert sich die Laufzeit der Execute-Stage des Sprungbefehls 
auf einen Takt zur Bestätigung.

https://community.arm.com/developer/ip-products/processors/f/cortex-m-forum/8969/question-about-the-pipeline-clock-cycle-and-machine-cycle-in-cortex-m-series

In anderen Beispielen benötigte die CPU immer 2 Takte für den Sprung. 
Daher zähle ich den Sprung hier auch mit 2 Zyklen.

Das ganze mache ich aus purer Neugirde und um herauszufinden welche 
Konstrukte welchen Aufwand haben.