STM32F4 64 Bit Operation Dauer

[Nate (Gast)]

Hallo alle zusammen!

Ich bin gerade dran auf einem STM32F4 board 64 bit operationen 
auszuführen (bitte nicht mit assembler anfangen, ich weiß das man damit 
das Problem lösen kann).

Ich führe eine einfache Addition in einer Schleife aus, hierbei ist zu 
beachten dass erstmal der Fall beachtet wird, bei dem e aus kleinen 
Zahlen besteht! Also wird Poly[j] vorerst (bis auf sonderfälle die hier 
nicht betrachtet werden) nicht größer als 32 bit. Bitte nicht fragen 
wieso 64 bit benutzt wird => wird für den Sonderfall benötigt.

int64_t Poly = {0};
int32_t e = ....; //mit Zahlen gefüllt, pos und negativ

for (uint16_t i = 0; i < PARAM_W; i++)
{
  for (uint16_t j = 0; j < PARAM_N; j++)
  {
    Poly[j] += e[PARAM_N - c[i] + j];
  }


c ist ein Array der Länge PARAM_W.

Wenn ich die Anzahl der benötigten clock cycles für den Schritt
Poly[j] += e[PARAM_N - c[i] + j];
mir ausgeben lasse auf dem STM32F4 board, variiert diese um 5 clock 
cycles!

Hier noch die Compiler Optionen/flags
-Wall -g -std=c99 -O3 mfloat-abi=softfp
Optimazation flag ändern ändert nichts, variiert trotzdem um 5 cc.

Hat jemand eine erklärung wieso das so ist? Warum dauert genau die selbe 
addition länger? Kann es sein, dass es der Fall ist, wenn Poly[j] durch 
die addition eines Wertes sich im Vorzeichen ändert? Woran könnte es 
sonst liegen?

Danke schon einmal für die Hilfe!

Beste Grüße
Nate

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

Nate schrieb:
> variiert diese um 5 clock cycles

Wie gemessen?

[Nate (Gast)]

Ich meine damit, dass ich zwei verschiedene clock cycles bekomme für die 
Operation (164 und 159). langsamer oder schneller ist vom standpunkt 
abhängig ;)

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

Ist die Messung taktgenau per SysTick ohne Teiler, oder spielt da I/O 
mit hinein?

[Nate (Gast)]

Gemessen mit dem Data Watchpoint and Trace (DWT) Unit

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

Nate schrieb:
> Ich meine damit, dass ich zwei verschiedene clock cycles bekomme für die
> Operation (164 und 159).

Für die Schleife oder für die Operation?
Für die einzelne Operation wärs zu viel.

[Nate E. (nate24)]

So sorry, bin der selbe hab mich nur angemeldet.

Nur für die Operation. Messe die clock cycles mit:

*DWT_CYCCNT = 0;
*DWT_CONTROL = *DWT_CONTROL | 1 ;

und lese nach der Operation DWT_CYCCNT aus

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

Für ein paar Loads mit Additionen ist das zu viel.
Da spielt noch mehr mit.

Der Generierte Asm-Code der Schleife mitsamt der DWT Operationen wäre 
sinnvoll.

[Nate E. (nate24)]

Ahh sorry mein Fehler, es bezieht sich nicht auf die Addition. Die Frage 
bezieht sich auf die Modulo Operation danach.

for(uint16_t i = 0; i< PARAM_N; i++)
{
w[i] = Poly[i] % PARAM_Q;
}

Tut mir Leid für den Fehler.
Die Modulo Operation dauert unterschiedlich lange, unabhängig ob es ein 
negativer oder ein positiver Wert ist.

[Sebastian K. (sek)]

Die Modulo Operation verwendet DIV, falls der Compiler dies nicht 
wegoptimiert bekommt. Und der braucht für die Abarbeitung 
unterschiedlich lange, 2-12 Cycles.

[Nate E. (nate24)]

Sebastian K. schrieb:
> Die Modulo Operation verwendet DIV, falls der Compiler dies nicht
> wegoptimiert bekommt. Und der braucht für die Abarbeitung
> unterschiedlich lange, 2-12 Cycles.

Danke! Das erklärt meine Frage :)

[rmu (Gast)]

Nate schrieb:
> Ich meine damit, dass ich zwei verschiedene clock cycles bekomme für die
> Operation (164 und 159). langsamer oder schneller ist vom standpunkt
> abhängig ;)

164 oder 159 zyklen für eine Operation finde ich auch exzessiv, ASM wär 
interessant.

5 Zyklen Unterschied können aber schon möglich sein. Es wird zu einer 
64bit-Zahl eine 32bit-Zahl dazugezählt, die durchgeführten Operationen 
sind auch nur 32bit breit. Kommt es also zu einem "Überlauf" wenn man 
die untersten 32bit addiert, dann muss man den Überlauf in die oberen 
32bit dazurechnen, gibts keinen Überlauf kann das (addieren von 0) 
entfallen.

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

rmu schrieb:
> 164 oder 159 zyklen für eine Operation finde ich auch exzessiv,

Für eine 64-Bit MOD Operation vielleicht nicht.

[Jim M. (turboj)]

rmu schrieb:
> Kommt es also zu einem "Überlauf" wenn man
> die untersten 32bit addiert, dann muss man den Überlauf in die oberen
> 32bit dazurechnen, gibts keinen Überlauf kann das (addieren von 0)
> entfallen.

Und so kommt man dann auf die 5 Takte, denn auch das Laden und Sichern 
der oberen 32 Bits entfallen dann.

Denn:

Lade Register: 2 Takte
Inkrementiere Register: 1 Takt
Speichere Register: 2 Takte
========
Summe: 5 Takte

Und die 3 Instruktionen müssten auch ein einen IT Block passen, und 
Cortex M4 kennt IT Folding.

Fazit: Der Compiler war wieder mal deutlich cleverer als der 
Programmierer...