printf, data presentation

[Bruce Albrecht]

In article <2075 at scolex>, seanf at sco.COM (Sean Fagan) writes:
> In article <225800108 at uxe.cso.uiuc.edu> mcdonald at 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.