seanf@sco.COM (Sean Fagan) (01/15/89)
[note the followup. This isn't a C-only subject any more] [also, although it wasn't indicated, '>>' is me (seanf@sco.com)] 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. > >>And, yes, there are at least 2 C compilers for NOS, so it is an issue. > >Things like NOS are why I WANT it IN THE STANDARD!!! If you only get >a line at a time YOU CAN'T, ABSOLUTELY CAN'T write decent software. >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 >what I would call "normal" io? If I were looking for a computer today, >I would not even CONSIDER one that can't do that. If a manufacturer >wants to make a computer that has severe IO problems like that, he >should have a multiprocessor system where directly connected users >CAN do it, offloading only the more compute bound parts of a task >on the more remote sections of hardware. >If your OS can't do single character IO ---- FIX IT! 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": adb ar as awk basename cal cat cc chgrp chmod chown chroot cp date dc dd df diff du echo ed egrep fgrep file find fsck grep head ipcrm ipcs ls make mkdir mv nm passwd ps pwd ranlib rm rmdir sed sh sleep sort strings strip stty sync tar time touch tr tsort wc who at bc calendar ctags cxref finger ftp get lex lint mail rcp sdb yacc *NONE* of these require scIO, and would work *just fine* on systems that don't have it. 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... Point 3: (I've copied the lines from above, so don't worry, he didn't repeat himself.) >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 go through the input line, looking for escape characters and commands, processes it all internally, and then dumps what it thinks the screen should look like. It's a very nice editor (although I would like to see it get regular expressions for searching and replacing), and it's possible to get 50-60 people using it at once, on the same machine. Try this with GNU emacs on anything other than an Amdahl. Point 1, revisted, with shades of Point 2: Get a Unix machine, with sources to the tty driver. Rewrite the tty driver so that it copies an entire line of text to the process. Get a 630 (aka BLIT terminal), and run sam on it. I believe that Doug Gwyn has commented enough about sam and a 630. Believe it or not, the Unix-end of sam is a line-oriented editor. Are you saying that sam is not decent software? Face it: Unix is slow, and will always be slow until people start doing their ports properly, looking for speed, and designing it for the target system entirely. NOS, on the other hand, is fast, because it was designed properly. This does not mean that I prefer NOS to Unix. However, I have a little test for you. Get on your favorite Unix or VMS machine (say, a top-of-the-line VAX). Write a nice little FORTRAN program that does lots of file-io, or even user-io. I'll port the program to a CDC Cyber 170/750, a 15-20 year old machine, and it will probably run faster, even though the 750 is, by Cyber standards, a bit slow (it's only a 5-6 MFLOPS machine, mainly due to the 400ns ram). Or, I'll port it to a Cyber 180/960, running in 170 mode, and it will still probably beat the VAX. Why? Because the OS was designed to do that type of thing, while VMS and Unix weren't. Try thinking what a feature does to an operating system before you demand it. You might find that it's better, in the long run, to leave it out and try a different approach (a la FSE). I think that's most of what I want to say. I, also, used to think that scIO was necessary, until I started working on NOS, and found out the reasons. Other than vi, rn, and emacs, I don't use scIO programs anymore, and I can get the same functionality for those without it. I would also like to point out that it's possible to port Unix in such a way that typing a character on the keyboard doesn't interrupt the CPU, but most people don't bother doing so. Add that to the list of Unix gripes. -- 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'.
bga@raspail.UUCP (Bruce Albrecht) (01/17/89)
In article <2075@scolex>, seanf@sco.COM (Sean Fagan) writes: > 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. > > > >>And, yes, there are at least 2 C compilers for NOS, so it is an issue. > > > >Things like NOS are why I WANT it IN THE STANDARD!!! If you only get > >a line at a time YOU CAN'T, ABSOLUTELY CAN'T write decent software. > >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 > >what I would call "normal" io? If I were looking for a computer today, > >I would not even CONSIDER one that can't do that. If a manufacturer > >wants to make a computer that has severe IO problems like that, he > >should have a multiprocessor system where directly connected users > >CAN do it, offloading only the more compute bound parts of a task > >on the more remote sections of hardware. > >If your OS can't do single character IO ---- FIX IT! > Anyone who thinks that "normal" users of NOS can't do single character I/O, is either using something other than CDC communications processors, or didn't bother to look at the CDC manuals. We have supported single character I/O for at least 5 years, if not longer, although it requires some setup by the user application. CDC's position, and I think rightly so, is that single character I/O is such a drain on ANY system's resources that it should not be used unless absolutely necessary. (BTW if you were looking for a computer today, CDC would sell you a 180 running NOS/VE, and there is no development done for NOS any more.) > I think that's most of what I want to say. I, also, used to think that scIO > was necessary, until I started working on NOS, and found out the reasons. > Other than vi, rn, and emacs, I don't use scIO programs anymore, and I can > get the same functionality for those without it. > > I would also like to point out that it's possible to port Unix in such a way > that typing a character on the keyboard doesn't interrupt the CPU, but most > people don't bother doing so. Add that to the list of Unix gripes. In VX/VE, CDC's Unix shell for NOS/VE, input is normally line at a time. When a program "needs" scIO, such as VI, it instructs the front-end communications processor to send input a character at a time. I personally prefer the CDC screen editors that are not scIO, as I find them easier to use than the vi input/command modes. Another reason why CDC is against using scIO is that it doesn't work very well in a distributed computing environment. If the scIO is on a single computer directly connected to the terminal (or is the computer), it works very well, and the character echo times are usually measured in a tenth of a second or less. On the other hand, if you are connected to a large network, and some of the computers you are using are located thousands of miles away, the character echo time can be .75 seconds or more, which most people find unacceptable. Try running vi or Emacs when dialed into Telenet, and from there through a second network, and you'll understand why using terminal echo and an editor that doesn't use scIO has its advantages. Because single character I/O is not supported by some terminals (block mode only), some networks (not available, or too expensive), and some operating systems, I don't think routines to support it belong in the set of routines required to exist in order for a C implementation to be standards-compliant. If there's a second set of standard routines, that are available at the discretion of the implementer, that's where they belong.