[comp.arch] 386 demand paged virtual memory

jallen@netxcom.UUCP (John Allen) (09/01/87)

In article <299@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
>	I saw an add that indicated that the V/386 product
>	supported "demand paged virtual memory".  I this
>	true, or have they come up with an obscure new
>	meaning for those words?  I didn't think the 386
>	had the hardware for real demand paging, am I wrong?

The 386 processor has:

64 terabytes of virtual address space,
A page fault interrupt (14),
and
A restartable instruction set (two avoidable exceptions).

What else would one need?


John Allen
=========================================================================
NetExpress Communications, Inc.      seismo!{sundc|hadron}!netxcom!jallen
1953 Gallows Road, Suite 300         (703) 749-2238
Vienna, Va., 22180
=========================================================================

jru@etn-rad.UUCP (John Unekis) (09/03/87)

In article <358@netxcom.UUCP> jallen@netxcom.UUCP (John Allen) writes:
>In article <299@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
>>	I saw an add that indicated that the V/386 product
>>	supported "demand paged virtual memory".  I this
>>	true, or have they come up with an obscure new
>>	meaning for those words?  I didn't think the 386
>>	had the hardware for real demand paging, am I wrong?
>
>The 386 processor has:
>
>64 terabytes of virtual address space,
>A page fault interrupt (14),
>and
>A restartable instruction set (two avoidable exceptions).
>
>What else would one need?

What else ?  How about an algorithm to timestamp the segments in the 
page list to determine the oldest ones for swapping to disk, to lock pages
in memory during I/O, to perform the disk I/O to a core image on a swap 
volume, to assign variable swapping priorities to pages to keep kernal
routines from swapping out and causing thrashing, etc., etc., etc.

When they say that the 80386 "supports demand paged virtual memory", what 
they mean is that since your operating system will have to manage tasks
as a group of segments in memory anyway, why not make the segments a small
fixed size and call them pages instead. Your operating system will still
be doing all the work, but using segments to represent virtual pages 
makes it look like intel had a reason for preserving segmentation beyond
continued compatibility with the 8086.

---------------------------------------------------------------
disclaimer: I was acting under orders from Ollie.

bobr@zeus.TEK.COM (Robert Reed) (09/04/87)

In article <268@etn-rad.UUCP> jru@etn-rad.UUCP (0000-John Unekis) writes:
	In article <358@netxcom.UUCP> jallen@netxcom.UUCP (John Allen) writes:

	What else would one need?

    When they say that the 80386 "supports demand paged virtual memory",
    what they mean is that since your operating system will have to manage
    tasks as a group of segments in memory anyway, why not make the segments
    a small fixed size and call them pages instead.

However, the 386 has both segment tables and page tables, which, in addition
to the previously mentioned features, does provide for real demand paged
virtual memory.  You can run with a segmented architecture or a
paged-segmented architecture, or just a paged architecture, all using a 386.
-- 
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK

steve@nuchat.UUCP (Steve Nuchia) (09/04/87)

In article <358@netxcom.UUCP>, jallen@netxcom.UUCP (John Allen) writes:
> In article <299@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
> >	meaning for those words?  I didn't think the 386
> >	had the hardware for real demand paging, am I wrong?
> 
> The 386 processor has:
> 
> 64 terabytes of virtual address space,
> A page fault interrupt (14),
> and
> A restartable instruction set (two avoidable exceptions).
> 
> What else would one need?

Several people sent me lots of good info by mail, for which I am
grateful.  I really should keep up with such things, but there is
so much to read and so little time....

In addition to the things you list, one needs a virtual-to-physical
address translation mechanism.  If this had been required to be off-chip,
as I had though it was, we could expect the mass market (affordable)
386 products to leave it off.

The answers, for anyone still curious, are that the 386 does include,
in addition to the above, a small-ish page table cache which hardware
keeps track of using a ram-resident page table/process descriptor
type thing.  I don't know much of the detail, but I do know that
the bare chip has sufficient (specified) capability for real demand
paging.

I also found out that microport is _still_ not shipping unix
for the 386.   *sigh*

	Steve Nuchia
-- 
Steve Nuchia			Of course I'm respectable!  I'm old!
{soma,academ}!uhnix1		Politicians, ugly buildings, and whores
!nuchat!steve			all get respectable if they last long enough.
(713) 334 6720				- John Huston, Chinatown

jallen@netxcom.UUCP (John Allen) (09/05/87)

In article <268@etn-rad.UUCP> jru@etn-rad.UUCP (0000-John Unekis) writes:
>When they say that the 80386 "supports demand paged virtual memory", what 
>they mean is that since your operating system will have to manage tasks
>as a group of segments in memory anyway, why not make the segments a small
>fixed size and call them pages instead. Your operating system will still
>be doing all the work, but using segments to represent virtual pages 
>makes it look like intel had a reason for preserving segmentation beyond
>continued compatibility with the 8086.

This is incorrect and misleading.  A segment and a page a two very different
things.  The 386 will allow any number of pages within a segment which can
be up to 4 Gigabytes in length.  The paging mechanism is not dependent upon
the segmented architecture.

John Allen
=========================================================================
NetExpress Communications, Inc.      seismo!{sundc|hadron}!netxcom!jallen
1953 Gallows Road, Suite 300         (703) 749-2238
Vienna, Va., 22180
=========================================================================

root@hobbes.UUCP (John Plocher) (09/13/87)

+---- steve@nuchat.UUCP (Steve Nuchia) writes in <306@nuchat.UUCP> ----
| I also found out that microport is _still_ not shipping unix
| for the 386.   *sigh*
| 
| 	Steve Nuchia
+----

Bell Technologies (800/FOR-UNIX, 415/659-9097) says they ARE shipping!
I have device drivers for their tape and smart serial boards which are 
marked for Unix Vr3/386!

	-John

-- 
John Plocher uwvax!geowhiz!uwspan!plocher  plocher%uwspan.UUCP@uwvax.CS.WISC.EDU