Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!pt!vi.ri.cmu.edu!jfb
From: jfb@vi.ri.cmu.edu (John Brennen)
Newsgroups: comp.sys.ibm.pc
Subject: 386 rumors, questions, and comments
Message-ID: <1014@vi.ri.cmu.edu>
Date: Wed, 12-Aug-87 16:25:08 EDT
Article-I.D.: vi.1014
Posted: Wed Aug 12 16:25:08 1987
Date-Received: Sat, 15-Aug-87 02:41:19 EDT
Organization: Carnegie-Mellon University, CS/RI
Lines: 33
Keywords: protection sun machine

First, someone posted saying that a user-level task can bring down a 386
machine.  How?  Assuming the user has one readable code segment and one
readable data segment, neither of which contains system data; further,
the GDT, IDT, and paging directories are protected...now, what's the
trick that subverts the protection (also, assume that the O/S attempts
no error recovery, but terminates the executing task on any violation).

Second, I have heard that Sun is planning a 386-based machine.  If this
is true, it says something interesting:  that someone with no financial
interest in Intel and a considerable investment in Motorola has chosen
an Intel part.  Sun certainly isn't turning its back on Motorola, but
broadening one's horizons never hurt anyone.

I've written multitaskers for both the 80xxx family and the 68xxx family,
and I'll admit that the 68xxx program was cleaner and easier to write.
The problem is that a UN*X primitive like fork() is difficult to implement
because pointers in the parent and child point to the same object.  In my
80xxx version, **because of segmentation**, the pointers do what they
are supposed to.  Using register-based addressing is the only consistent
solution for the 68000, and is (in my opinion) unacceptable.  The other
"solution" (a 68020 with MMU) was unacceptable at the time, and restricts
the use of the program, while the 80xxx version will run identically on
anything from an 8088 to an 80386 (32-bit registers and all).

Sorry to ramble on without any serious flaming (:-), but to tell the truth,
I've been programming these two processor families for over two years, and
still haven't made up my mind.  Flames to /dev/null, constructive comments
are welcome.

John Brennen
jfb@vi.ri.cmu.edu
Visual Inspection Lab
Carnegie Mellon U.