rcd@ico.ISC.COM (Dick Dunn) (03/28/89)
jfh@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.