From owner-freebsd-hardware  Tue May 20 22:21:02 1997
Return-Path: <owner-hardware>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id WAA19286
          for hardware-outgoing; Tue, 20 May 1997 22:21:02 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA19280
          for <HARDWARE@FreeBSD.ORG>; Tue, 20 May 1997 22:20:59 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id PAA05401; Wed, 21 May 1997 15:16:17 +1000
Date: Wed, 21 May 1997 15:16:17 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199705210516.PAA05401@godzilla.zeta.org.au>
To: brett@lariat.org, HARDWARE@FreeBSD.ORG, rberndt@nething.com,
        WELCHDW@wofford.edu
Subject: Re: isa bus and boca multiport boards
Sender: owner-hardware@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>Since the entire set of ports must be scanned whenever an interrupt occurs,
>>maybe there is too much delay in getting to the upper ports. Something gets
>>locked up if they overflow. I left several messages, but no one could
>>figure it out.

Probably not.  Scanning all (inactive) ports takes about 1/4 as long as
handing one fully active 16550 port.  Scanning 16 fully active ports
at 115200 bops takes too long for the default (unconfigurable :-()
fifo trigger level.  However, having 16 fully active ports is rare.

>Maybe the sio driver should be recoded in optimized ASM. I can see some
>major C inefficiencies in it, including lots of repeated pointer
>dereferences and control structures that the compiler would probably
>optimize poorly. I've generated super-tight assembler for serial I/O.

Nope.  There are only some minor C inefficiencies in the important parts
of the driver.  The code is within 50% of best possible generic i386
assembler code by static instruction counts, but this is unimportant
with modern CPUs.  On a P5/133, about 300 pointer dereferences can be
done in the time it takes to do one i/o instruction.  On a 386/20, only
about 6 pointer dereferences can be done in the time it takes to do one
i/o instruction.

There are some major C inefficiencies in tty layers outside the driver.
The pppd line discipline interface and implementation is particularly
inefficient.  On a 486/33, it takes slightly longer than all i/o and
interrupt handling.  This problem is "fixed" by using a modern CPU to
speed up the non-i/o parts.

Bruce