Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!princeton!udel!rochester!cornell!uw-beaver!mit-eddie!ll-xn!ames!lll-tis!lll-winken!abhg!carpet!bill From: bill@carpet.UUCP Newsgroups: comp.unix.microport Subject: Re: Ridiculous(ly slow) tty driver Summary: Xenix isn't UNIX Message-ID: <78@carpet.WLK.COM> Date: 3 Jun 88 15:54:48 GMT References: <1086@maynard.BSW.COM> <7030015@hpindda.HP.COM> Organization: W.L. Kennedy Jr. & Associates, Pipe Creek, TX Lines: 43 Posted: Fri Jun 3 11:54:48 1988 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