Message-Id: <199701020047.BAA03506@math.amu.edu.pl> Comments: Authenticated sender is From: "Mark Habersack" Organization: Home, sweet home (Poznan, Poland) To: alaric AT abwillms DOT demon DOT co DOT uk (Alaric B. Williams), djgpp AT delorie DOT com Date: Thu, 2 Jan 1997 01:46:04 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: DPMI incorporation... Reply-to: grendel AT ananke DOT amu DOT edu DOT pl Once upon a time (on 1 Jan 97 at 0:17) Alaric B. Williams said: > "Mark Habersack" wrote: > > >1. in i386 Intel introduced a new level of indirection in memory > >addressing - paging. Memory in i386 can be divided into units as > >small as 4KB (PAGES) while in iAPX286 the smallest swappable (in > >virtual memory sense) was a SEGMENT (64KB). > > That's not quite getting the point, Mark. The 286 segments were > limited to a maximum size of 64Kb, but could be any size. The idea > was that you swapped things in and out at a high level; whole DLLs > and things like that lived in individual segments. The 386 flat > address space just arbitarily carves itself into 4k bits for > management, they don't mean anything structurally. What I mean is that 286-based virtual memory manager was somehow forced to swap data between memory and disk in 64KB chunks. It was, of course, possible to exchange exactly that many bytes the given segment contained, but the overhead involved was unacceptable. The overhead was related to the different sizes of the segment sin question. If the VMM were to pay attention to the sizes, it'd have to maintain some structure (probably sort of FAT) to find segments in the swapfile. Even though searching through the structure wouldn't be that time consuming, the operations involved in rearranging data layout inside of the swapfile would be unacceptable. Imagine such a situation: Swapfile MAP TABLE . Segments storage area start . Segment 0 START (size 34768B) Segment 0 END . Segment 1 START (size 14586B) Segment 1 END . Segment 2 START (size 60000B) Segment 2 END Now, let's assume an application needs Segment back in the memory. Further on, let's assume that VMM has store another segment in the swapfile. First VMM swaps out the segment from the memory to disk (say, the segment is 5000B long and lies between two other ones): it allocates some new space at the end of swapfile and stores there our segment. So far, so good. But a hole of 5000B appeared in RAM. What to do? VMM has to shuffle (compact) the segments in memory to minimize fragmentation. It does some magic and when done allocates a new segment in memory, reads Segment 1 from disk and puts it in memory. But now we have another hole, this time on disk. As the disks are slow, VMM may chose not to rearrange segments stored on the HDD. But this is straight way to grow the swapfile so that it eats entire disk space. This cannot be allowed. So VMM rearranges the swapfile from time to time - very wasteful operation. Solution? Make all the segments one size - no matter how many data they really contain (of course VMM has to store some information about how many bytes are needed from a given segment). It cures one problem - there's no disk-shuffling anymore. But the problem of memory fragmentation stays on. Introduction of 4KB pages in i386 solved all these problems at once. Together with page table directiories and page tables, the mechanism enables VMM to exchange only 4KB at the time and place anywhere it wants. Fast, clean and safe. And the User/Supervisor bit in page tables allows for much safer protection of memory than just putting segments' descriptors in GDT/LDT - smart programmer may circumvent the protection. And with the introduction of the U/S bit (even more strenghtened in i486) it is virtually not possible. > >3. Additional segment registers (fs, gs) > > I've never figured out why :-) Neither did I ;-)) Maybe they are here just in case when a program needs to maintain several segments (and since segment register loading is a costly operation, it's good to have some spare registers). Also remember that the Flat model is not the only one possible in protected mode (truly, it shouldn't be uses 'cause it's very easy to modify code segments in that model - and that was one of the goals behind the PM to protect code segments against modification). > Still, it's interesting that Intel have given names to registers > that are clearly alphabetically named, yet those names reflect their > instruction-set biases: [snip] > GS = global data segment I think it has some historical meaning. Some of you probably remember that on the 8-bit Intel processors (also on Zilog's) registers were named A,B,C. > What about AS and BS? :-) ;-)) --------------------------------------------------------------------- Midnight sun bids moors farewell, retreats from charging dusk, Mountains echo, curfews bell, signal ending tasks. They place their faith in oaken doors, cover in candle light The panic seeps through bloodstained floors as Grendel stalks the night ---- Visit http://ananke.amu.edu.pl/~grendel