bauer@loligo.cc.fsu.edu (Jeff Bauer) (01/19/89)
>In article <225800108@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >>> >>>For example, NOS on a CDC >>>Cyber 170-state machine: to do I/O, you normally tell a peripheral >>>processor, which swaps you out of main memory until it has a line of TTY >>>input, at which point it rolls you back into memory, with the line >>>automagically put into your buffer. To do what inkey$ in BASIC does, you >>>would need single-character I/O, which "normal" users cannot get in NOS. >> [long tirade bashing NOS] >>Things like NOS are why I WANT it IN THE STANDARD!!! If you only get . . . >>If your OS can't do single character IO ---- FIX IT! In article <2075@scolex> seanf@scolex.UUCP (Sean Fagan) writes: >Point 1: Most of the software I write doesn't use single-character I/O, >unless you count ^C (to interrupt) as scIO, in which case I believe NOS can >be set up to do the same thing. Based on what you say, the following >programs aren't "decent software": > [List of UNIX commands] >Point 2: There is a damned good reason why NOS doesn't have scIO. scIO is, >no matter how you do it, going to slow down the processor. Everything you >interrupt the cpu, you are slowing down a program somewhere. If, on the >other hand, you do what NOS does, you only have to interrupt the processor >when you roll a job back into memory, at which point it already has the >input line in memory, and can just play with it at it's leisure. Why do you >think that there are "smart" serial cards for PC's running Unix? >You can, if you really want to, get scIO on a Seymour-Cray-designed machine, >but talk to people running GNU emacs on a Cray-2, and ask them what it does >to system performance... > > >>The impossibility of writing a decent editor is one reason we no >>longer use CDC computers here. Why can't "normal" users on NOS do > >There is a very decent editor under NOS. It's called FSE (Full Screen >Editor). Yes, it's full screen. No, it doesn't use scIO. What it does is . . [Interesting discussion about how NOS solves the sorts of problems that large mainframe users run -- FORTRAN & large I/O.] >-- >Sean Eric Fagan | "May the forces of evil become confused on the way to >seanf@sco.UUCP | you house." -- George Carlin >(408) 458-1422 | Any opinions expressed are my own, not my employers'. An interesting case study for how operating system design is affected by system architecture is the PLATO subsystem. It provided "scIO" (I prefer the term "hot key" or "raw mode") and gave good response times to what at the time were high-speed terminals (imagine running 512x512 bitmap graphics over a 1200 baud connection and making it look reasonable enough for chidren to be entertained long enough to learn...) Every key pressed at a terminal was handled by CPU level code, in a single NOS control point (process) that multi-tasked users. PPUs (peripheral processor units) offloaded all the disk I/O and handled much of the network traffic, dropping key strokes into CPU memory. The resource usage was (is, actually, there are still PLATO systems running on various CDC gear the world 'round) tremendous, however. To support the entire PLATO environment took up from 4 to 5 dedicated control points (ahem, daemons), a large amount of external RAM (500 million 60-bit words and up), and a handful of dedicated PPU programs handling network and disk traffic. The point being that the design of PLATO (an operating system in its own right, even if it "ran" on top of NOS) showed mechanisms for building on top of the somewhat primitive aspects of NOS complained about earlier. Many sites ran PLATO with a full interactive and batch load (non- PLATO traditional processing) on medium-sized Cybers with no great degradation of CPU power or resources -- a great example of how creative use of system architecture can achieve something that the "standard" wouldn't expect on these types of machines. I understand it that when Don Bitzer at U of Ill. looked for CPU horsepower in the early 60's for PLATO IV (the current version of PLATO that exists on the Cybers) Control Data gear was pretty much the only choice... -- Jeff Bauer bauer@loligo.cc.fsu.edu ETA Systems, Inc. (904) 644-2591 ext. 113
marc@hpfcdc.HP.COM ('Thelonious' Sabatella) (01/20/89)
/ hpfcdc:comp.os.misc / bauer@loligo.cc.fsu.edu (Jeff Bauer) / 2:49 pm Jan 18, 1989 / >I understand it that when Don Bitzer at U of Ill. looked for CPU >horsepower in the early 60's for PLATO IV (the current version of >PLATO that exists on the Cybers) Control Data gear was pretty >much the only choice... Maybe so, but I'll bet a lot of that had to do with TUTOR, "the official arcane programming lanaguage of the Super Bowl (as well as PLATO)" which kind of assumes that the natural wordsize is 60 bits. Or does PLATO IV predate TUTOR? -------------- Marc Sabatella (an ex FSU PLATO-ite) HP Colorado Language Lab marc%hpfcrt@hplabs.hp.com