[TUHS] 386BSD released

Theodore Y. Ts'o tytso at mit.edu
Fri Jul 16 23:00:58 AEST 2021


On Thu, Jul 15, 2021 at 10:51:11PM -0700, Bakul Shah wrote:
> 
> Dave Yost wrote the serial driver for our 4 port serial card @ Fortune
> (1981-82).  Later chips like NS16550 had 16 char on chip buffers but we
> back then we used a Moto SIO chip that had only one char buffer.  IIRC,
> he used two tricks. One was "partially evaluated" xmit/recv handlers so
> that each port got its own xmit/recv functions, with hand-crafted
> instructions (in hex, no less!) just right for a given port and all the
> interry t handler . The  do was transfer a char from/to the buffer it
> (lready knew about. The other was he increased the cblock size from 8 to 128
> (what a clist points to). He says he described this design to dmr who said
> why not?!  With this design Yost's code was able to handle 4 full-duplex
> 9600 baud streams at full-speed. Not bad for a 5.6Mhz clock machine!

The trick that I used was two have two "flip buffers" which were
dedicated for each serial port.  One buffer would be filled by the
interrupt handler, while the other would be buffer would be processed
by the bottom half (read: software interrupt) handler.  When the
bottom half handler had emptied one buffer, it would check to see if
there were any characters in the other buffer, and if so, flip the two
and process the characters in that buffer.  Exclusion was handled by a
combination of disabling serial interrupts and using a spinlock (which
was held just long enough to flip the pointers to the two flip
buffers).

With this scheme I could handle multiple pairs of 115200 baud streams
at full rates before the 40 MHz CPU was saturated.  No memory
allocation is required on the hot paths, and the amount of processing
that is done in the hardware interrupt context is the absolute
minimum.

I also added a bit test against 32-byte bitarray to determine whether
a character could be handled via the fast path or require special
handling (in case it was a ^C, ^U, ^S, etc.) but that was important
only for cooked mode; it wasn't needed for raw mode.  I suspect this
hack would become less or even not helpful as Intel processors became
more Spectre- and Meltdown-susceptible, but for the 386, it was a win.  :-)

     	      	  			    	- Ted


More information about the TUHS mailing list