printf, data presentation

[Sean Fagan]

[note the followup.  This isn't a C-only subject any more]
[also, although it wasn't indicated, '>>' is me (seanf at sco.com)]
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!

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 at sco.UUCP  |    you house."  -- George Carlin
(408) 458-1422  | Any opinions expressed are my own, not my employers'.