Àrea de memòria superior

De la Viquipèdia, l'enciclopèdia lliure
No s'ha de confondre amb Àrea de memòria alta.
L'àrea de memòria superior es troba entre 640 KB i 1024 KB.

A l'entorn de gestió de memòria DOS, l' àrea de memòria superior (UMA) fa referència a la memòria entre les adreces de 640. KB i 1024 KB (0x A0000–0xFFFFF) en un PC IBM o compatible. IBM va reservar els 384KB superiors dels 1024KB que podia accedir la CPU 8088 per a la ROM del BIOS, la ROM del BIOS de vídeo, les ROMs opcionals, la memòria RAM de vídeo, la memòria RAM dels perifèrics, les E/S mapejades a la memòria i la obsoleta ROM BASIC.[1]

Tanmateix, fins i tot mapejant la memòria RAM de vídeo, la ROM del BIOS, la ROM del BIOS de vídeo, les ROMs opcionals i els ports d'E/S per a perifèrics, gran part dels 384 KB d'espai d'adreces no s'utilitzava. Atès que la restricció de 640 KB de memòria es va convertir cada cop més en un obstacle, es van trobar tècniques per omplir les àrees buides amb RAM. Aquestes àrees es van anomenar blocs de memòria superior (UMB).

Ús[modifica]

La següent etapa en l'evolució del DOS va ser que el sistema operatiu utilitzés blocs de memòria superiors (UMB) i l'àrea de memòria alta (HMA). Això va passar amb el llançament del DR DOS 5.0 el 1990. El gestor de memòria integrat del DR DOS, EMM386. EXE, podia realitzar la major part de la funcionalitat bàsica del QEMM i programes semblants.[2]

L'avantatge del DR DOS 5.0 sobre la combinació d'un DOS més antic amb QEMM afegit era que el mateix nucli del DR DOS i gairebé totes les seves estructures de dades es podien carregar a la memòria alta. Això deixava pràcticament tota la memòria base lliure, permetent configuracions emprant fins a 620 KB dels 640 KB accessibles.

La configuració no era automàtica: els UMB lliures s'havien d'identificar manualment, incloent-los manualment a la línia de codi que carregava EMM386 des del CONFIG. SYS, i després els controladors, etc., s'havien de carregar manualment als UMB des del CONFIG. SYS i AUTOEXEC. BAT. Aquesta configuració no era procés trivial. Com que estava en gran part automatitzat pel programa d'instal·lació de QEMM, aquest programa va sobreviure al mercat; de fet, funcionava bé amb el suport HMA i UMB del propi DR-DOS i va passar a ser una de les utilitats més venudes per al PC.[2]

Aquesta funcionalitat va ser copiada per Microsoft amb el llançament de MS-DOS 5.0 el juny de 1991. Finalment, encara es van treure més estructures de dades del DOS de la memòria convencional, permetent deixar lliures fins a 631 KB dels 640 KB. A partir de la versió 6.0 de MS-DOS, Microsoft fins i tot va incloure un programa anomenat MEMMAKER que s'utilitzava per optimitzar automàticament la memòria convencional movent els programes TSR a la memòria superior.

Durant un període a principis de la dècada de 1990, l'optimització manual del mapa de memòria DOS es va convertir en una habilitat molt apreciada, permetent que les aplicacions més grans s'executin fins i tot en les configuracions de PC més complexes. La tècnica consistia a crear primer tants UMB com sigui possible, inclosa la reassignació de blocs de memòria assignats però no utilitzats, com ara l'àrea de visualització monocroma de les màquines de color. Aleshores, s'havien de carregar molts subcomponents de DOS en aquests UMB en la seqüència correcta per utilitzar els blocs de memòria de la manera més eficient possible. Alguns programes TSR requerien memòria addicional durant la càrrega, que es va alliberar de nou un cop finalitzada la càrrega. Afortunadament, hi havia poques dependències entre aquests mòduls, de manera que era possible carregar-los en gairebé qualsevol seqüència. Les excepcions eren que per emmagatzemar amb èxit els CD-ROM, la majoria de les memòries cache de disc s'havien de carregar després de qualsevol controlador de CD-ROM i que els mòduls de la majoria de les piles de xarxa s'havien de carregar en una seqüència determinada, bàsicament treballant progressivament a través de les capes del Model OSI.[2]

Un mètode bàsic però eficaç utilitzat per optimitzar la memòria convencional va ser carregar el controlador HIMEM. SYS, carregant després l'EMM386. EXE com a controlador amb l'opció "RAM AUTO" que permet l'accés a l'UMA carregant els controladors de dispositiu com a devicehigh. Aquest mètode carrega eficaçment els gestors de memòria fonamentals a la memòria convencional i, després, tota la resta a l'UMA. Els programes menjadors de memòria convencional com MSCDEX també es podien carregar a l'UMA d'una manera similar, alliberant per tant una gran quantitat de memòria convencional.

Windows[modifica]

La creixent popularitat de Windows 3.0 va fer que la necessitat de l'àrea de memòria superior fos menys rellevant, ja que les aplicacions de Windows no es van veure afectades directament pels límits de memòria base de DOS, però els programes DOS que s'executaven sota Windows (amb el mateix Windows actuant com a gestor de múltiples tasques) encara es veien afectats. Amb el llançament de Windows 95, es va tornar menys rellevant encara, ja que aquesta versió de Windows proporciona gran part de la funcionalitat dels controladors DOS a les aplicacions DOS que s'executaven sota Windows, com ara el suport de CD, xarxa i so; el mapa de memòria caixes DOS de Windows 95 s'optimitzaven automàticament. Tanmateix, no tots els programes DOS es podien executar en aquest entorn. Concretament, els programes que intentessin canviar directament del mode real al mode protegit no funcionaven, ja que això no estava permès en el mode 8086 virtual en què s'executava. A més a més, els programes que intentaven fer el canvi utilitzant l'API de la interfície de programa de control virtual (VCPI) (que es va introduir per permetre que els programes DOS que necessitaven un mode protegit l'accés des del mode 8086 virtual configurat per un gestor de memòria, tal com s'ha descrit anteriorment) no funcionava a Windows 95. Només s'admetia l'API del DOS Protected Mode Interface (DPMI) per canviar al mode protegit.[3]

Implementació[modifica]

Mode virtual 8086[modifica]

Els blocs de memòria superiors es poden crear assignant la memòria estesa a l'àrea de memòria superior quan s'executen en mode 8086 virtual. Això és semblant a com es pot emular la memòria ampliada utilitzant la memòria estesa, de manera que aquest mètode per proporcionar blocs de memòria superiors sol ser proporcionat pel gestor de memòria ampliada (per exemple, EMM386). La interfície de programació d'aplicacions per gestionar els blocs de memòria superiors s'especifica a l'especificació de memòria eXtended .

Shadow RAM[modifica]

En molts sistemes, inclosos els moderns, és possible utilitzar la memòria reservada per a l'ombra de la ROM de la targeta d'expansió com a memòria superior. Molts chipsets es reserven fins a 384 KB RAM per a aquest propòsit i com que aquesta RAM no s'utilitza generalment, es pot utilitzar com a memòria superior en mode real amb un controlador de driver personalitzat, com ara UMBPCI.

IBM XT[modifica]

Als ordinadors IBM XT, era possible afegir més memòria a la placa base i utilitzar un descodificador d'adreces PROM personalitzat per fer-lo aparèixer a l'àrea de memòria superior. Igual que amb la memòria superior basada en 386 descrita anteriorment, la memòria RAM addicional es podria utilitzar per carregar fitxers TSR o com a disc RAM.[4]

La targeta AllCard, una unitat de gestió de memòria addicional per a ordinadors de classe XT, permetia assignar la memòria normal a l'interval d'adreces 0xA0000-EFFFF, donant fins a 952 KB per a programes DOS. Els programes com el Lotus 1-2-3, que accedien directament a la memòria de vídeo, s'havien de pegar per gestionar aquest disseny de memòria. Per tant, la barrera de 640 KB es va eliminar a costa de la compatibilitat del programari. Aquest ús de l'àrea de memòria superior és diferent de l'ús de blocs de memòria superiors, que s'utilitzaven per alliberar memòria convencional movent els controladors de dispositiu i els TSR a la part superior 384. KB de 1 MB d'espai d'adreces, però va deixar la quantitat de memòria adreçable (640 KB) intacte.[3]

Vegeu també[modifica]

Referències[modifica]

  1. «Memory Map (x86) - OSDev Wiki». wiki.osdev.org. [Consulta: 20 desembre 2020].
  2. 2,0 2,1 2,2 «MS-DOS 5.0 Development Post-Mortem Report». Microsoft, 18-09-1991. Arxivat de l'original el 2019-04-02. [Consulta: 22 juliol 2019]. «[…] Un dels estimulants més importants per afegir funcions va ser la pressió competitiva de DRDOS 5.0, de la qual vam saber per primera vegada a la primavera de 1990. El conjunt de funcions DRDOS ens va portar a afegir UMB suport, intercanvi de tasques i recuperació. […] Una gran quantitat de l'atenció de la direcció de l'equip es va desviar cap a noves funcions com ara programari de transferència de fitxers, recuperació i instal·lació de xarxa […] Finalment, aquesta situació va arribar a un punt de crisi a finals de juliol de 1990 i, dirigida per BradS, la direcció de l'equip va passar una àrdua sèrie de reunions fixant un calendari i un procés per tancar el projecte. […]» (1+32 pages)
  3. 3,0 3,1 «UMBPCI V3.89 - c't magazine's hardware-UMB-driver for DOS and Win95/98». Arxivat de l'original el 2019-12-30. [Consulta: 7 febrer 2020].
  4. «What is high memory, why do I care, and how can I use it?», 2001. Arxivat de l'original el 2018-10-05. [Consulta: 7 febrer 2020].