Sprungtiefe verringern

Nobbie Gast 28.03.2011 08:33 #2121796

Lesenswert?

•

Hi,

Ich weiß nicht, ob ich im richtigen Unterforum gepostet habe. Falls 
nicht, bitte entsprechend verschieben.

Jetzt zu meinem Anliegen. Ich habe aktuell ein komplexeres 
Firmware-Projekt, in dem ich einen Hardware-Abstraction-Layer 
implementiert habe. Dieser dient zum softwareseitigen Verknüpfen der 
einzelnen Module.
Der Code sieht, wie nachfolgend dargestellt, aus:

/*----------------------------------------------*/
/* modul_1.c
uint16_t func1(uint16_t param1, uint16_t param2)
uint16_t func2(uint16_t param1, uint16_t param2)
/*----------------------------------------------*/
/*----------------------------------------------*/
/* Abslayer.c
uint16_t layer_func1(uint16_t param1, uint16_t param2)
   return func1(param1, param2);
uint16_t layer_func2(uint16_t param1, uint16_t param2)
   return func2(param1, param2);
/*----------------------------------------------*/


Wie man erkennt, wird im Abstraktionslayer nur die eigentliche Funktion 
aus dem Hardwaremodul aufgerufen. Dies hat aber zur Folge, dass sich 
dadurch die Sprungtiefe erhöht und somit die Stackbelastung steigt.

Meine Frage ist, kann man dies "eleganter" lösen und somit die 
Sprungtiefe reduzieren? Die Hardwareabstraktionschicht möchte ich aber 
belassen.

Danke Nobbie

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Jan S. (jan_s) 28.03.2011 08:41 #2121799

Lesenswert?

•

▲
▼

Indem Du dir den überflüssigen Funktionsaufruf einfach sparst und das 
Ganze zur Compile-Zeit mit Macros löst.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Mike R. (thesealion) 28.03.2011 08:42 #2121800

Lesenswert?

•

▲
▼

Spontan würden mir da #define oder inline funktionen einfallen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Lothar M. (lkmiller) Moderator (Firma: Titel) 28.03.2011 08:56 #2121808

Lesenswert?

•

▲
▼

Nobbie schrieb:
> Die Hardwareabstraktionschicht möchte ich aber belassen.
Das ist das, was dein Nachfolger 10 Jahre später verfluchen und 
herausbasteln wird. Garantiert...
Und: du wirst dein Programm trotzdem nicht so abstrakt hinbekommen, dass 
du alle Hardwarebezüge gekapselt bekommst...

BTW:
> Ich habe aktuell ein komplexeres Firmware-Projekt, in dem ich einen
> Hardware-Abstraction-Layer implementiert habe.
Es kann nicht komplex sein, wenn du einen so kleinen Prozessor 
verwenden mußt, dass der Stack keinen Platz hat  ;-)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Purzel H. (hacky) 28.03.2011 09:00 #2121812

Lesenswert?

•

▲
▼

>... Hardwareabstraktionschicht ...

Ist ein Furz fuer Betriebssytemschreiber, die beliebig Rechenleistung 
und Resourcen haben. Bei Controllern gilt eher :
So komplex wie noetig, so einfach wie moeglich.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Nobbie Gast 28.03.2011 09:16 #2121825

Lesenswert?

•

▲
▼

Hi,

genau das sind die Sprüche, die ich von Kollegen auch höre und dann 
schaue ich manchmal in deren Code und schlage die Hände über den Kopf 
zusammen (Übrigens sind das auch die, die dann zur Fehlersuche Hilfe 
benötigen und von Dingen wie atomare Zugriffe, usw... höchstens mal was 
gehört haben).
Ich möchte und werde hier jetzt aber keine Grundsatzdiskussion über die 
Sinnhaftigkeit meiner Struktur durchführen.

Nur soviel, durch die Abstraktionsschicht kann und konnte ich sehr 
einfach Softwaremodule austauschen (z.T. auch durch Softwaretestmodule).

@Lothar:
naja, komplex ist relativ, da gebe ich dir Recht ;-). Aber für meine 
Verhältnisse ist dieses Projekt schon komplexer (manch anderer würde 
sicherlich drüber lachen)

@Jan und Mike:
inline wird meines Wissens nach nicht von allen C-Compiler unterstützt 
(kommt eigentlich von C++, C99-Standard)
mit dem #define funktioniert das super.

Danke an alle
Nobbie

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Oliver Gast 28.03.2011 10:03 #2121869

Lesenswert?

•

▲
▼

A. K. schrieb im Beitrag #2121831:
> Die Chancen stehe nicht schlecht, dass der Compiler aus dem
> Unterprogrammaufruf einen schlichten Sprungbefehl macht.

Wenn die Funktionen, wie oben gezeigt, über drei Sourcedateien verteilt 
sind, hat der Compiler keine Chance.


Plan B wären Funktionspointer:

uint16_t (*layer_func1)(uint16_t, uint16_t)= func1;


Das geht aber nur, wenn die Parameter bei Layer- und Modulfunktion 
identisch sind.

Oliver

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Sprungtiefe verringern

Antwort schreiben