🚀 go-pugleaf

In article <1992Oct1.154555.5001@ni.umd.edu>, louie@sayshell.umd.edu (Louis A. Mamakos) writes:
|> In article <1aehh5INNa0r@stephen.cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes:
|> 
|> >What is the future of serial ports?  Most general purpose processors
|> >can't keep up with the high interrupt rate.  Will a serial port
|> >replacement eventually evolve... perhaps something like a serial
|> >port version of SCSI?  What is the bandwidth of Apple Desktop Bus?
|> 
|> Serial ports don't have to interrupt on every character.  If there
|> were a moderately intelligent serial controller, plus DMA support for
|> the I/O transfers, then things could be quite zippy, thank you.
|> 
|> Doing transfers on the SCSI bus, while cheaper than fielding thousands
|> of interrupts per second, are not free either.  Consider that with the
|> current products, you'll likely make a context switch into user code
|> for the process that actually drives the SCSI device.  A well designed
|> serial interface, with proper kernel support, ought to be able to do
|> better.
|> 
|> The real shame is that the NeXT 68030 boards in the original cubes had
|> hardware support for DMA channels for the serial interfaces, though
|> the software apparently didn't us it.  Those DMA channels were dropped
|> in the 68040 products..

Chuckle...

When I started work on TTYDSP, I thought to myself.. Man NeXT's serial
ports are brain damaged. Why didn't they use DMA? 

Well, after a little playing, it became quite apparent to me why simple
DMA doesn't work. The amount of processing that goes on per character,
in order to conform with unix tty processing, is OBSCENE. Let me put it
this way.... TTYDSP can almost manage 195,000 baud - that's 19,500
characters per second (10 bit chars). Let's be nice and say that DSP only
does 4 million instructions per second. 4000000 / 19500 = 200 instructions
per character... Now you can either assume I'm a lousy programmer, or
you can look at what processing has to happen. Here are some things
which you might want to consider:

RUNNING IN COOKED MODE:
Input from the serial port: ABC
Output from the CPU: DEF
Input from the serial port: <DEL>

Well, let's see.. That would mean backing up over outputted characters.
Can't do that.. I guess just have to output:
^R
AB

ANOTHER CASE FOR COOKED MODE: (tab expansion enabled)

Input from serial port: XABCD<TAB>X<DEL><DEL>

Okay.. So, the first <DEL> backspaces over the X. The second <DEL> has
to backspace over the TAB.. Er.. How many spaces did that TAB output?
Well, who knows... So you have to go add up the total output size of
all characters before the TAB (which in this case is 5, so the tab
outputted 3 spaces which must be backspaced over).

...
Oh but wait! This is all cooked mode.. Only users enter stuff in 
cooked mode. It can be slow as a dog. No user can enter stuff at 9600
baud by hand.. No problem.

Well, any time someone does:
cat >foo
and downloads a file... That's cooked mode. Enjoy.

WELL, OKAY OKAY.... ANYTHING REAL USES RAW MODE.. NOT MUCH PROCESSING
HAPPEN THERE... RIGHT?

wrong...

First off.. Consider echo in raw mode. It can be enabled... Now suppose
someone hit ^K what has to be echoed? Well, the ^ char, followed by the
K char, ofcourse. Now someone sends a stream of 1000 ^Ks to the serial
port... That's right! 2000 characters have to go out.. Which takes longer
to send out that than the 1000 chars take to come in... That sounds
suspiciously like a QUEUE is required!! Those chars that have come in
but haven't yet been echoed... Which is infact, what is required...

This problem becoems 100000 times sicker when you consider all the 
stuff that happens for tab expansion...



Those who believe serial processing can be handled by DMA, please think
again. This only became clear to me after while thinking about how to
implement the processing.

In summary, the problem is NOT the number of interrupts. It's the amount
of work that has to be done on each character in order to comply with
the standard TTY interfaces.

Niall