www.mikrocontroller.net

Forum: Compiler & IDEs IAR Compiler: reentrant function


Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal eine vllt ungeschickte Frage: Was hat das mit der Architektur zutun?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, der MSP430 hat eine wunderbar orthogonale Architektur. Kommt 
übrigens aus Bayern.

Autor: T. H. (pumpkin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Groschen ist gefallen. Wiedermal zu kompliziert gedacht. Danke!

Cheers!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.