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
henderso@uoregon.UUCP (Mark C. Henderson) (09/14/87)
In article <216@hobbes.UUCP> root@hobbes.UUCP (John Plocher) writes:
#+---- 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
Does anybody know what software Bell is shipping with their 386 unix? I
will not consider it UNIX unless it has a C compiler, nroff, and all
these other goodies. Does Bell have the full set of utilities available? Any
information would be appreciated.
Mark Henderson
--
Mark C. Henderson
Dept. of Mathematics, University of Oregon, Eugene, OR 97403-1222
Tel: 503-342-1896 (H) 503-686-4743 (W)
CSNet: henderso@mist.uoregon.edu OR henderso@uoregon.csnet
UUCP: {allegra,cae780,cbosgd,decvax,gatech,hplabs,ihnp4,ucbvax,
watmath,uw-beaver}!tektronix!uoregon!henderso
{seismo!cmcl2,decwrl!microsoft,hplabs}!hp-pcd!uoregon
bellcore!ogcvax!uoregon!henderso
root@hobbes.UUCP (John Plocher) (09/19/87)
+---- Mark C. Henderson writes in <638@uoregon.UUCP> ---- | +---- I wrote | | 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! | +---- | Does anybody know what software Bell is shipping with their 386 unix? I | will not consider it UNIX unless it has a C compiler, nroff, and all | these other goodies. Does Bell have the full set of utilities available? Any | information would be appreciated. +---- 1) For the $395 price ($99 in large quantity) you get: AT&T SVr3 standard distribution Unix Software development system (C compiler... ) 7 Manuals - Includes the complete P-H Unix series + '386 implementation notes. You DO NOT GET: FORTRAN compiler DWB (ditroff...) "AT&T does not have it ported yet and so has unbundled it" STREAMS support (also unbundled) 2) You need: Compaq 386 or iNTEL 386 Motherboard based system (or .?.) (Does not work well with PCsLTD 386 and MultiTech 386) AT LEAST 2Mb of contiguous 32bit RAM An iNTEL EE-80386 chip (i.e., a new one without the infamous 32 bit multiply bug) 3) Exelan, Lachman, et al have ethernet TCP/IP support products **** I don't have this product, I dont have any ties to Bell other than using their tape and ICC hardware, and I suggest calling the 800 number (above) if you have more questions. -- John Plocher uwvax!geowhiz!uwspan!plocher plocher%uwspan.UUCP@uwvax.CS.WISC.EDU