IAR Compiler: reentrant function

[pumpkin (Gast)]

Moin,

ich bin auf der Suche nach einer Möglichkeit eine Funktion im IAR 
(MSP430) als reentrant zu deklarieren. Die F1-Doku schweigt sich aus, 
Support kann nicht in Anspruch genommen werden - noch ist das Teil nicht 
gekauft (und wird es wohl auch nicht...). Auf die PDFs von IAR habe ich 
gerade keinen Zugang...  :^/

Kann jemand helfen?

Cheers!

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

Ich könnte mir vorstellen, dass dies beim MSP430 immer so ist.

Es gibt ein paar Architekturen, die sich damit schwer tun. PIC 12/14bit 
und 8051 beispielsweise. Die meisten jedoch sind von Haus aus reentrant, 
wie C das auch vorschreibt.

[pumpkin (Gast)]

Mal eine vllt ungeschickte Frage: Was hat das mit der Architektur zutun?

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

Alles.

Hauptsächlich mit der Frage, wie gut man relativ zu einem Adressregister 
den Speicher adressieren kann. Das ist nämlich für lokale Daten und 
Parameter auf dem Stack essentiell.

8051 und 12/14-Bit PICs können das nicht, tun sich mit absoluter 
Adressierung viel leichter. Deshalb wird bei diesen gerne zwischen 
reentrant und non-reentrant unterschieden, der Effizienz zuliebe.

MSP430 hingegen erinnert sehr stark an die PDP-11, für die C 
ursprünglich entwickelt wurde. Was folglich gut zusammen passt.

[Rufus Τ. F. (rufus)]

Ja, der MSP430 hat eine wunderbar orthogonale Architektur. Kommt 
übrigens aus Bayern.

[T. H. (pumpkin)]

Der Groschen ist gefallen. Wiedermal zu kompliziert gedacht. Danke!

Cheers!

[Peter D. (peda)]

Man muß bedenken, daß der Ur-8051 nur 128 Byte SRAM und 4kB EPROM hatte.
Und bei so wenig SRAM manchen reentrante Funktionen eh keinen Sinn, sie 
brauchen immer reichlich Stack. Reentrante Funktionen sind das Gegenteil 
von Effizienz.

Da hat man sich für die Overlay-Technik entschieden, was auch dem 
Codeverbrauch deutlich zugute kommt, da die Funktinen keinen Stackframe 
aufbauen müssen.

Dadurch ergab sich auch das Kuriosum, daß der Codeverbrauch oft kleiner 
wurde, nachdem ich Programme von Assembler auf C umgeschrieben hatte.


Peter

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

Peter Dannegger schrieb:

> Reentrante Funktionen sind das Gegenteil von Effizienz.

Bei 8051 zweifellos. Und meistens ist das auch nicht erforderlich. Nur 
ist C eben für eine Maschinenklasse entworfen worden auf die diese 
Aussage nicht zutrifft, Bei Architekturen wie MSP430 ist die Verwendung 
eines Stacks deutlich effizienter als absolute Adressierung, erst recht 
gilt das für ARM&Co. Ein Stack ist ja letztlich auch nichts anderes als 
eine Overlay-Technik, nur automatisiert und ohne komplexe Analyse.

[Peter D. (peda)]

A. K. schrieb:
> Peter Dannegger schrieb:
>
>> Reentrante Funktionen sind das Gegenteil von Effizienz.
>
> Bei 8051 zweifellos. Und meistens ist das auch nicht erforderlich. Nur
> ist C eben für eine Maschinenklasse entworfen worden auf die diese
> Aussage nicht zutrifft

Ich meinte rekursive Funktionen und die sind auf jeder Maschine 
ineffizient. CALL und RET sind überall sehr teure Instruktionen.


Peter

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

Peter Dannegger schrieb:

> Ich meinte rekursive Funktionen und die sind auf jeder Maschine
> ineffizient.

Ja, aber das ist etwas anderes.

Es geht es dabei meist nicht um Rekursion, sondern um die Möglichkeit, 
Funktionen auch aus Interrupt-Handlern aufrufen zu können (nix Grosses, 
kommt aber schon mal vor), und vor allem um die Verwendung durch mehrere 
Prozesse/Threads im Rahmen eines RTOS.

Wobei ein RTOS natürlich nicht zum typischen Einsatzprofil von 8051/PIC 
zählt, deshalb stört das da weniger.

> CALL und RET sind überall sehr teure Instruktionen.

Beim RISC-typischen Aufrufverfahren von ARM sind diese Befehle nicht 
teurer als gewöhnliche Sprungbefehle. Tendentiell teuer ist eher der 
Gesamtaufwand des Funktionsaufrufs, mit Prolog/Epilog.