processor problems...or just ugliness?

[Dick Dunn]

jfh at rpp386.Dallas.TX.US (John F. Haugh II) wrote a flame about the 286.
First item of note is that he directed followups to "junk".  I don't get
it; was he afraid that someone might try to post a substantive response?

> The 80286 does have problems.

Meaning what?  That it's uglier than last week's roadkill?  Perhaps so,
but:

>...I doubt that a fully functional and
> robust operating system for an 80286 can ever be had...

There are existence proofs to the contrary.  Even the Microport system,
which has some long-standing bugs, *could* be fixed...people are frustrated
with the bugs in the Microport AT stuff precisely because they know they
can be fixed.  There is nothing that I know of in the 286 architecture
which prevents one from constructing, say, a correct implementation of
UNIX in which processes are completely protected from one another as they
should be, and in which the kernel is protected from processes such that
no process could cause a kernel panic.

If anyone has any concrete, substantive reason that a 286 cannot support a
correct, robust operating system, I'd like to know what it is.  What I'm
looking for is, for example, a way that a program in user mode can cause an
exception that the kernel can't defend against.  Let's even include the
usual support chips for the 286 since (a) it doesn't have any useful
interrupt control on-chip, and (b) the 286, as ugly as it is, is actually
rather pleasant next to the cascaded pair of 8259's normally used with it.

I'm not much swayed by an argument like:

>...The chip is brain dead and a waste of good silicon...

since it's a content-free statement, and:

>...Various modes of failure
> cause the program to be completely aborted, and if that program
> happens to be your operating system, tough luck.

amounts to nothing since the same is true of "various modes of failure" on
most processors.  Try things like a bad kernel stack pointer, nonexistent
address for load/store, etc., and see what it does to a 680x0, a VAX, a
PDP-11...

> ...Others of us are disgusted with bogus hardware.
> The 80286 is such an example of a total loser implemented on silicon.

No, it's not a total loser.  That's nonsense.  It IS an unpleasant
processor in many ways.  I won't defend the architecture, but just because
it's ugly doesn't mean it's not usable.

In fact, if you get in to the real details of most processors, you'll find
that there are lots of warts.  A very few processors are exceptionally
clean in design, like the PDP-11...but even there if you go looking at the
Unibus map or the memory protection, you'll find things are more ornate
than you might like.  Of course, the PDP-11 is probably two orders of
magnitude  (?quantitative subjectivity?:-) cleaner than the 286, BUT the
286 is still usable.  It works (or at least if it doesn't, nobody has
posted a reason yet).

The 286 has a rather baroque memory protection scheme, but at least it has
one.  Contrast with the 680x0, which didn't have either an internal MMU or
any accepted external MMU for years.  That made it impossible to produce a
UNIX port "for the processor" since the port depended on box-specific
memory management.

If you have a chance to influence architecture, it's great to complain
about all the things that make an operating system ugly or slow...but if
the hardware already exists, you need to take a different tack:  See if
everything you need to do is *possible* (note: NOT easy or clean, just
possible)...then get down to it.

Let me try to keep my views in perspective:  I've done OS-level work on the
286, and believe me, I complained about the architecture all along.  It was
often painful to do things, but it was possible and the result was usable.
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...Never offend with style when you can offend with substance.