[comp.unix.microport] Ridiculous

vandys@hpindda.HP.COM (Andy Valencia) (05/23/88)

/ hpindda:comp.unix.microport / bill@carpet.WLK.COM (Bill Kennedy) /  8:58 am  May 22, 1988 /
In article <1086@maynard.BSW.COM> campbell@maynard.BSW.COM (Larry Campbell) writes:
>The 80286 is pitifully
>slow in its interrupt response, all of them, all speeds.
	So why does SCO XENIX do so much better?  Same chip....

					Andy Valencia

vandys@hpindda.HP.COM (Andy Valencia) (06/01/88)

/ hpindda:comp.unix.microport / bill@carpet.WLK.COM (Bill Kennedy) / 11:14 pm  May 29, 1988 /
In article <670@igloo.UUCP> learn@igloo.UUCP (william vajk) writes:
>>In article <70@carpet.WLK.COM>, I wrote:
>>
>>> Just like you marvel that the '286 can run UNIX at all... 
>>
>>Is that the problem. The 286 was never intended to run unix at all ?
>>I suppose that's why xenix works just fine.

    Eh?  Current SCO XENIX is a port of System-V.  I'm told that it
isn't called UNIX simply for legal reasons.

...
>I didn't want anyone to think I'm cozy with them.  Read the 286 data
>sheets, read some more about the UNIX kernel, marvel that V/AT works at
>all!  Now that *IS* to Microport's credit, Hickey and company made it
>work.

    I've read quite a bit about both, plus about the PDP-11, and I'm puzzled.  
The PDP-11 certainly ran UNIX (:->), and the '286 is in the same ballpark.
Which feature of the '286 is so incompatible with UNIX?

					Andy

daveb@laidbak.UUCP (Dave Burton) (06/02/88)

In article <7030015@hpindda.HP.COM> vandys@hpindda.HP.COM (Andy Valencia) writes:
|Which feature of the '286 is so incompatible with UNIX?

"Intel". :-) :-) :-)

bill@carpet.UUCP (06/03/88)

This was mailed but got coughed back by the mail gods.  It's short
enough to post and on second reading appears to be pertinent to the
discussion.

550 hpindda.HP.COM!vandys... User unknown
>    Eh?  Current SCO XENIX is a port of System-V.  I'm told that it
>isn't called UNIX simply for legal reasons.

I can promise you that is just not so.  SCO assures me that they will
be closer to it in the next major release but the current offering is
a very schizophrenic mixture of VII and V.  I don't know about their
286 version but I have and use the 386 Vr2.2.3 and the differences
are confusing and often infuriating.  I can cite you some examples but
I don't think that was what you were referring to.  You are certainly
correct that there are some legal issues that separate them too.  The
binary license arrangements are very different and the more relaxed
details were a direct result of not using the UNIX name.

>...
>
>    I've read quite a bit about both, plus about the PDP-11, and I'm puzzled. 
>The PDP-11 certainly ran UNIX (:->), and the '286 is in the same ballpark.
>Which feature of the '286 is so incompatible with UNIX?
>
>					Andy

In particular the processor overhead needed to handle character by
character interrupts.  Not to belabor the point but most machines
can go do what they need implicitly from the interrupt itself, modified
perhaps by the hardware interrupt controller.  The 286 must navigate
through an interrupt descriptor table, possibly switch between real and
protected mode, and in most implementations, compete for the bus with
memory refresh.  The various techniques developed to overcome that
are easily cancelled by a careless driver writer who only services one
character at a time.  This becomes more aggravated at baud rates above
9600 as character time approaches DRAM refresh time.

Thank you for posting the follow up.  I certainly wasn't typing what
I was thinking or it would have been much clearer.  The burden of
communications is, after all, on the communicaTOR and your (and others)
followup shows I didn't do very well.
-- 
Bill Kennedy  Internet:  bill@ssbn.WLK.COM
                Usenet:  { killer | att-cb | ihnp4!tness7 }!ssbn!bill

vandys@hpindda.HP.COM (Andy Valencia) (06/08/88)

/ hpindda:comp.unix.microport / bill@carpet.WLK.COM (Bill Kennedy) / 10:52 pm  Jun  6, 1988 /
>...  The key
>difference is that Xenix is not UNIX System V, V/AT is.  There is no way to
>compare a system that passes SVID with one that doesn't.  That can't keep
>you from preferring one over the other, but you can't stand them alongside
>each other unless they have something more in common than your opinion.

    Wait!  Hooooooold it!  I'm blowing my whistle.  Something makes me suspect
that you're using SCO's old System-3 port.  You're right, it was a dog.  But
XENIX for the '286 (from SCO) was one of the BETA sites for SVVS.  Their
System-V port.  The one they've been shipping for years.  And they
DO pass it!  Their '386 UNIX product also passes it.  When comparing SCO
to uPort, it's a lot closer to apples:apples than you think--you just have
to stop looking at (very) dated versions of their product.

				Andy
				vandys%hpindda.UUCP@hplabs.hp.com

dave@micropen (David F. Carlson) (06/14/88)

> In article <7030015@hpindda.HP.COM> vandys@hpindda.HP.COM (Andy Valencia) writes:
> |Which feature of the '286 is so incompatible with UNIX?
> 


The two main "problems" of the 286 for UNIX are:

1).	Segmented architecture with 16bit offsets.  Unix likes flat linear
address spaces.  64K is not large enough for "useful" processing--this is why
we all bought VAXes ~8-10 years ago.  Useful had outgrown PDP-11 16 bit
space.  Of course, 32 bit segments of the 386 are plenty flat enough so there
is no problem in SV/386.  The limitation of 1 64K stack is seen in the fatal
kernel panics related to "TSS Fault", "Double Panic", "General Protection"
and your other nightmares.  Hassles of segments are "fixed" in other 80x86 OSs
like MS-DOG by "modifying" C to support "large" and "small", "near" and "far".
Clearly, this is not an option for UNIX.  Thus, the next point.

2).	Register loads within a segment are fast on the 286.  Segment loads are
abyssmally SLOW.  I believe around 20:1 slower than a register load.  Thus,
our large model programs like the UNIX kernel and most "useful" things with
dynamic memory, are crippled by a normal %20 slower run time due to having
to load segment registers for most operations.

Other hassles for PC based products is that the interrupt handlers allow
interrupts to be "lost".  The ttys in particular are based on three different
chips that do things quite differently at times (8150, 81A50, 16450).  So,
in Microport we are forced to poll within our interrupt driven tty driver,
and still we lose interrupts.  A partial "fix" here is to get more cycles
to reduce the probability of hassles.  6 MHz ATs perform miserably whereas
a 12MHz or 20MHz would have satisfactory tty handling.

-- 
David F. Carlson, Micropen, Inc.
...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave

"The faster I go, the behinder I get." --Lewis Carroll