[avr-gcc] przydzial pamieci
Masz problem? Zapytaj na forum elektroda.pl
From: "jfk" <jotefka_at_nospam_poczta.fm>
Subject: [avr-gcc] przydzial pamieci
Date: Mon, 12 Jul 2004 12:22:03 +0200
Witam wszystkich
Pisze duzy programik na mega128 z zewn ram 32k.
bo potrzebuje duzo roznych buforow.
Czy Waszym zdaniem moge korzystac z malloc() i free()?
uklad bedzie odbieral po rs485 i po spi ramki roznej dlugosci ( od 32 do
prawie 250 bajtow) i sklejał w jeszcze wieksze czasami.
Jakie jest ryzyko że ram sie zdefragmentuje? Albo jak temu zapobiec?
Czy pozostawienie zawsze np 25% wolnego ramu moze pomóc?
Ktos ma doswiadczenia z dynamiczna pamiecia?
Z gory dzieki za wszelkie porady.
jfk
========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!newsfeed.pionier.net.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: [avr-gcc] przydzial pamieci
Date: Mon, 12 Jul 2004 18:04:05 +0200
Jakie jest ryzyko że ram sie zdefragmentuje? Albo jak temu zapobiec?
Czy pozostawienie zawsze np 25% wolnego ramu moze pomóc?
Czesc, zobacz m.in.
http://www.avrfreaks.net/phpBB2/viewtopic.php?t=21455
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: [avr-gcc] przydzial pamieci
Date: Tue, 13 Jul 2004 00:59:40 +0200
On Mon, 12 Jul 2004 12:22:03 +0200, jfk wrote:
Pisze duzy programik na mega128 z zewn ram 32k.
bo potrzebuje duzo roznych buforow.
Czy Waszym zdaniem moge korzystac z malloc() i free()?
uklad bedzie odbieral po rs485 i po spi ramki roznej dlugosci ( od 32 do
prawie 250 bajtow) i sklejał w jeszcze wieksze czasami.
Jakie jest ryzyko że ram sie zdefragmentuje?
Spore.
Czy pozostawienie zawsze np 25% wolnego ramu moze pomóc?
Nie.
Albo jak temu zapobiec?
Nie stosowac dynamizmu.
transmisje ? To moze bufory kolowe - tzn jeden obszar wykorzystywany
w kolko pod bufory - bo o ile rozumiem dane sie dosc szybko
dezaktualizuja ..
J.
========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai
From: "jfk" <jotefka_at_nospam_poczta.fm>
Subject: Re: [avr-gcc] przydzial pamieci
Date: Tue, 13 Jul 2004 07:56:05 +0200
Albo jak temu zapobiec?
Nie stosowac dynamizmu.
transmisje ? To moze bufory kolowe - tzn jeden obszar wykorzystywany
w kolko pod bufory - bo o ile rozumiem dane sie dosc szybko
dezaktualizuja ..
Bufor kołowy jest zbyt prosty - to nie moze byc zadne fifo lifo itp. bo
zwalnianie moze byc w roznej kolejnosci.
Myslalem raczej o wlasnym mallocu:
jakies duze tablice i przydzielanie zawsze n*x-bajtow, gdzie n =32 lub np 64
tylko ze czasem bedzie potrzeba np 5 bajtow a czasem 255.
pozdr.
jfk
========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai
From: "jfk" <jotefka_at_nospam_poczta.fm>
Subject: Re: [avr-gcc] przydzial pamieci
Date: Tue, 13 Jul 2004 08:11:25 +0200
Z linka podanego przez Jurka wynika że zostawienie czesci pamieci zawsze
wolnej jednak moze pomoc.
Tylko pewnie trzeba wiecej niz 25% ;-(
Autor malloca twierdzi poza tym ze i tak malloc jest najefektywniejszym
wykorzystaniem pamieci.
Dzieki wszystkim
jfk
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: JS <jar0sz_at_nospam_polbox.com.pl_without_pl>
Subject: Re: [avr-gcc] przydzial pamieci
Date: Wed, 14 Jul 2004 13:18:31 +0000 (UTC)
W artykule <ccvthb$ekt$1_at_nospam_inews.gazeta.pl>
autorem którego mieni się jfk, napisano:
Albo jak temu zapobiec?
Nie stosowac dynamizmu.
transmisje ? To moze bufory kolowe - tzn jeden obszar wykorzystywany
w kolko pod bufory - bo o ile rozumiem dane sie dosc szybko
dezaktualizuja ..
Bufor kołowy jest zbyt prosty - to nie moze byc zadne fifo lifo itp. bo
zwalnianie moze byc w roznej kolejnosci.
Myslalem raczej o wlasnym mallocu:
jakies duze tablice i przydzielanie zawsze n*x-bajtow, gdzie n =32 lub np 64
tylko ze czasem bedzie potrzeba np 5 bajtow a czasem 255.
Przydzielać zawsze 255 ?
O ile pamięci starczy ...
Inna możliwość to defragmentacja w razie potrzeby. Problemem jest tu
konieczność przesunięcia bloków, które uniemożliwiają wykonanie
żądanego przydziału. Wskaźniki do tych bloków, jeśli są zapamiętane
gdzieś w programie (a są, bo to jest istota działania malloc'a),
staną się nieważne.
Jedno z wyjść to obsługa przydziału w oparciu
o uchwyty bloków pamięci: funkcja przydziału zwraca identyfikator
bloku (nie adres) który nie zmienia wartości mimo przemieszczania
bloku w pamięci podczas defragmentacji.
Aby uzyskać adres, blok trzeba unieruchomić (wtedy zarządca pamięci
nie może go przesunąć), a po użyciu - znowu uruchomić.
Drugie wyjście to użycie master-pointera. Zarządca pamięci uaktualnia
zawartość tego wskaźnika w razie przesuwania bloków. Oczywiście
kopie tego wskaźnika mogą stać się nieważne.
--
Pozdrawiam
Jarosław Szynal
========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!newsfeed.pionier.net.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: [avr-gcc] przydzial pamieci
Date: Fri, 16 Jul 2004 14:08:06 +0200
jfk wrote:
Pisze duzy programik na mega128 z zewn ram 32k.
bo potrzebuje duzo roznych buforow.
Czy Waszym zdaniem moge korzystac z malloc() i free()?
uklad bedzie odbieral po rs485 i po spi ramki roznej dlugosci ( od 32 do
prawie 250 bajtow) i sklejał w jeszcze wieksze czasami.
Po przeczytaniu watku: a dlaczego nie napisac wlasnego
alokatora dzialajacego wg. strategii blokow blizniaczych?
Jakie jest ryzyko że ram sie zdefragmentuje?
S_fragmentuje_, defragmentacja, czyli scalanie, to korzystne zjawisko. :-)
Ktos ma doswiadczenia z dynamiczna pamiecia?
Ja, ale zanim zaczniemy o tym rozmawiac, przeczytaj sobie to:
http://www.cs.northwestern.edu/~pdinda/ics-f02/doc/dsa.pdf
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.internetia.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_SPAMTRAP.slackware.pl>
Subject: Re: [avr-gcc] przydzial pamieci
Date: 17 Jul 2004 14:54:08 +0200
On Fri, 16 Jul 2004 14:08:06 +0200, "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl> wrote:
[.....]
Po przeczytaniu watku: a dlaczego nie napisac wlasnego
alokatora dzialajacego wg. strategii blokow blizniaczych?
A co to za algorytm? Czy chodzi o to co anglosasi nazywają
buddy system(s)?
http://www.cs.northwestern.edu/~pdinda/ics-f02/doc/dsa.pdf
Fajny papier.
Regards,
/J.D.
--
Jan Dubiec, jdx#slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!newsfeed.pionier.net.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: [avr-gcc] przydzial pamieci
Date: Mon, 19 Jul 2004 13:32:59 +0200
Jan Dubiec wrote:
A co to za algorytm? Czy chodzi o to co anglosasi nazywają
buddy system(s)?
Tak, w najprostszej wersji chodzi o rekurencyjny podzial blokow
o wielkosci 2^n bajtow na pary "blizniakow" -- sasiadujacych
ze soba blokow o dwa razy mniejszym rozmiarze. Ma to pewne
wady (ale nieistotne w tym zastosowaniu), wiec wymyslono tez
lepsze wersje.
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai