Memorie convențională - Conventional memory

Zonele de memorie ale familiei IBM PC

În gestionarea memoriei DOS , memoria convențională , numită și memorie de bază , este primul 640 kilobyte de memorie pe computerul IBM sau sistemele compatibile. Este memoria de citire-scriere adresabilă direct de procesor pentru utilizarea sistemului de operare și a programelor de aplicații. Deoarece prețurile memoriei au scăzut rapid, această decizie de proiectare a devenit o limitare a utilizării capacităților mari de memorie până la introducerea sistemelor de operare și a procesoarelor care au făcut-o irelevantă.

Bariera de 640 KB

Blocuri de memorie IBM PC, PC / XT , 3270 PC și PCjr
0-bloc 1 64 KB Memorie obișnuită de utilizator până la 64 KB (zonă de memorie redusă)
1 bloc 2 64 KB Memorie obișnuită de utilizator la 128 KB
2 blocuri 3 64 KB Memorie obișnuită a utilizatorului la 192 KB
3 blocuri 4 64 KB Memorie obișnuită de utilizator la 256 KB
4 blocuri 5 64 KB Memorie obișnuită de utilizator la 320 KB
5 blocuri 6 64 KB Memorie de utilizator obișnuită până la 384 KB
6 blocuri 7 64 KB Memorie obișnuită de utilizator la 448 KB
7 blocuri 8 64 KB Memorie obișnuită de utilizator la 512 KB
8 blocuri 9 64 KB Memorie obișnuită de utilizator până la 576 KB
9 blocuri 10 64 KB Memorie obișnuită de utilizator la 640 KB
Un bloc 11 64 KB Memorie video extinsă ( EGA )
Blocul B 12 64 KB Memorie video standard ( MDA / CGA )
Blocul C 13 64 KB Extindere ROM (XT, EGA, 3270 PC)
Bloc D 14 64 KB alte utilizări (cartușe PCjr, LIM EMS )
E-bloc 15 64 KB alte utilizări (cartușe PCjr, LIM EMS)
F-bloc 16 64 KB Sistem ROM-BIOS și ROM-BASIC

Bariera KB 640 este o limitare arhitecturală a IBM PC compatibil PC. Intel 8088 CPU, utilizat în IBM PC - ul inițial , a fost capabil să abordeze 1 MB (2 20  bytes), din moment ce chip a oferit 20 de linii de adresă . În proiectarea computerului, memoria sub 640 KB era pentru memorie cu acces aleatoriu pe placa de bază sau pe plăcile de expansiune și a fost numită zona de memorie convențională.Primul segment de memorie (64 KB) al zonei de memorie convenționale se numește memorie inferioară sau zonă de memorie redusă . Restul de 384 KB dincolo de zona de memorie convențională, numită zona de memorie superioară (UMA), a fost rezervat pentru utilizarea sistemului și a dispozitivelor opționale. UMA a fost folosit pentru BIOS-ul ROM , memorie suplimentară numai în citire , extensii BIOS pentru unități de disc fixe și adaptoare video, memorie pentru adaptor video și alte dispozitive de intrare și ieșire mapate cu memorie . Designul computerului IBM original a plasat harta de memorie Color Graphics Adapter (CGA) în UMA.

Nevoia de mai multă memorie RAM a crescut mai repede decât nevoile hardware-ului pentru a utiliza adresele rezervate, ceea ce a dus la faptul că memoria RAM a fost în cele din urmă mapată în aceste zone superioare neutilizate pentru a utiliza tot spațiul adresabil disponibil. Aceasta a introdus o „gaură” rezervată (sau mai multe găuri) în setul de adrese ocupate de hardware care ar putea fi utilizate pentru date arbitrare. Evitarea unei astfel de găuri a fost dificilă și urâtă și nu a fost susținută de DOS sau de majoritatea programelor care ar putea rula pe ea. Mai târziu, spațiul dintre găuri ar fi folosit ca blocuri de memorie superioare (UMB).

Pentru a menține compatibilitatea cu sistemele de operare și aplicațiile mai vechi, bariera de 640 KB a rămas parte a designului PC-ului chiar și după ce 8086/8088 a fost înlocuit cu procesorul Intel 80286 , care putea adresa până la 16 MB de memorie în modul protejat . Bariera de 1 MB a rămas, de asemenea, atâta timp cât 286 funcționa în modul real , deoarece DOS a necesitat un mod real care utilizează registrele segment și offset într-o manieră suprapusă, astfel încât adresele cu mai mult de 20 de biți să nu fie posibile. Este încă prezent în compatibilele IBM PC astăzi dacă rulează în modul real, cum este cel utilizat de DOS. Chiar și cele mai moderne computere Intel au încă o suprafață între 640 și 1024  KB rezervată. Cu toate acestea, acest lucru este invizibil pentru programele (sau chiar majoritatea sistemului de operare) de pe sistemele de operare mai noi (cum ar fi Windows , Linux sau Mac OS X ) care utilizează memorie virtuală , deoarece nu au deloc cunoștință de adresele de memorie fizică. În schimb, acestea funcționează într-un spațiu virtual de adrese, care este definit independent de adresele RAM disponibile.

Unele plăci de bază dispun de opțiunea „Orificiul de memorie la 15 megabyți” necesară pentru anumite plăci video VGA care necesită acces exclusiv la un anumit megabyte pentru memoria video. Plăcile video ulterioare care utilizează magistrala AGP (spațiu de memorie PCI) pot avea 256 MB de memorie cu o dimensiune a diafragmei de 1 GB .

Memorie suplimentară

O tehnică utilizată pe computerele IBM XT timpurii a fost instalarea RAM suplimentară în intervalul de adrese de memorie video și împingerea limitei până la începutul adaptorului de afișare monocrom (MDA). Uneori, software-ul sau un decodor de adresă personalizat a fost necesar pentru ca acest lucru să funcționeze. Aceasta a mutat bariera la 704 KB (cu MDA / HGC) sau 736 KB (cu CGA).

Administratorii de memorie pe sisteme bazate pe 386 (cum ar fi QEMM sau MEMMAX (+ V) în DR-DOS ) ar putea obține același efect, adăugând memorie convențională la 640 KB și mutând bariera la 704 KB (până la segmentul B000, începutul MDA / HGC) sau 736 KB (până la segmentul B800, începutul CGA). Numai CGA ar putea fi utilizat în această situație, deoarece memoria video Adaptor grafic îmbunătățit (EGA) era imediat adiacentă zonei de memorie convenționale sub linia de 640 KB; aceeași zonă de memorie nu a putut fi utilizată atât pentru bufferul de cadre al plăcii video, cât și pentru programele tranzitorii.

Toate Calculatoare cârcă add-on unitățile de gestionare a memoriei AllCard pentru XT- și Chargecard pentru 286 calculatoare / 386SX-clasă, precum și ECM MicroWay lui (Extended convențională Memory) add-on-board permis de memorie normal să fie mapat în A0000 -Gama de adrese EFFFF ( hex ), oferind până la 952 KB pentru programele DOS. Programe precum Lotus 1-2-3 , care accesau direct memoria video, trebuiau corecționate pentru a gestiona acest aspect de memorie. Prin urmare, bariera de 640 KB a fost eliminată în detrimentul compatibilității hardware.

De asemenea, a fost posibil să se utilizeze redirecționarea consolei (fie prin specificarea unui dispozitiv de consolă alternativ, cum ar fi AUX: atunci când se invocă inițial COMMAND.COM sau se utilizează CTTY mai târziu) pentru a direcționa ieșirea și a primi intrarea de la un terminal prost sau de la un alt computer care rulează un emulator de terminal. . Presupunând că BIOS-ul sistemului a permis în continuare mașinii să pornească (ceea ce este adesea cazul cel puțin cu BIOS-urile pentru computerele încorporate), placa video ar putea fi apoi îndepărtată complet, iar sistemul ar putea furniza un total de 960 KB de memorie DOS continuă pentru programe a încărca.

O utilizare similară a fost posibilă pe multe computere compatibile cu DOS, dar nu cu IBM, cu o structură de memorie non-fragmentată, de exemplu Victor 9000 / Sirius 1 sau PC-ul Apricot care suporta până la 896 KB de memorie DOS continuă pentru a fi utilizată în versiunea sa personalizată. din MS-DOS.

Software de driver DOS și TSR-uri

Majoritatea programelor standard scrise pentru DOS nu au neapărat nevoie de 640 KB sau mai mult de memorie. În schimb, software-ul driverului și utilitățile denumite programe Terminate and Stay Resident (TSR) ar putea fi utilizate în plus față de software-ul DOS standard. Aceste drivere și utilitare utilizează în mod permanent o anumită memorie convențională, reducând totalul disponibil pentru programele DOS standard.

Unele drivere DOS foarte frecvente și TSR-uri care utilizează memorie convențională au inclus:

  • ANSI.SYS - suport pentru text color și rezoluții diferite de text
  • ASPIxDOS.SYS, ASPIDISK.SYS, ASPICD.SYS - toate trebuie încărcate pentru ca unitățile Adaptec SCSI și CD-ROM- urile să funcționeze
  • DOSKEY.EXE - permite reamintirea comenzilor DOS tastate anterior folosind săgeata sus
  • LSL.EXE, E100BODI.EXE (sau alt driver de rețea), IPXODI.EXE, NETX.EXE - toate trebuie să fie încărcate pentru accesul la litera unității serverului de fișiere NetWare
  • MOUSE.EXE - suport pentru dispozitive mouse în programele DOS
  • MSCDEX.EXE - suport pentru accesul la unitatea CDROM și litera unității, utilizat în combinație cu un driver separat specific producătorului. Este necesar în plus față de driverele SCSI de mai sus pentru accesul la un dispozitiv CDROM SCSI.
  • SBCONFIG.EXE - suport pentru dispozitivul audio Sound Blaster 16 ; un driver cu nume diferit a fost folosit pentru diverse alte plăci de sunet, ocupând, de asemenea, memoria convențională.
  • SMARTDRV.EXE - instalați memoria cache a unității pentru a accelera citirile și scrierile pe disc; deși ar putea aloca mai mulți megabyți de memorie peste 640 kb pentru stocarea în cache a unității, totuși avea nevoie de o mică parte din memoria convențională pentru a funcționa.

După cum se poate vedea mai sus, multe dintre aceste drivere și TSR-uri ar putea fi considerate practic esențiale pentru funcționarea completă a sistemului. Dar, în multe cazuri, utilizatorul computerului a decis să decidă dacă poate rula anumite programe DOS standard sau dacă au încărcat toate driverele și TSR-urile lor preferate. Încărcarea întregii liste de mai sus este probabil imposibilă sau imposibilă, dacă utilizatorul dorește să ruleze și un program DOS standard.

În unele cazuri, driverele sau TSR-urile ar trebui descărcate din memorie pentru a rula anumite programe și apoi reîncărcate după rularea programului. Pentru driverele care nu au putut fi descărcate, versiunile ulterioare ale DOS au inclus o capacitate de meniu de pornire pentru a permite utilizatorului computerului să selecteze diferite grupuri de drivere și TSR-uri pentru a le încărca înainte de a rula anumite programe DOS standard cu utilizare ridicată a memoriei.

Blocuri de memorie superioare și încărcare ridicată

Pe măsură ce aplicațiile DOS au devenit mai mari și mai complexe la sfârșitul anilor 1980 și începutul anilor 1990, a devenit o practică obișnuită eliberarea memoriei convenționale prin mutarea driverelor de dispozitiv și a programelor TSR în blocuri de memorie superioare (UMB) în zona de memorie superioară (UMA) la boot , pentru a maximiza memoria convențională disponibilă pentru aplicații. Acest lucru a avut avantajul de a nu necesita modificări hardware și a păstrat compatibilitatea aplicației.

Această caracteristică a fost furnizată mai întâi de produse terțe, cum ar fi QEMM , înainte de a fi încorporată în DR DOS 5.0 în 1990, apoi MS-DOS 5.0 în 1991. Majoritatea utilizatorilor au folosit driverul EMM386 însoțitor furnizat în MS-DOS 5, dar produse de la terți de la companii precum QEMM s-au dovedit de asemenea populare.

La pornire, driverele ar putea fi încărcate la nivel înalt folosind directiva „ DEVICEHIGH =”, în timp ce TSR-urile ar putea fi încărcate la mare folosind directivele „ LOADHIGH ”, „ LH ” sau „ HILOAD ”. Dacă operațiunea a eșuat, driverul sau TSR s-ar încărca automat în memoria convențională obișnuită.

CONFIG.SYS , încărcarea ANSI.SYS în UMB-uri, fără suport EMS activat: 

DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE NOEMS
DEVICEHIGH=C:\DOS\ANSI.SYS

AUTOEXEC.BAT , încărcând MOUSE, DOSKEY și SMARTDRV în UMB, dacă este posibil: 

LH C:\DOS\MOUSE.EXE
LH C:\DOS\DOSKEY.EXE
LH C:\DOS\SMARTDRV.EXE

Capacitatea versiunilor DOS 5.0 și ulterioare de a muta propriul cod de bază al sistemului în zona de memorie înaltă (HMA) prin comanda DOS = HIGH a dat un nou impuls memoriei libere.

Optimizare driver / TSR

Plăcile de expansiune hardware ar putea utiliza oricare din zona de memorie superioară pentru adresarea ROM, astfel încât blocurile de memorie superioare au fost de dimensiuni variabile și în locații diferite pentru fiecare computer, în funcție de hardware-ul instalat. Unele ferestre de memorie superioară ar putea fi mari și altele mici. Încărcarea driverelor și a TSR-urilor ar alege un bloc și ar încerca să încadreze programul în el, până când s-a găsit un bloc unde se potrivește sau va intra în memoria convențională.

Un aspect neobișnuit al driverelor și al TSR-urilor este că acestea ar folosi cantități diferite de memorie convențională și / sau superioară, pe baza ordinii în care au fost încărcate. Acest lucru ar putea fi folosit în avantaj dacă programele au fost încărcate în mod repetat în ordine diferite și verificând câtă memorie era liberă după fiecare permutare. De exemplu, dacă a existat un UMB de 50 KB și un UMB de 10 KB și au fost încărcate programele care necesită 8 KB și 45 KB, cei 8 KB ar putea intra în UMB de 50 KB, împiedicând încărcarea celui de-al doilea. Versiunile ulterioare ale DOS au permis utilizarea unei adrese de încărcare specifice pentru un driver sau TSR, pentru a se potrivi mai strâns între driverele / TSR-urile.

În MS-DOS 6.0, Microsoft a introdus MEMMAKER, care a automatizat acest proces de potrivire a blocurilor, potrivind funcționalitatea oferită de administratorii de memorie terți . Această optimizare automată de multe ori încă nu a oferit același rezultat ca și efectuarea manuală, în sensul de a oferi cea mai mare memorie convențională gratuită.

De asemenea, în unele cazuri, companiile terțe au scris drivere multifuncționale speciale care ar combina capacitățile mai multor drivere standard DOS și TSR-uri într-un singur program foarte compact, care a folosit doar câțiva kilobiți de memorie. De exemplu, funcțiile driverului mouse-ului, driverului CD-ROM, suportului ANSI, reamintirii comenzii DOSKEY și memorarea în cache a discului ar fi toate combinate împreună într-un singur program, consumând doar 1-2 kilobiți de memorie convențională pentru accesul normal al driverului / întreruperii și stocarea restului codului programului multifuncțional în memoria EMS sau XMS.

Extensoare DOS

Bariera a fost depășită doar odată cu sosirea extensoarelor DOS , care au permis aplicațiilor DOS să ruleze în mod protejat pe 16 biți sau pe 32 de biți , dar acestea nu au fost utilizate pe scară largă în afara jocurilor pe computer . Cu un extender DOS pe 32 de biți, un joc ar putea beneficia de un spațiu de adresă plat de 32 de biți și setul complet de instrucțiuni pe 32 de biți fără prefixele de operare / adresă de 66h / 67h. Extensorii DOS pe 32 de biți necesită suport pentru compilator (compilatoare pe 32 de biți) în timp ce XMS și EMS lucrau cu un vechi compilator care viza aplicații DOS în mod real pe 16 biți. Cele mai comune două specificații pentru extensoarele DOS au fost VCPI - și ulterior compatibile DPMI cu Windows 3.x.

Cel mai notabil extender DOS compatibil DPMI poate fi DOS / 4GW , livrat cu Watcom . Era foarte frecvent în jocurile pentru DOS. Un astfel de joc ar consta fie dintr-un kernel DOS / 4GW pe 32 de biți, fie dintr-un stub care a încărcat un kernel DOS / 4GW situat în cale sau în același director și un „executabil liniar” pe 32 de biți. Sunt disponibile utilități care pot elimina DOS / 4GW dintr-un astfel de program și îi permit utilizatorului să experimenteze oricare dintre clonele DOS / 4GW mai multe și poate îmbunătățite.

Înainte de extensiile DOS, dacă un utilizator a instalat memorie suplimentară și a dorit să o folosească în DOS, ar trebui mai întâi să instaleze și să configureze driverele pentru a accepta fie specificațiile de memorie extinsă (EMS), fie specificațiile de memorie extinse (XMS) și să ruleze programe care acceptă una dintre aceste specificații.

EMS a fost o specificație disponibilă pe toate computerele, inclusiv pe cele bazate pe Intel 8086 și Intel 8088 , care permiteau hardware-ului suplimentar să afișeze mici bucăți de memorie în și în afara ( comutare bancară ) a spațiului de adresare „mod real” (0x0400– 0xFFFF). Acest lucru a permis programelor DOS în mod real pe 16 biți să acceseze mai mulți megabyte de RAM printr-o gaură din memoria reală, de obicei (0xE000–0xEFFF). Un program ar trebui apoi să solicite explicit accesarea paginii înainte de a o utiliza. Aceste locații de memorie ar putea fi apoi utilizate în mod arbitrar până când vor fi înlocuite cu o altă pagină. Acest lucru este foarte asemănător cu memoria virtuală paginată modernă . Cu toate acestea, într-un sistem de memorie virtuală, sistemul de operare gestionează toate operațiunile de paginare , în timp ce paginarea a fost explicită cu EMS.

XMS a furnizat un protocol de bază care a permis unui program DOS de 16 biți să încarce bucăți de memorie extinsă 80286 sau 80386 în memorie redusă (adresa 0x0400-0xFFFF). Un driver XMS tipic a trebuit să treacă în modul protejat pentru a încărca această memorie. Problema cu această abordare este că, în timp ce în modul protejat 286, apelurile DOS directe nu au putut fi efectuate. Soluția de soluționare a fost de a implementa un mecanism de apelare inversă, necesitând o resetare a 286. Pe 286, aceasta a fost o problemă majoră. Intel 80386 , care a introdus „ modul virtuale 8086 “, a permis nucleul de oaspeți să se întreacă în 8086 și rula sistemul de operare gazdă , fără a fi nevoie pentru a forța de fapt , partea din spate procesor în „mod real“. HIMEM.SYS 2.03 și versiunile ulterioare au folosit modul ireal pe procesoarele 80386 și versiunile superioare, în timp ce HIMEM.SYS 2.06 și versiunile ulterioare au folosit LOADALL pentru a schimba registrele interne nedocumentate pe 80286, îmbunătățind semnificativ latența de întrerupere evitând comutatoarele repetate de mod real / mod protejat.

Windows instalează propria sa versiune de HIMEM.SYS pe DOS 3.3 și versiuni ulterioare. Windows HIMEM.SYS lansează furnizorul de servicii XMS (n) .0 în mod protejat pe 32 de biți pentru Windows Virtual Machine Manager, care oferă apoi servicii XMS (n-1) .0 către casetele DOS și pe mașina Windows pe 16 biți (de exemplu, DOS 7 HIMEM.SYS este XMS 3.0, dar executarea comenzii „MEM” într-o fereastră Windows 95 DOS afișează informații XMS 2.0).

Vezi si

Referințe

Lecturi suplimentare