Ridiculous(ly slow) tty driver

[David F. Carlson]

> In article <7030015 at hpindda.HP.COM> vandys at 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