ARM-Assembler: Takte zählen

[Walter T. (nicolas)]

Hallo zusammen,

ich mache mich in meinen ersten Gehversuche mit Assembler. Ich habe eine 
kleine ISR geschrieben und wundere mich, wie sich die Ausfuehrungsdauer 
unterscheidet.

Die Funktion sieht so aus:

.syntax unified
.cpu cortex-m3
.thumb

#include "hw_config.h"
#include "io_pins.h"
.include "../../src_library/src_asm/stm32f4xx.inc"
.include "../../src_library/src_asm/stm32f4xx_gpio.inc"
.include "../../src_library/src_asm/stm32f4xx_tim.inc"

@ Zyklenzaehler fuer Profiling
DWT_CYCCNT = 0xE0001004

.align 4
.bss
.global DdaState
DdaState:
akku:
    .space 4
cnt:
    .space 4
v:
    .space 4

.data
min:
    .word 0xFFFFFFFF
max:
    .word 0

.align 4
.text
.type TIM6_DAC_IRQHandler, %function
.global TIM6_DAC_IRQHandler
TIM6_DAC_IRQHandler:

    @ Profiling 1
    push { r4-r5 }
2    ldr r4, =DWT_CYCCNT
2    ldr r5, [r4]


    @ IT pending Bit loeschen TIMx->SR = (uint16_t)~TIM_IT;
2    ldr r0, =TIM6_BASE
2    ldr r1, =~TIM_IT_Update
2    str r1, [r0, #TIMx_SR]

    @ DDA: akku inkrementieren, rueckschreiben, Ueberlauf pruefen
2    ldr r0, =DdaState
2    ldr r1, [r0, #(akku-DdaState)]
2    ldr r2, [r0, #(v-DdaState)]

1    adds r1, r1, r2
2    str r1, [r0, #(akku-DdaState)]      @ Neuen Akku speichern
1+P  bcc 1f                              @ Kein Overflow -> Ende

    @ Zaehler-Update (re-use r2)
2    ldr r2, [r0, #(cnt-DdaState)]
1    add r2, #1
2    str r2, [r0, #(cnt-DdaState)]

    @ GPIO-Pin wackeln
2    ldr r1, =GPIO_PORT( PULSEGEN_PULSE0_PIN )  @ GPIOA
2    ldrh r3, =GPIO_PIN( PULSEGEN_PULSE0_PIN )  @ 1<<10

1    tst r2, #0x1
?    ite eq
2    strheq r3, [r1, #GPIOx_BSRRL]
2    strhne r3, [r1, #GPIOx_BSRRH]

1:
    @ Profiling 2
2   ldr r4, [r4]
    sub r4, r5 @ Ueberlauf richtig?
    ldr r0, =min
    ldr r1, [r0]
    cmp r1, r4
    it hs
    movhs r1, r4
    str r1, [r0]

    ldr r0, =max
    ldr r1, [r0]
    cmp r1, r4
    it ls
    movls r1, r4
    str r1, [r0]
    pop { r4-r5 }

    bx lr
    .ltorg

Man sieht: Die Funktion ist extrem kurz und ist eine Timer-ISR. Jetzt 
der merkwürdige Teil: Ist der Wert "v" = 0, variiert die Ausführungszeit 
(der Wert in "min" und "max") schon um 17...22 Takte. Das finde ich 
schon sehr merkwürdig, weil in diesem Fall nichts bedingt ausgeführt 
wird.

Sobald "v" größer als Null ist, wird die Bandbreite noch größer mit 
einem Maximum von 36 Takten.

Ich habe mal versucht, die Takte zu zählen (wie in 
https://developer.arm.com/documentation/ddi0439/b/CHDDIGAC ). Ich komme 
auf 12+P Takte. Also 5 bis 10 Takte für den Pipeline-Refill nach dem 
Branch? (In der Doku steht "3-stage-Pipeline", also hätte ich mit 3 oder 
4 Takten gerechnet.)

14 Takte innerhalb [bcc 1f...1:] scheint ja zu passen (wobei da der 
Pipeline-Flush fehlt).

Kurzum: Wo verzähle ich mich?

[Irgend W. (Firma: egal) (irgendwer)]

Du hast glaube ich vergessen des der Einsprung und der Aussprung auch 
etliche Tackte benötigt.

https://interrupt.memfault.com/blog/arm-cortex-m-exceptions-and-nvic#tail-chaining

Dazu kommt noch der Zeitpunkt wo das Interrupt auftritt und was die CPU 
gerade macht und wann sie beschließt auf dem Interrupt zu reagieren usw.

Meistens ist das mit dem Tackte zählen bei den derzeit gängigen 
Prozessoren nicht mehr wirklich in allen Fällen sauber möglich.
Da kommen einfach zu viele Faktoren mit rein die man gar nicht mehr 
Tackt genau berechnen kann.
- Die Piplines und wenn welche Stufe davon gültig bleiben oder nicht
- Die Caches was diese beinhalten bzw. wann das Ding meint diese seinen 
ungültig
- Zugriff auf den Speicher mit Wartezyklen (die aber teilweise durch 
abwechselnden Zugriff auf zwei bänke kaschiert werden) und auch 
Wartezeiten, weil gerade irgend ein anderer Hardwareteil den Bus belegt 
usw.
- und noch einiges mehr...

[Walter T. (nicolas)]

Irgend W. schrieb:
> Du hast glaube ich vergessen des der Einsprung und der Aussprung auch
> etliche Tackte benötigt.

Der Teil ist ja alles außerhalb dessen was im Profiling berücksicht 
wird. Leider wird es auch wohl mit meinem Werkzeug nicht möglich sein, 
ein- und Aussprung aus ISRs zu berücksichtigen.

Berücksichtigt ist ja nur der Bereich zwischen den Zeilen 40 und 72, 
wobei der Bereich der Zeilen 56 bis 69 nicht durchlaufen wird. Und da 
finde ich nichts, was eine unterschiedliche Anzahl an Prozessorzyklen 
verbrauchen könnte.

[foobar (Gast)]

Bei diesen CPUs bringt Taktzählen nicht mehr viel.  Jenachdem in welchem 
Speicher das Programm liegt (CCM, RAM, Flash), variiert die Laufzeit. 
Wenn Zugriffe (auch I/O-Zugriffe) dann noch über die Busmatrix gehen 
oder gar auf asynchronen Bussen (z.B. APB) landen, kannst du gleich 
Würfeln ...