Swapping

Swapping

[Tommy McCabe]

Swapping, in theory, is actually quite simple. The
memory is borken up into fixed-size pages, or
segments, or whatever you want to call them. Instead
of each program accessing the memory directly, as in
DOS, each program interfaces with a virtual kernel
memory. When a page enters the virtual kernel memory,
the kernel puts it somewhere in the hardware memory.
Because of this interface layer, pages can be wherever
they want in the hardware, but all the program sees is
the virtual address. Also, the virtual memory can be a
lot larger than the hardware memory. So, if the
hardware memory is almost all used, and a program
enters a page in virtual memory, the kernel can put
that page on the hard disk instead of in RAM, and when
the program uses that virtual address, the kernel
fetches the data from the hard drive, and the program
never sees it because the kernel does all the
switching and fetching. An opposite, but harder idea,
is caching- when a file is loaded from the hard disk,
its allocated space in virtual memory, which is
allocated space in real memory, so that the data can
be accessed faster.


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Swapping

[Alan Cox]

On Mer, 2004-05-26 at 23:45, Tommy McCabe wrote:
> Swapping, in theory, is actually quite simple. The
> memory is borken up into fixed-size pages, or
> segments, or whatever you want to call them. Instead

That is paging in conventional terminology. Actually to be 
honest there are two divides here and even the PDP-11 used
elements of both

Firstly older processors could not restart a faulting instruction
perfectly. Eg if you did

	"move block of 32 bytes from x to y"

you didn't know how much was copied when it faulted. Worse still 
instructions that did the post increment/decrement might or might
not have changed the values. The 8086 is in this category, the 80286
is [with sufficient care] not.

Many systems that did have paging hardware but this limit used the 
paging hardware for memory defragmentation only. It was necessary to
load all of a program into memory to run it, as it couldn't be allowed
to fault (because the fault could not be recovered)

The other difference is by fixed v variable size). Paging traditionally
means fixed size blocks and not loading all the program into memory at
once. Works a treat on a 386, not useful on a 286. In the 286 world
instead you have to work with variable sized segments being written to
or from disk, but you could in 286PM but not on 8086 load only some
segments into memory and load others on the fault.

Re: Swapping

[Gábor Lénárt]

Re,

On Thu, May 27, 2004 at 07:45:07PM +0100, Alan Cox wrote:
> Firstly older processors could not restart a faulting instruction
> perfectly. Eg if you did
> 
> 	"move block of 32 bytes from x to y"
> 
> you didn't know how much was copied when it faulted. Worse still 
> instructions that did the post increment/decrement might or might
> not have changed the values. The 8086 is in this category, the 80286
> is [with sufficient care] not.

I don't understand this.

mov  cx,32
push ds
pop  es
mov  si,0x100
mov  di,0x200
rep  movsb

This code (in intel asm syntax) copies 32 bytes from offset 0x100 to
0x200 withing the data segment. If you interrupt rep prefixed movsb
register cx should inform you the state of the prefixed movsb.

Or simply I've ignored something :)

> The other difference is by fixed v variable size). Paging traditionally
> means fixed size blocks and not loading all the program into memory at
> once. Works a treat on a 386, not useful on a 286. In the 286 world
> instead you have to work with variable sized segments being written to
> or from disk, but you could in 286PM but not on 8086 load only some
> segments into memory and load others on the fault.

Also it's important to declare here than on 386, paging and segmenting
works in parallel (if you enable paging of course). On 286 you have got
only segmenting but you have got special meaning of segment registers in
protected mode ie conatining selectors which are "only" indices inside a
desciptor table. Segmenting is similar in 386 protected mode but there
you have the possibility to use page granulity instead of bytes, so instead
of maximum of 64K segment size, you can use maximum segment size 4G. Since
paging and segmenting can works in parallel most modern OSes (like Linux)
uses "flat" addressing mode, ie setting segment sizes to 4G, and let paging
do the hw level protecting and other related stuffs on per page basis.

And another interesting things for 386 is the so called 'flat real
addressing mode). It's an ugly trick and only works in real mode so not
in virtual 8086 mode. You can change into 32 bit protected mode on 386,
and you can build a descriptor table with using 4G wide segment limits.
Now you can load selectors into the segment registers. And NOW. If you
switch back into real mode, size of the segments are 4G (!) instead of 64K,
though meaning of segment IDs reamins the "real mode" constructs, so 
segid*16=real_addr. This addressing mode is used by some old scene demos.
However I don't know exactly if it's a bug or feature :) as far as I can
remember it's because CPU has got a "cache" for eg segment limits to avoid
to load from descriptor table each time, and since 4G limit is loaded,
this limit is used in real mode too after switching back into real mode.

However, Alan, please correct me if I'm wrong somewhere.

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Swapping

[Tommy McCabe]

--- Gábor Lénárt <lgb@lgb.hu> wrote:
> Re,
> 
> On Thu, May 27, 2004 at 07:45:07PM +0100, Alan Cox
> wrote:
> > Firstly older processors could not restart a
> faulting instruction
> > perfectly. Eg if you did
> > 
> > 	"move block of 32 bytes from x to y"
> > 
> > you didn't know how much was copied when it
> faulted. Worse still 
> > instructions that did the post increment/decrement
> might or might
> > not have changed the values. The 8086 is in this
> category, the 80286
> > is [with sufficient care] not.

I think he means "on the 8086, if you're copying X
bytes from A to B, and there's some error, you can't
tell how much of it has been copied".

> I don't understand this.
> 
> mov  cx,32
> push ds
> pop  es
> mov  si,0x100
> mov  di,0x200
> rep  movsb
> 
> This code (in intel asm syntax) copies 32 bytes from
> offset 0x100 to
> 0x200 withing the data segment. If you interrupt rep
> prefixed movsb
> register cx should inform you the state of the
> prefixed movsb.
> 
> Or simply I've ignored something :)
> 
> > The other difference is by fixed v variable size).
> Paging traditionally
> > means fixed size blocks and not loading all the
> program into memory at
> > once. Works a treat on a 386, not useful on a 286.
> In the 286 world
> > instead you have to work with variable sized
> segments being written to
> > or from disk, but you could in 286PM but not on
> 8086 load only some
> > segments into memory and load others on the fault.
> 
> Also it's important to declare here than on 386,
> paging and segmenting
> works in parallel (if you enable paging of course).
> On 286 you have got
> only segmenting but you have got special meaning of
> segment registers in
> protected mode ie conatining selectors which are
> "only" indices inside a
> desciptor table. Segmenting is similar in 386
> protected mode but there
> you have the possibility to use page granulity
> instead of bytes, so instead
> of maximum of 64K segment size, you can use maximum
> segment size 4G. Since
> paging and segmenting can works in parallel most
> modern OSes (like Linux)
> uses "flat" addressing mode, ie setting segment
> sizes to 4G, and let paging
> do the hw level protecting and other related stuffs
> on per page basis.
> 
> And another interesting things for 386 is the so
> called 'flat real
> addressing mode). It's an ugly trick and only works
> in real mode so not
> in virtual 8086 mode. You can change into 32 bit
> protected mode on 386,
> and you can build a descriptor table with using 4G
> wide segment limits.
> Now you can load selectors into the segment
> registers. And NOW. If you
> switch back into real mode, size of the segments are
> 4G (!) instead of 64K,
> though meaning of segment IDs reamins the "real
> mode" constructs, so 
> segid*16=real_addr. This addressing mode is used by
> some old scene demos.
> However I don't know exactly if it's a bug or
> feature :) as far as I can
> remember it's because CPU has got a "cache" for eg
> segment limits to avoid
> to load from descriptor table each time, and since
> 4G limit is loaded,
> this limit is used in real mode too after switching
> back into real mode.
> 
> However, Alan, please correct me if I'm wrong
> somewhere.
> 
> - Gábor (larta'H)
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
http://vger.kernel.org/majordomo-info.html



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Swapping

[Gábor Lénárt]

On Fri, May 28, 2004 at 07:56:10AM -0700, Tommy McCabe wrote:
> > > instructions that did the post increment/decrement
> > might or might
> > > not have changed the values. The 8086 is in this
> > category, the 80286
> > > is [with sufficient care] not.
> 
> I think he means "on the 8086, if you're copying X
> bytes from A to B, and there's some error, you can't
> tell how much of it has been copied".

I see, and maybe I haven't got enough knowledge on this, but the example
I've shown below uses "rep movsb" to move bytes by bytes. If you interrupt
this, you can examine register CX to check the copy process.

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Swapping

[Alan Cox]

On Gwe, 2004-05-28 at 08:52, Gábor Lénárt wrote:

> mov  cx,32
> push ds
> pop  es
> mov  si,0x100
> mov  di,0x200
> rep  movsb
> 
> This code (in intel asm syntax) copies 32 bytes from offset 0x100 to
> 0x200 withing the data segment. If you interrupt rep prefixed movsb
> register cx should inform you the state of the prefixed movsb.

So you get an exception in the rep movsb - how many bytes were copied ?
Did the fault occur before or after the increment ? This kind of 
question.



-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Swapping

[Gábor Lénárt]

On Thu, Jun 03, 2004 at 11:36:59PM +0100, Alan Cox wrote:
> On Gwe, 2004-05-28 at 08:52, Gábor Lénárt wrote:
> 
> > mov  cx,32
> > push ds
> > pop  es
> > mov  si,0x100
> > mov  di,0x200
> > rep  movsb
> > 
> > This code (in intel asm syntax) copies 32 bytes from offset 0x100 to
> > 0x200 withing the data segment. If you interrupt rep prefixed movsb
> > register cx should inform you the state of the prefixed movsb.
> 
> So you get an exception in the rep movsb - how many bytes were copied ?
> Did the fault occur before or after the increment ? This kind of 
> question.

But you can check content of register CX after rep movsb.
However it seems I've misunderstand your point, sorry.

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html