Malloc und Free emulieren

Michael schrieb:
> ich möchte die Funktionen malloc und free emulieren.

Michael schrieb:
> im Grunde möchte ich

Michael schrieb:
> mir den Code zur Verfügung stellen

:-)

Wenn du besser sein willst als der Compilerbauer...
So ein selbstgebasteltes malloc/free richtet man am speziellen 
Anwendungsfall aus.

Michael schrieb:
> Hallo zusammen,
>
> ich möchte die Funktionen malloc und free emulieren.

Aus welchem Grund? Gibt es für deine Zielarchitektur keins?

> Also im Grunde möchte ich einen fest Speicherbereich reservieren und auf
> diesem Speicherbereich sollen dann die Funktionen userMalloc(...) und
> userFree(...) arbeiten.

Also eben genau das, was malloc/free macht. Implementationen davon 
findet man mit ein wenig Googelei. Es gibt aber unterschiedliche 
Implementationen, je nach Anforderung an Speicherverbrauch und 
Performance.

Michael schrieb:
> ich möchte die Funktionen malloc und free emulieren.

Was stört Dich denn an den Compilerfunktionen?

Bzw. um welchen Compiler, welches Target geht es überhaupt?

Michael schrieb:

> ich möchte die Funktionen malloc und free emulieren.

Nein, möchtest du nicht.

> Also im Grunde
> möchte ich einen fest Speicherbereich reservieren und auf diesem
> Speicherbereich sollen dann die Funktionen userMalloc(...) und
> userFree(...) arbeiten.

Du willst also eine eigene malloc() Implementierung.

Da würde sich als erstes die Frage stellen: warum? Paßt dir was an der 
(den) vorhandenen nicht? Oder geht es um den Lerneffekt? NIH?

Es gibt außerhalb des embedded Bereichs jede Menge malloc() 
Implementationen mit verschiedenen, teilweise widersprüchlichen 
Zielstellungen.

- Speichereffizienz (wenig Overhead)
- Laufzeiteffizienz (*alloc in O(1))
- fragmentierungsfrei (oder zumindest ~arm)
- threadfreundlich
- mit eingebautem Validator

siehe z.B. http://en.wikipedia.org/wiki/C_dynamic_memory_allocation

Außerhalb der embedded-Welt ist der Allocator meist in einer dynamisch 
geladenen Bibliothek und kann dann z.B. durch einen Preload-Mechanismus 
ausgetauscht werden ohne das Programm anfassen zu müssen.

Im embedded Bereich sind malloc() & Co eher ungern gesehene Gäste. Zum 
einen läuft da typischerweise nur eine einzige Applikation, so daß man 
den Speicher auch gleich statisch allozieren kann. Das ist dann nicht 
nur schnell(er) sondern auch automatisch frei von Laufzeitfehlern.

Außerdem läuft embedded Kram meist sehr lange ohne Restart, so daß 
Fragmentation ein echtes Problem darstellt.

Zusammenfassend würde ich sagen, daß die Entwicklung eines eigenen 
Speicherallokators ganz allgemein schon eine anspruchsvolle Aufgabe ist 
und für embedded Software nochmal einen Zacken schärfer. Angesichts der 
erschlagenden Fülle an existierenden Implementierungen bräuchte man auch 
wirklich einen exotischen Sonderwunsch, um eine weitere, eigene 
Implementierung zu rechtfertigen.


XL