NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/os/coherent/3374

Internet Message Format | 1992-07-31 | 3.8 KB

Xref: sparky comp.os.coherent:3374 comp.os.minix:4088
Newsgroups: comp.os.coherent,comp.os.minix
Subject: Re: OS compare (Unix/clone)
Path: sparky!uunet!think.com!unixland!rmkhome!rmk
From: [e-mail] (Rick Kelly)
Organization: The Man With Ten Cats
Date: Fri, 31 Jul 1992 12:39:47 GMT
Reply-To: [e-mail] (Rick Kelly)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 69

In article <[e-mail]> [e-mail] (Linus Benedict Torvalds) writes:
>In article <[e-mail]> [e-mail] (Petri Virkkula) writes:
>>
>>    Haven't I understood something correctly? Isn't it possible to
>>    swap segments to disk using Valid and Accessed flags in
>>    segment descriptors?
>
>Yes, it's certainly possible, but it's also almost never worth the
>bother: it's slow, hard to program, and writing a C-compiler (and
>probably any other language) to understand several segments while still
>being efficient is pretty hard.  And having just one code-segment and
>one data (and stack) segment is simply not enough for a lot of
>interesting applications.

Didn't XENIX for the 286 use large model code?  It seems to me that
they implemented demand paging, but they may have stuck to process
swapping.  It's been years since I used it.

>Having several different code/date-segments doesn't lend itself very
>well to high-level languages (it doesn't even work too well in assembly,
>but there the programmer often knows what he/she is doing).  Thus
>coherent 3.2 and minix don't even try: they keep to one segment, and
>limit all data to 64kB.  You can do a lot in 64kB, but I'd rather miss
>the experience.

Of course, Coherent 3.x only had this limit on Intel processors.  Previous
versions of Coherent ran on 68xxx and Z8000 processors.

One thing that made V7 UNIX successful on the PDP-11 was overlays.  The
original UNIX version of EMACS was 300k, but used in-memory overlays to
swap parts of the program in and out.

Coherent 3.x came with a series of routines to allow a program to set
up virtual devices for large amounts of data.

>OS/2 1.x tried to implement a "real" system on a 286, and while some
>people think it worked well, most people (including the OS/2 2.0
>designers) seem to agree that the 286 protected mode memory management
>is simply not enough for any good real system.  Of course, you can still
>use them for DOS or some other embedded system (a toaster, washing
>machine etc).

It's easy to be condescending towards the 286, but that is where UNIX
on Intel boxes started.  Try Xenix and Venix as just two examples of
AT&T UNIX source code running on the 286.  Without the 286 ports to
prove the viability and popularity of UNIX on AT boxes, they may have
never ported UNIX to the 386.

>That doesn't mean the 386 is perfect: it has got it's own number of
>idiocyncracies (especially when used in AT hardware).  But at least you
>don't have to fight the hardware all the way if you want to do something
>bigger on a 386.

Judging by what Intel has done with the 386 and 486 in parallel computers,
they seem to be excellent processors that have been unfortunately hampered
by an aging hardware design ( the AT ).

>PS.  "Being able to" and "suitable for" are totally different things:
>you can write a fully multitasking VM system with 32-bit pointers on a
>Z80 (for example by writing a 386 (or why not a cray-XMP?) emulator on
>it), and all general-purpose processors are theoretically able to solve
>the same set of problems.  Thus even a lowly 286 can provably do the
>same things a 386 does.  It's just not worth it in most cases.

The Cray XMP does not do demand paging.

--

Rick Kelly    [e-mail]    unixland!rmkhome!rmk    [e-mail]