malloc/free

[Jindrich Fucik]

OK, já bych se o těch intelech nehádal, už mi ten dějepis moc nejde, 
takže se nemám o co opřít.

Spíš jsem chtěl ukázat, že existují relativně jeddnoduché metody, jak 
správce paměti může defragmentovat, aniž by tím poškodil vzhled pointerů 
v uživatelském programu.

Dne 5.11.2016 v 17:07 Pavel Hudecek napsal(a):
> Tak tady bych se teda hádal: 286 i 386 mají selektory, liší se jen
> formát položek tabulky. 286 umožňovala délku segmentu 0-64 kB
> definovanou po B, od 386 se jedním bitem nastavuje, zda je to jako na
> 286, nebo do 4 GB, ale velikost je pak dělitelná 4 kB. Virtualizace Vámi
> popsaným způsobem šla už na 286, od 386 je výhodnější použít
> stránkování, což je další virtualizační level mezi fyzickou pamětí a
> segmenty.
>
> Velké ARMy mají taky nějaké takové memory managementy, ale zatím jim tak
> dobře nerozumím, k Pentiu jsem měl knížky v češtině. Není něco takového
> k ARMům?
>
> PH
>
> -----Původní zpráva----- From: Jindrich Fucik
> Tady nám ještě schází jedno malé kouzlo - podívat se na architekturu
> používaného procesoru.
> Například intel - původně používal pointr ve tvaru segment:offset. Na
> šestnáctibitech (8086) tedy dvě šestnáctibitová čísla: 1234:1234, přitom
> platilo, že segment*konstanta+offset dávají fyzickou adresu.
> Konstanta nebyla moc velká, tuším 16, takže se na jedno místo dalo
> dosáhnout jako 0001:0000 a nebo 0000:0010.
>
> Pak přišla 286 která zavádí chráněný režim a segment už mohl být celý
> unikátní a měl velokost 64k, takže do něj nemohl nikdo jiný a nedal se
> naadresovat jinak. Pořád však leží jeden za druhým.
>
> A pak tu máme 386, ta místo segment zavádí slovo selector. Selector je
> číslo bloku, který si přejeme dostat, ale existuje někde tabulka, která
> říká, jakej je přepočet selector -> fyzická adresa, respektive, kde je
> daný selector ve fyzické paměti. A aby se to nepletlo, tak zavádí i
> výjimku, která říká, že v té paměti vůbec není. To se pak využilo pro
> to, aby se obsah paměti vystěhoval třeba na disk a vznikl nám swap.
> Prostě proces si chce sáhnout na selector 1234, podle tabulky se zjistí,
> že není v paměti, tak se operační systém podívá kde je na disku, stáhne
> ho do paměti a tvému procesu vrátí s úsměvem že je to fyzická adresa XYZ.
>
> A tímto dlouhým povídáním jsem chtěl říci to, že taková defragmentace
> může probíhat, většinou je to vlastnost operačního systému, ale na
> druhou stranu tato defragmentace nemá vliv na tvar pointerů, ale jen na
> jejich přepis ze selectoru na fyzickou reprezentaci.
>
> Pochopitelně třeba na arduinu neprobíhá, tam je velmi jednoduchá správa
> paměti.
>
> Dne 3.11.2016 v 1:28 Pavel Hudecek napsal(a):
>> mějme program v C, běžící v MCU s několika desítkami kB RAM.
>>
>> Program čas od času alokuje nějakou paměť a jindy zas odalokuje.
>> Předpokládejme, že se alokují kousky od několika B až do několika kB.
>> Alokace a dealokace se dějí v obecně náhodném pořadí, tedy různé kousky
>> paměti jsou alokovány na různou dobu.
>>
>> 1. Může se stát, že se paměť postupně fragmentuje tak, že od jistého
>> okamžiku již nepůjde alokovat nějaké větší kousky, přestože celkové
>> místo by bohatě stačilo?
>> 2. Pokud se neděje (1), může se stát, že nějaký správce paměti bude v
>> průběhu času již alokované kusy v případě nutnosti přesouvat, takže se
>> budou měnit hodnoty pointerů na ně ukazujících?
>> 3. Nebo to funguje úplně jinak? :-)
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list