www.mikrocontroller.net

Forum: Compiler & IDEs malloc eigenständig implemetieren


Autor: Bauer Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi!

ich weiss, dass bei der avr-libc ein malloc dabei ist, aber ich weiss
auch, dass das nicht ganz das gelbe vom ei ist.

jetzt hab ich mir überlegt, malloc und free eigenständig zu
implementieren.

meine frage: weiss da jemand wie ich das am besten mach oder gibts da
was gutes im inet (tutorial oder so...)

mfg bernd

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann sieh' Dir doch einfach mal den Quelltext der
Standardimplementierung an, die in der avr-libc enthalten ist, und
entdecke die Stellen, an der die nicht das "gelbe vom Ei" ist.

Was überhaupt soll das bedeuten, daß das "nicht das gelbe vom ei
ist"?
Ist's Dir zu langsam, stört Dich die inherente Speicherfragmentierung
bei häufigem malloc/free mit variierenden Blockgrößen oder wo siehst Du
das Problem?

Autor: Bauer Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi!

nein... ich glaube ich hab mich ein bißchen falsch ausgerückt....

ich hab von jemandem "gehört", dass malloc nicht so astrein
implementiert ist.

ich habe eigentlich gepostet, dass jemand die "vorwürfe" dementiert,
oder eben jemand weiss wie mans besser machen kann.

mfg bernd

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, malloc ist so gut wie nie "sehr gut" implementiert.
Es ist halt immer angemessen implementiert.
Ich glaube aber kaum, daß Du es schaffen wirst, das besser zu machen,
als Jörg Wunsch das derzeit in der avr-libc gemacht hat. Dazu fehlt Dir
(was ich aus Deinen Beiträgen ableite, ohne Dich damit diskriminieren zu
wollen ;) offensichtlich schon das nötige Grundwissen.

Wenn Du das dennoch auf Dich nehmen möchtest: viel Vergnügen :)

Autor: Bauer Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi!

da hast du (ohne Dich damit diskriminieren zu
wollen ;-) recht.

deshalb frag ich auch, ob irgendjemand literatur zu diesem thema
kennt.

mfg bernd

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist nicht das Problem, daß malloc() schlecht implementiert ist,
sondern daß malloc in MC-Anwendungen in der Regel fehl am Platze ist.

Eine MC-Anwendung muß nämlich alle Aufgaben erfüllen, die ihr
einprogrammiert wurden !!!

Und dazu ist es notwendig, daß man den gesamten Speicherbedarf bereits
bei der Softwareentwicklung überprüft.
Und dazu ist es notwendig den maximalen Speicherbedarf jeder Funktion
zu kennen.
Und deshalb kann man ihn am besten doch gleich fest reservieren, d.h.
man braucht gar kein malloc().

Du würdest bestimmt ganz schön dumm aus der Wäsche gucken, wenn Du von
Deinem Fernseher die FB drückst und statt den Kanal zu wechseln oder
sonstwas zu machen erscheint nur ne Ausschrift "Out of Memory".

Ein MC ist nun mal kein PC, wo man andere Anwendungen schließen oder
auf Festplatte auslagern kann, wenns eng mit dem Speicher wird.


Peter

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, am malloc() gibt's durchaus Dinge zu verbessern, siehe die
Beiträge von Bertolt Mildner in der avr-libc-Mailingliste.

Ansonsten beherzige Patricks Rat und schau Dir einfach malloc()-
Implementierungen an.  Nimm Dir die aus der avr-libc als Anfang, schau
Dir insbesondere Implementierungen auf vergleichbaren Maschinen an.
Dazu gehörigen heutige moderne CPUs mit ihren vielen Gigabyte an
virtual memory space allerdings nicht mehr, also mit einer
Implementierung aus Linux (GLIBC) oder 4.4BSD oder gar aktuellen BSDs
wirst Du nicht sehr froh werden.  Die haben ganz andere
Voraussetzungen.  Eher vergleichbar dürften die Ur-Implementierungen
aus der Anfangszeit von C sein, wie sie in den ersten Unixen zum
Einsatz kamen.  Da der Unix-Quellcode bis V7 UNIX (genauer bis 32V
UNIX) öffentlich im Netz verfügbar ist, hast Du da genügend
Vergleiche.

Außerdem: eigentlich musst Du ,,nur'' wissen, was ein malloc() genau
als Aufgabe hat.  Was anderes hatte ich eigentlich auch nicht als
Voraussetzung. ;-) OK, ich hatte eine bereits vorhandene malloc()-
Implementierung für den AVR als Voraussetzung, die aber meines
Erachtens eben wirklich ,,nicht das Gelbe vom Ei'' war, weil sie
insbesondere zu Speicherfragmentierung geneigt hat, sobald man Objekte
unterschiedlicher Größe allozieren und freigeben wollte.  Aus dieser
Implementierung übernommen habe ich letztlich (vom Prinzip her) den
Test auf steack-heap-collision.  Falls Dir letzteres ein Fremdwort
ist, das solltest Du allerdings wirklich verstehen, bevor Du ernsthaft
was implementierst.  Ich hab's einigermaßen in der Doku der avr-libc
beschrieben.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte seinerzeit 'malloc()' vom GNU-CC auf meine H8 CPU angepaßt.
Vielleicht ist die Version nicht das Optimum, wenn man voll
'dynamisch' programmiert. Aber es bringt schon große Vorteile,
dynamische Speicherbereiche verwenden zu können, als alles statisch dem
Compiler zu überlassen.
Auch bei einem Mega128 kann dies mit ext. RAM Sinn machen, wenn der
Speicher mal zur Erfassung und dann zur Verarbeitung benötigt wird.

Ich hatte damals eine Videoanwendung, bei der die überblendeten
Bildbereiche dynamisch gerettet und restauriert wurden; die Fenster
waren unterschiedlich groß und der freie Speicher hätte dabei nicht
gereicht.

Autor: Bauer Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi!

An Jörg Wunsch:

Frage: woher bekomme ich den Unix V7 code? hab ein bißchen gegoogelt
(ja das wort steht jetzt sogar im duden ;-) und hab aber nichts
interessantes gefunden.

hast du da einen link?

mfg bernd

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Frage: woher bekomme ich den Unix V7 code?

Guck mal bei der Unix Heritage Society:

http://www.tuhs.org/

Autor: Gerd Kautzmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unix V7 ... bloß nicht damals galt UNIX als untauglich weil man es
aufgrund der Speicherfragmentierung alle paar Monate rebooten musste.

Malloc ist halt nicht Trivial, der Speicher der angefordert wird muss
irgendwann wieder freigegeben werden Resultat: Speicherfragmentierung.

Erfahrenen Programmierer haben früher per Malloc erst mal einen
bestimmten Speicherbereich angefordert und ihn dann teilweise selbst
verwaltet.

Wenn du Speicher nicht mehr freigeben möchtest wird malloc sehr einfach
... dank mal darüber nach.

cu Gerd

Autor: Bauer Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi!

die einfachsten lösungen sind immer noch am besten.

hab ne einfache implementierung gefunden in der "c bibel".

im Kernighan Ritchie ist eine einfache implementierung von malloc
drinnen.

mfg bernd

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Unix V7 ... bloß nicht damals galt UNIX als untauglich weil man es
> aufgrund der Speicherfragmentierung alle paar Monate rebooten
> musste.

Das lag aber sicher nicht an malloc(), dieweil dieses ja auf
Prozessebene benutzt wird, nicht auf Systemebene.  Es lag wohl einfach
daran, dass es auf Systemebenen keinen Mechanismus wie memory paging
heutzutage gab, sodass man für jeden neuen Prozess auch
zusammenhängend Speicher benötigt hat.  Das rührt natürlich dann schon
wieder an Peters Argumente: wenn man malloc() benutzt, muss man sehr
genau wissen, was man tut.  Je nach Applikation kann natürlich auch
ein (gezielter) Reboot durchaus im Rahmen des Sinnvollen sein, den
kann man ja mit einem Watchdog-Reset implementieren (oder mit einem
externen Reset über einen Portpin).

Die K&R-Implementierung ist gar nicht so uninteressant.  Hätte ich mir
vielleicht damals wirklich mal ansehen sollen, aber das war mir
gedanklich schon lange weggerutscht, dass da eine Beispiel-
implementierung drin ist (wobei sich die Copyright-Frage stellt, wenn
man das in der avr-libc weiterverwenden möchte).

Paar Anmerkungen nur dazu:

. morecore() sollte auf dem AVR keine großen Blöcke allozieren,
sondern
  wirklich nur das, was gerade gebraucht wird.  Anders als sbrk()
unter
  Unix ist die Allozierung auf dem Heap für uns nicht teuer, wohl aber
  der (ggf. unnötig) allozierte RAM selbst.

. Da wir an die 64 KB RAM herankommen können wollen (was auf V7 UNIX
oder
  im K&R so kein Thema ist), muss man besondere Sorgfalt bei den
  Zeigervergleichen walten lassen, wenn man an das obere RAM-Ende
  gelangt.  Hier hatte meine ursprüngliche Implementierung einen Bug.

Autor: Andreas Auer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi.

Hab jetzt auch mit Interesse diesen Thread mitgelesen. (Übrigens war
ich derjenige, der behauptet hat "Malloc sei nicht das Wahre auf AVR
Basis". Natürlich ist mir auch klar, dass es ohne MMU und dergleichen
auf dem Mikrocontroller sehr schwierig ist ein vernünftiges dynamisches
Speichermanagment mit malloc zu realisieren!

@Jörg Wunsch
Ich glaub, als ich malloc mit dem AVR verwendet habe, gab es deine
Implementation noch nicht (ist schon etwas mehr als 1 Jahre her). Ich
hab mir damals auch mal angesehen wie malloc implementiert war. Und da
gabs eben Kommentare, dass dieser und jener Block gebraucht wird, aber
dass es nicht weiter interessant sei, da er sowieso nichts macht (oder
so ähnlich). Alles in allem war mir das dann etwas suspekt. Deshalb
auch meine Behauptung was malloc betrifft.

mfg
Andreas

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, die vorherige Implementierung dürfte inzwischen schon etwas
älter sein. ;-)  Als das derzeitige CVS aus Marek Michalkiewicz'
privaten Quellen im Juni 2002 aufgebaut worden ist, war meine
Implementierung schon dabei (aber wahrscheinlich gerade mal so).

In der Tat, die davorliegende Implementierung war wirklich nicht das
Wahre.  Allerdings habe ich schon erwogen, sie als Option in die
avr-libc zu importieren.  Man müsste nur, um sauber zu sein, den
damaligen Autor nochmal ausfindig machen.  Sie hatte einen Vorteil
gegenüber der derzeitigen: wenn man wirklich nur Blöcke gleicher Größe
angefordert hat, kam sie mit weit weniger ROM aus als meine Variante.

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.