FaNkY
Admin
Data inscrierii: 26/Mar/2007
Mesaje: 2259
Localitate: De_Dust2
|
 Trimis: 12/11/2007 08:32 Titlul subiectului: Utilizarea eficienta a memoriei extinse |
 |
|
Pentru amanunte privind configura-rea sistemului de operare revedeti
arti-colul "Cum stati cu memoria?" semnat de Mircea Cioata n PC
Report din august 1994.
UMBFILES -ncarcarea tabelei SFT n memoria extinsa
Cele doua programe prezentate n continuare ilustreaza doua moduri
posibile de întrebuințare a memoriei extinse, elibernd astfel o parte din
memoria con-ventionala. Binenteles, cele doua programe vor da
rezultatele aSteptate numai daca aveti un procesor 386 sau 486 (sau,
de ce nu, chiar un Pentium), Si daca sistemul de operare DOS (cel
putin versiunea 5.0) este configurat pentru a putea utiliza Si memoria
extinsa.-
Chiar Si n ultimele versiuni de DOS, SFT (System File Table) se
ncarca n memoria conventionala, ocupnd un spatiu de cel putin nf *
59 octeti, unde nf este argumentul comenzii FILES din CONFIG.SYS .
Progra-mul UMBFILES va ajuta sa treceti peste acest mic neajuns,
ncarcnd n blocurile de memorie superioara cea mai mare parte a
tabelei SFT.
Organizarea tabelei SFT
SFT este organizata sub forma unei liste nlantuite, a carei structura
este descrisa n cadrul articolului "Configurarea dinamica a
sistemului DOS" semnat de Jozsef Szabo. Sa spunem n plus ca DOS aloca
din oficiu n memoria conventionala doua blocuri SFT, primul avnd 5
intrari, al doilea cel putin 3 intrari. Deci, pentru a utiliza
eficient memoria conventionala, vom folosi urmatoarele comenzi: - n
CONFIG.SYS : FILES = 8 - n AUTOEXEC.BAT : UMBFILES =nn n acest fel,
tabela SFT va avea n total nn+8 intrari, dintre care 8 n memoria
conventionala, Si restul de nn n memoria superioara. Pe parcurs, daca
este nevoie, tabela SFT poate fi extinsa cu o noua comanda UMBFILES.
Cum lucreaza UMBFILES?
Sa explicam
mai nti cele 4 functii API (ale ntreruperii 21h)
folosite de program pentru lucrul cu memoria extinsa: a) AX = 5800h:
obtine n registrul AL o valoare care indica strategia de alocare a
memoriei; aceasta se interpreteaza astfel: - bitii 7-6 val 00:
strategia Low-First (mai nti se ncearca alocare n memoria
con-ventionala);
- bitii 7-6 val 01: strategia High-Only (se aloca numai n memoria
superioara);
-bitii 7-6 val 10: strategia High-First (mai nti se ncearca o
alocare n memoria superioara);
- bitii 1-0 val 00: strategia First-Fit (se aloca primul bloc de
memorie a carui marime este cel putin egala cu marimea ce-ruta);
- bitii 1-0 val 01: strategia Best-Fit (se exploreaza toate blocurile
de memorie Si se aloca cel care are valoarea cea mai apro-piata - Si
cel putin egala - cu marimea ceruta);
- bitii 1-0 val 10: strategia Last-Fit (se ex-ploreaza toate blocurile
de memorie Si se aloca ultimul a carui marime este cel putin egala cu
marimea ceruta); b) AX = 5801h, BX = strategie: seteaza strategia de
alocare; c) AX = 5802h: obtine n registrul AL starea blocurilor UMB:
- AL = 0 - memoria superioara este de-conectata, absolut orice cerere de
alocare se re-zolva numai n memoria conventionala; - AL = 1 - memoria
superioara este tratata ca o extensie logica a memoriei
con-ventionale;
d) AX = 5803h, BX = stare UMB: seteaza starea blocurilor UMB. UMBFILES
foloseSte strategia de alocare High-Only / Best-Fit. Dupa ce se
converteSte valoarea argumentului (numarul de intrari cu care se
extinde SFT) n numar de paragrafe, se aloca n memoria superioara un
bloc de marimea ceruta. Se actualizeaza lantul SFT Si se initializeaza
blocul SFT alocat. S-ar putea crede ca misiunea programului se ncheie
aici. Ramne totuSi o problema nerezolvata. Cnd un proces se termina,
DOS elibereaza automat toata memoria care i-a fost alocata, inclusiv
UMB-urile proprii (nu este cazul proceselor rezidente). Pentru ca DOS
sa nu elibereze blocul SFT creat, UMBFILES utilizeaza un subterfugiu
pentru a pacali sistemul: modifica valoarea din cmpul proprietar al
MCB, punnd aici tocmai valoarea returnata n urma cererii de alocare.
Astfel relatia acestui UMB cu programul nu mai este reperata.
MEMORY - cum putem obtine un Heap mai mare?
Strategia acestui program (care Stie n ce zona de memorie a fost
ncarcat) este prezentata n continuare. Indiferent n ce zona de
memorie (conventionala sau superioara) este ncarcat, memoria Heap
este localizata n aceeaSi zona cu programul. Din aceasta cauza,
atunci cnd programul este ncarcat n memoria superioara, n cea
conventionala ramne un bloc suficient de mare nefolosit. Ideea este deci
de a ncarca programul n memoria superioara (cu ajutorul comenzii
LOADHIGH), Si de a aloca pentru sine maximum posibil din memoria
conventionala. Se modifica apoi valorile variabilelor care pastreaza
configuratia memoriei Heap, astfel nct ele sa indice spre zona de
memorie alocata; n plus functiile MemAvail Si MaxAvail trebuie sa
reflecte marimea acestei zone de memorie. Ne putem da seama de
diferenta dintre cele doua situatii posibile lansnd o data programul
cu comanda MEMORY (deci ncarcare n memoria conventionala), Si apoi
cu comanda LH MEMORY (deci ncarcare n memoria superioara). Aceasta
idee poate fi folosita n situatia n care avem un program nu foarte
mare (!) -el trebuie sa ncapa ntr-un UMB -, dar care are trebuință de o
zona de manevra n memorie îndeajuns de mare. Desigur, un program mai
complex ar putea utiliza Si alte facilitati oferite de un driver EMM
(Extended Memory Manager) - cum ar fi de exemplu tehnici de gestionare
a memoriei expandate (oferite de majoritatea acestor driver-e).
_________________
 |
|
[/URL]