Konventionellt minne

Minnesområden i IBM PC-familjen

I DOS-minneshantering är konventionellt minne , även kallat basminne , de första 640 kilobytena av minnet på IBM PC eller kompatibla system. Det är läs-skrivminnet som kan adresseras direkt av processorn för användning av operativsystemet och applikationsprogram. Eftersom minnespriserna snabbt sjönk, blev detta designbeslut en begränsning i användningen av stora minneskapaciteter fram till introduktionen av operativsystem och processorer som gjorde det irrelevant.

640 KB barriär

IBM PC, PC/XT , 3270 PC och PCjr minnesblock
0-block 1:a 64 KB Vanligt användarminne till 64 KB (lågt minnesområde)
1-block 2:a 64 KB Vanligt användarminne till 128 KB
2-block 3:e 64 KB Vanligt användarminne till 192 KB
3-block 4:a 64 KB Vanligt användarminne till 256 KB
4-block 5:a 64 KB Vanligt användarminne till 320 KB
5-block 6:a 64 KB Vanligt användarminne till 384 KB
6-block 7:a 64 KB Vanligt användarminne till 448 KB
7-block 8:a 64 KB Vanligt användarminne till 512 KB
8-block 9:e 64 KB Vanligt användarminne till 576 KB
9-block 10:e 64 KB Vanligt användarminne till 640 KB
Ett block 11:e 64 KB Utökat videominne ( EGA )
B-block 12:a 64 KB Standard videominne ( MDA / CGA )
C-block 13:e 64 KB ROM-expansion (XT, EGA, 3270 PC)
D-block 14:e 64 KB annan användning (PCjr-patroner, LIM EMS )
E-block 15:e 64 KB annan användning (PCjr-patroner, LIM EMS)
F-block 16:e 64 KB System ROM-BIOS och ROM-BASIC

Barriären på 640 KB är en arkitektonisk begränsning för IBM PC-kompatibla datorer. Intel 8088- processorn, som användes i den ursprungliga IBM-datorn , kunde adressera 1 MB (2 20 byte), eftersom chippet erbjöd 20 adressrader . I designen av PC:n var minnet under 640 KB för slumpmässigt åtkomstminne på moderkortet eller på expansionskort, och det kallades det konventionella minnesområdet. Det första minnessegmentet (64 KB) i det konventionella minnesområdet benämns lägre minne eller område med lågt minne . De återstående 384 kB utöver det konventionella minnesområdet, kallat övre minnesområdet (UMA), reserverades för systemanvändning och tillvalsenheter. UMA användes för ROM BIOS , ytterligare skrivskyddat minne , BIOS-tillägg för fasta diskenheter och videoadaptrar, videoadapterminne och andra minnesmappade in- och utenheter . Designen av den ursprungliga IBM PC:n placerade minneskartan för Color Graphics Adapter (CGA) i UMA.

Behovet av mer RAM växte snabbare än hårdvarans behov för att utnyttja de reserverade adresserna, vilket resulterade i att RAM så småningom mappades till dessa oanvända övre områden för att utnyttja allt tillgängligt adresserbart utrymme. Detta introducerade ett reserverat "hål" (eller flera hål) i uppsättningen adresser som upptas av hårdvara som kunde användas för godtyckliga data. Att undvika ett sådant hål var svårt och fult och stöddes inte av DOS eller de flesta program som kunde köras på det. Senare skulle utrymmet mellan hålen användas som övre minnesblock (UMB).

För att bibehålla kompatibiliteten med äldre operativsystem och applikationer förblev 640 KB-barriären en del av PC-designen även efter att 8086/8088 hade ersatts med Intel 80286- processorn, som kunde adressera upp till 16 MB minne i skyddat läge . 1 MB-barriären fanns också kvar så länge som 286:an kördes i verkligt läge , eftersom DOS krävde realmode som använder segment- och offsetregistren på ett överlappande sätt så att adresser med mer än 20 bitar inte är möjliga. Det finns fortfarande i IBM PC-kompatibla datorer idag om de körs i verkligt läge som används av DOS. Även de modernaste Intel-datorerna har fortfarande utrymmet mellan 640 och 1024 KB reserverat. Detta är dock osynligt för program (eller till och med större delen av operativsystemet) på nyare operativsystem (som Windows , Linux eller Mac OS X ) som använder virtuellt minne , eftersom de inte har någon medvetenhet om fysiska minnesadresser alls. Istället arbetar de inom ett virtuellt adressutrymme, som definieras oberoende av tillgängliga RAM-adresser.

Vissa moderkort har ett "Memory Hole at 15 Megabyte"-alternativ som krävs för vissa VGA-videokort som kräver exklusiv åtkomst till en viss megabyte för videominne. Senare grafikkort som använder AGP -bussen (PCI-minnesutrymme) kan ha 256 MB minne med 1 GB bländarstorlek .

Ytterligare minne

En teknik som användes på tidiga IBM XT- datorer var att installera ytterligare RAM i videominnets adressintervall och skjuta upp gränsen till början av Monochrome Display Adapter (MDA). Ibland krävdes programvara eller en anpassad adressavkodare för att detta skulle fungera. Detta flyttade barriären till 704 KB (med MDA/HGC) eller 736 KB (med CGA).

Minneshanterare på 386-baserade system (som QEMM eller MEMMAX (+V) i DR-DOS ) skulle kunna uppnå samma effekt, lägga till konventionellt minne på 640 KB och flytta barriären till 704 KB (upp till segment B000, början av MDA/HGC) eller 736 KB (upp till segment B800, början av CGA). Endast CGA kunde användas i denna situation, eftersom enhanced Graphics Adapter (EGA) videominne var omedelbart intill det konventionella minnesområdet under 640 KB-linjen; samma minnesområde kunde inte användas både för bildrutebufferten på grafikkortet och för övergående program.

Alla datorers piggy-back add-on minneshanteringsenheter AllCard för XT- och Chargecard för 286/386SX-klassdatorer, såväl som MicroWays ECM (Extended Conventional Memory) tilläggsmodul gjorde att normalt minne kunde mappas in i A0000 -EFFFF ( hex ) adressintervall, vilket ger upp till 952 KB för DOS-program. Program som Lotus 1-2-3 , som fick direkt åtkomst till videominnet, behövde patchas för att hantera denna minneslayout. Därför togs 640 KB-barriären bort på bekostnad av hårdvarukompatibilitet.

Det var också möjligt att använda konsolomdirigering (antingen genom att ange en alternativ konsolenhet som AUX: när du först anropade COMMAND.COM eller genom att använda CTTY senare) för att rikta utdata till och ta emot indata från en dum terminal eller en annan dator som kör en terminalemulator . Förutsatt att system-BIOS fortfarande tillät maskinen att starta (vilket ofta är fallet åtminstone med BIOS för inbyggda datorer), kunde grafikkortet tas bort helt och systemet kunde ge totalt 960 KB kontinuerligt DOS-minne för program att ladda.

Liknande användning var möjlig på många DOS- men inte IBM-kompatibla datorer med en icke-fragmenterad minneslayout, till exempel SCP S-100-bussystem utrustade med deras 8086 CPU-kort CP-200B och upp till sexton SCP 110A-minneskort (med 64 KB RAM på var och en av dem) för totalt upp till 1024 KB (utan grafikkort, men med konsolomdirigering, och efter kartläggning av start/BIOS ROM), Victor 9000 / Sirius 1 som stödde upp till 896 KB , eller Apricot PC med mer kontinuerligt DOS-minne som ska användas under dess anpassade version av MS-DOS.

DOS-drivrutinsprogram och TSR:er

De flesta standardprogram skrivna för DOS behövde inte nödvändigtvis 640 KB eller mer minne. Istället kan drivrutiner och verktyg som hänvisas till som terminate-and-stay-resident-program ( TSR) användas utöver standard DOS-programvaran. Dessa drivrutiner och verktyg använde vanligtvis en del konventionellt minne permanent, vilket minskade det totala antalet tillgängliga för standard DOS-program.

Några mycket vanliga DOS-drivrutiner och TSR:er som använder konventionellt minne ingår:

  • ANSI.SYS - stöd för färgtext och olika textupplösningar
  • ASPIxDOS.SYS, ASPIDISK.SYS, ASPICD.SYS - alla måste vara laddade för att Adaptec SCSI- enheter och CDROM ska fungera
  • DOSKEY.EXE - tillåter återkallelse av tidigare inskrivna DOS-kommandon med uppåtpil
  • LSL.EXE, E100BODI.EXE (eller annan nätverksdrivrutin), IPXODI.EXE, NETX.EXE - alla måste laddas för åtkomst till NetWare -filserverns enhetsbeteckning
  • MOUSE.EXE - stöd för musenheter i DOS-program
  • MSCDEX.EXE - stöd för CDROM-enhetsåtkomst och enhetsbeteckning, används i kombination med en separat tillverkarspecifik drivrutin. Behövs utöver ovanstående SCSI-drivrutiner för åtkomst till en SCSI CDROM-enhet.
  • SBCONFIG.EXE - stöd för Sound Blaster 16 ljudenhet; en drivrutin med ett annat namn användes för olika andra ljudkort, som också upptar vanligt minne.
  • SMARTDRV.EXE - installera enhetscache för att påskynda diskläsning och skrivning; även om den kunde allokera flera megabyte minne utöver 640 kb för cachelagring av enheten, behövde den fortfarande en liten del av det konventionella minnet för att fungera.

Som kan ses ovan kan många av dessa drivrutiner och TSR:er anses praktiskt taget väsentliga för att systemet ska fungera med alla funktioner. Men i många fall måste ett val göras av datoranvändaren för att bestämma sig för att kunna köra vissa standard DOS-program eller ha alla sina favoritdrivrutiner och TSR:er inlästa. Att ladda hela listan som visas ovan är sannolikt antingen opraktisk eller omöjlig, om användaren också vill köra ett standard DOS-program.

I vissa fall skulle drivrutiner eller TSR:er behöva laddas ur från minnet för att köra vissa program och sedan laddas om efter att programmet körts. För drivrutiner som inte kunde laddas ur, inkluderade senare versioner av DOS en startmenyfunktion så att datoranvändaren kan välja olika grupper av drivrutiner och TSR:er som ska laddas innan de kör vissa DOS-program med hög minnesanvändning.

Övre minnesblock och hög laddning

När DOS-applikationer blev större och mer komplexa i slutet av 1980-talet och början av 1990-talet, blev det vanligt att frigöra konventionellt minne genom att flytta drivrutinerna och TSR-programmen till övre minnesblock (UMB) i övre minnesområdet (UMA) vid uppstart , för att maximera det konventionella minnet som är tillgängligt för applikationer. Detta hade fördelen av att inte kräva hårdvaruförändringar och bevarade programkompatibilitet.

Denna funktion tillhandahölls först av tredjepartsprodukter som QEMM , innan den byggdes in i DR DOS 5.0 1990 och sedan MS-DOS 5.0 1991. De flesta användare använde den medföljande EMM386 -drivrutinen i MS-DOS 5, men produkter från tredje part från företag som QEMM också visat sig populära.

Vid start kunde drivrutiner laddas högt med " DEVICEHIGH ="-direktivet, medan TSR:er kunde laddas högt med " LOADHIGH ", " LH " eller " HILOAD "-direktiven. Om operationen misslyckades skulle föraren eller TSR automatiskt laddas in i det vanliga konventionella minnet istället.

CONFIG.SYS , laddar ANSI.SYS till UMB, inget EMS-stöd aktiverat: 

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

AUTOEXEC.BAT , laddar MOUSE, DOSKEY och SMARTDRV till UMB om möjligt: 

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

Möjligheten hos DOS version 5.0 och senare att flytta sin egen systemkärnkod till det höga minnesområdet (HMA) genom kommandot DOS =HIGH gav ytterligare ett lyft för att frigöra minne.

Drivrutin/TSR-optimering

Hårdvaruexpansionskort kunde använda vilket som helst av det övre minnesområdet för ROM-adressering, så de övre minnesblocken var av varierande storlek och på olika platser för varje dator, beroende på den installerade hårdvaran. Vissa fönster i övre minnet kan vara stora och andra små. Att ladda drivrutiner och TSR högt skulle välja ett block och försöka passa in programmet i det, tills ett block hittades där det passade, eller så skulle det gå in i det konventionella minnet.

En ovanlig aspekt av drivrutiner och TSR:er är att de skulle använda olika mängder konventionellt och/eller övre minne, baserat på den ordning de laddades. Detta skulle med fördel kunna användas om programmen upprepade gånger laddades i olika ordningsföljder, och kontrollerade hur mycket minne som var ledigt efter varje permutation. Till exempel, om det fanns en 50 KB UMB och en 10 KB UMB, och program som behöver 8 KB och 45 KB laddades, kan de 8 KB gå in i 50 KB UMB, vilket hindrar den andra från att laddas. Senare versioner av DOS tillät användningen av en specifik laddningsadress för en drivrutin eller TSR, för att passa förare/TSR:er tätare ihop.

I MS-DOS 6.0 introducerade Microsoft MEMMAKER , som automatiserade denna process för blockmatchning, vilket matchade den funktionalitet som tredjepartsminneshanterare erbjöd . Denna automatiska optimering gav ofta fortfarande inte samma resultat som att göra det för hand, i betydelsen att ge det största lediga konventionella minnet.

Även i vissa fall skrev tredjepartsföretag speciella multifunktionsdrivrutiner som skulle kombinera kapaciteten hos flera vanliga DOS-drivrutiner och TSR:er till ett enda mycket kompakt program som använde bara några kilobyte minne. Till exempel skulle funktionerna för musdrivrutin, CD-ROM-drivrutin, ANSI-stöd, DOSKEY-kommandoåterställning och diskcache alla kombineras i ett program, och förbrukar bara 1 - 2 kilobyte konventionellt minne för normal åtkomst till drivrutiner/avbrott, och lagra resten av multifunktionsprogramkoden i EMS- eller XMS-minne.

DOS-förlängare

Barriären övervanns först med ankomsten av DOS-förlängare , som gjorde att DOS-applikationer kunde köras i 16-bitars eller 32-bitars skyddat läge , men dessa användes inte särskilt ofta utanför datorspel . Med en 32-bitars DOS-förlängare kan ett spel dra nytta av ett 32-bitars platt adressutrymme och hela 32-bitars instruktionsuppsättningen utan 66h/67h operand/adressöverskridande prefix. 32-bitars DOS-förlängare krävde kompilatorstöd (32-bitars kompilatorer) medan XMS och EMS fungerade med en gammal kompilator som var inriktad på 16-bitars real-mode DOS-applikationer. De två vanligaste specifikationerna för DOS-förlängare var VCPI - och senare DPMI -kompatibla med Windows 3.x.

Den mest anmärkningsvärda DPMI-kompatibla DOS-förlängaren kan vara DOS/4GW , levererad med Watcom . Det var väldigt vanligt i spel för DOS. Ett sådant spel skulle bestå av antingen en DOS/4GW 32-bitars kärna, eller en stubb som laddade en DOS/4GW kärna som finns i sökvägen eller i samma katalog och en 32-bitars "linjär körbar". Det finns verktyg tillgängliga som kan ta bort DOS/4GW från ett sådant program och låta användaren experimentera med någon av de flera, och kanske förbättrade, DOS/4GW-klonerna.

Innan DOS-förlängare, om en användare installerade ytterligare minne och ville använda det under DOS, måste de först installera och konfigurera drivrutiner för att stödja antingen utökad minnesspecifikation (EMS) eller utökad minnesspecifikation (XMS) och köra program som stöder en av dessa specifikationer.

EMS var en specifikation som var tillgänglig på alla datorer, inklusive de baserade på Intel 8086 och Intel 8088 , som gjorde det möjligt för tilläggshårdvara att söka små bitar av minne in och ut ( bankväxling ) av adresseringsutrymmet i "real mode" (0x0400– 0xFFFF). Detta gjorde det möjligt för 16-bitars real-mode DOS-program att komma åt flera megabyte RAM genom ett hål i det verkliga minnet, vanligtvis (0xE000–0xEFFF). Ett program måste då uttryckligen begära åtkomst till sidan innan det används. Dessa minnesplatser kan sedan användas godtyckligt tills de ersätts av en annan sida. Detta är mycket likt modernt sökt virtuellt minne . Men i ett virtuellt minnessystem hanterar operativsystemet alla personsökningsoperationer , medan personsökning var explicit med EMS.

XMS tillhandahöll ett grundläggande protokoll som gjorde det möjligt för ett 16-bitars DOS-program att ladda bitar av 80286 eller 80386 utökat minne i lågt minne (adress 0x0400-0xFFFF). En typisk XMS-drivrutin var tvungen att byta till skyddat läge för att ladda detta minne. Problemet med detta tillvägagångssätt är att i 286 skyddat läge kunde direkta DOS-anrop inte göras. Lösningen var att implementera en återuppringningsmekanism, som kräver en återställning av 286:an. På 286:an var detta ett stort problem. Intel 80386 , som introducerade " virtuellt 8086-läge ", tillät gästkärnan att emulera 8086:an och köra värdoperativsystemet utan att faktiskt tvinga processorn tillbaka till "riktigt läge". HIMEM.SYS 2.03 och högre använde overkligt läge på 80386 och högre processorer medan HIMEM.SYS 2.06 och högre använde LOADALL för att ändra odokumenterade interna register på 80286, vilket avsevärt förbättrade avbrottslatens genom att undvika upprepade växlar i realläge/skyddat läge.

Windows installerar sin egen version av HIMEM.SYS på DOS 3.3 och högre. Windows HIMEM.SYS lanserar 32-bitars skyddat läge XMS (n).0-tjänsteleverantör för Windows Virtual Machine Manager, som sedan tillhandahåller XMS (n-1.0-tjänster till DOS-boxar och 16-bitars Windows-maskinen (t.ex. DOS) 7 HIMEM.SYS är XMS 3.0 men att köra 'MEM'-kommandot i ett Windows 95 DOS-fönster visar XMS 2.0-information).

Se även

Vidare läsning

Hämtad från " https://en.wikipedia.org/w/index.php?title=Conventional_memory&oldid=1135253308 "