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
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?
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
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 :)
hi! da hast du (ohne Dich damit diskriminieren zu wollen ;-) recht. deshalb frag ich auch, ob irgendjemand literatur zu diesem thema kennt. mfg bernd
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
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.
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.
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
> Frage: woher bekomme ich den Unix V7 code? Guck mal bei der Unix Heritage Society: http://www.tuhs.org/
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
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
> 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.
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.