The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Bakul Shah <bakul@iitbombay.org>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] 386BSD released
Date: Fri, 16 Jul 2021 09:00:58 -0400	[thread overview]
Message-ID: <YPGDCoO4uB1ehBxi@mit.edu> (raw)
In-Reply-To: <A75B5962-43CC-4BFA-B20F-DD66913DB72D@iitbombay.org>

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

  reply	other threads:[~2021-07-16 13:01 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13 22:28 Dave Horsfall
2021-07-14  7:54 ` Michael Kjörling
2021-07-14  8:19   ` Angus Robinson
2021-07-14  8:32     ` Michael Kjörling
2021-07-14  9:07       ` Lars Brinkhoff
2021-07-14 14:09         ` Larry McVoy
2021-07-14 14:54           ` Warner Losh
2021-07-14 15:06             ` Richard Salz
2021-07-14 15:37             ` Steve Nickolas
2021-07-14 10:09       ` Tom Ivar Helbekkmo via TUHS
2021-07-14 10:39         ` arnold
2021-07-14 17:21         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2021-07-14 17:32           ` Richard Salz
2021-07-14 15:01     ` Clem Cole
2021-07-14 17:40       ` [TUHS] [COFF] " Theodore Y. Ts'o
2021-07-14 17:50         ` Larry McVoy
2021-07-14 18:28         ` Clem Cole
2021-07-14 11:49   ` [TUHS] " Andy Kosela
2021-07-14 15:48     ` Theodore Y. Ts'o
2021-07-16  1:35   ` Dave Horsfall
2021-07-16  2:33     ` risner
2021-07-16  4:25       ` Theodore Y. Ts'o
2021-07-16  5:51         ` Bakul Shah
2021-07-16 13:00           ` Theodore Y. Ts'o [this message]
2021-07-16 13:56             ` Larry McVoy
2021-07-16 14:40               ` Clem Cole
2021-07-16 15:44                 ` Theodore Y. Ts'o
2021-07-16 16:11               ` Bakul Shah
2021-07-16 19:07               ` Kevin Bowling
2021-07-16 20:17                 ` Clem Cole
2021-07-16 20:24                   ` Richard Salz
2021-07-18 13:13                     ` arnold
2021-07-18 13:23                       ` Richard Salz
2021-07-18 13:43                       ` [TUHS] MtXinu calendar (was Re: 386BSD released) Al Kossow
2021-07-18 13:51                         ` Al Kossow
2021-07-18 16:44                         ` Al Kossow
2021-07-18 17:38                           ` John Cowan
2021-07-18 18:35                           ` Bakul Shah
2021-07-19  3:06                             ` Dan Stromberg
2021-07-18 19:00                           ` arnold
2021-07-18 21:48                             ` Deborah Scherrer
2021-07-18 20:06                           ` Lyle Bickley
2021-07-14 21:37 ` [TUHS] 386BSD released Bakul Shah
2021-07-16 21:22 ` Dave Horsfall
2021-07-15  2:21 Douglas McIlroy
2021-07-15  2:41 ` Adam Thornton
2021-07-15 15:07 ` Clem Cole
2021-07-16 17:30 Nelson H. F. Beebe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YPGDCoO4uB1ehBxi@mit.edu \
    --to=tytso@mit.edu \
    --cc=bakul@iitbombay.org \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).