GCC Wie ist das mit reentrantem Code?

[Christian J. (Gast)]

Hallo,

ich nutze eine Berechnungsroutine sowohl im Hauptprogramm als auf in 
einem Interrupt des Timers. Wäre halt blöde, wenn ich die zweimal gleich 
schreiben müsste.

Versteht der gcc das und trifft Maßnahmen? Oder muss ich da was 
beachten?

Gruss,
Christian

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

Kein Problem. Zugriffe auf externe/statische Variablen müssen allerdings 
atomar erfolgen.

[Peter II (Gast)]

Christian J. schrieb:
> Versteht der gcc das und trifft Maßnahmen? Oder muss ich da was
> beachten?

was soll er den für Maßnahmen beachten? Das ist doch etwas normales.

Aber du solltest beachten, das ein Funktionsaufruf in der ISR dafür 
sorgt, dann alle Register gesichert werden müssen, das macht das ganze 
etwas langsamer (ob es stört musst du wissen)

[Christian J. (Gast)]

Peter II schrieb:
> Aber du solltest beachten, das ein Funktionsaufruf in der ISR dafür
> sorgt, dann alle Register gesichert werden müssen, das macht das ganze
> etwas langsamer (ob es stört musst du wissen)

Na, ich erwarte doch, dass er den Stackframe richtig bedient. Notfalls 
kann ich bei Aufrufen aus dem Main ja noch __disable_IRQ() eingeben. 
Die Routine benutzt keine externen Daten, nur lokale und die Parameter 
der Funktion.

[Peter II (Gast)]

Christian J. schrieb:
> Na, ich erwarte doch, dass er den Stackframe richtig bedient.

es werden aber mehr Register gesichert als notwendig sind.

[Christian J. (Gast)]

Peter II schrieb:
> es werden aber mehr Register gesichert als notwendig sind.

Macht nix, bei einem 180 Mhz Motor des Cortex M4 stört mich das nicht.

[Peter II (Gast)]

Christian J. schrieb:
> Macht nix, bei einem 180 Mhz Motor des Cortex M4 stört mich das nicht.

dann ist ja gut

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

Peter II schrieb:
> Aber du solltest beachten, das ein Funktionsaufruf in der ISR dafür
> sorgt, dann alle Register gesichert werden müssen, das macht das ganze
> etwas langsamer (ob es stört musst du wissen)

Das betrifft nur die Scratch-Register, also jene, die von einer 
aufgerufenen Funktion verändert werden dürfen. Bei AVRs sind das recht 
viele, daher fällt das bei denen auf.

Wenn es sich allerdings um einen Cortex M handelt, dann werden diese 
Register sowieso schon vollständig als Teil des Interrupt-Verfahrens von 
der Hardware gesichert. Bei den Cortex M ergibt sich also durch 
Funktionsaufrufe innerhalb einer ISR keinerlei Nachteil.

Hintergrund: Bei den Cortex M sind ISRs normale Funktionen mit normalem 
ABI, keine speziellen Exception-Handler. Folglich sichern sie weder 
Scratch- noch Status-Register. Das geschieht automatisch als Teil des 
Interrupt-Ablaufs des Cores. Es gibt daher auch keinen "Return from 
Interrupt" Befehl, sondern eine spezielle Return-Adresse signalisiert 
einen anderen Ablauf.

Da diese 5 Store-Operationen parallel zum Vektor- und Code-Zugriff auf 
das Flash-ROM erfolgen, hat das in der üblichen Konfiguration auch kaum 
Folgen für die Interrupt-Latenz. Zudem entfallen sie, wenn ein 
Return-From-Interrupt gleich in den nächsten Handler springt.

[Johann L. (gjlayde)]

A. K. schrieb:
> Kein Problem. Zugriffe auf externe/statische Variablen müssen allerdings
> atomar erfolgen.

Atomarer Zugriff ist notwendig für reentrant Code, aber nicht 
hinreichend.

[Eric B. (beric)]

Christian J. schrieb:
> Die Routine benutzt keine externen Daten, nur lokale und die Parameter
> der Funktion.

Wenn die lokale Daten nicht 'static' sind, ist alles i.O.