[avr-gcc] przydzial pamieci



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomość
Spis treści
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

Poprzedni Następny
Wiadomość
Spis treści
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

Poprzedni Następny
Wiadomość
Spis treści
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

Poprzedni Następny
Wiadomość
Spis treści
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

Poprzedni Następny
Wiadomość
Spis treści
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

Poprzedni Następny
Wiadomość
Spis treści
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

Poprzedni Następny
Wiadomość
Spis treści
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

Poprzedni Następny
Wiadomość
Spis treści
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

Poprzedni Następny
Wiadomość
Spis treści
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