From owner-freebsd-hardware Wed May 21 21:21:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA29068 for hardware-outgoing; Wed, 21 May 1997 21:21:33 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA29055 for ; Wed, 21 May 1997 21:21:26 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA18011; Thu, 22 May 1997 13:51:08 +0930 (CST) From: Michael Smith Message-Id: <199705220421.NAA18011@genesis.atrad.adelaide.edu.au> Subject: Re: isa bus and boca multiport boards In-Reply-To: <3.0.1.32.19970521075940.0075bc30@lariat.org> from Brett Glass at "May 21, 97 07:59:40 am" To: brett@lariat.org (Brett Glass) Date: Thu, 22 May 1997 13:51:08 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > >> 1) The code looks at a flag called "gone" on each and every port (present > >> or not) during each and every interrupt service. Since the presence or > >> absence of a port is determined at boot time > > > >This is not true. Please note where the "gone" flag is manipulated, and > >post a correction to your statement when you understand. > > OK, here's a correction: It's WORSE than that! The loop checks the pointer > "com" to see if it's null, and THEN checks "gone." Neither should be done at > interrupt time. The list of ports to scan should be built and maintained > outside the ISR. The state of the 'gone' flag may (possibly) change _during_the_execution_ of the ISR. > >It's not, actually, all that much. Scanning a port is a single I/O > >operation, taking around 1us. At 115200bps, it takes 86us for a > >single character to arrive. > > You're omitting overhead! With a check of a pointer, the check of the flag, > loading the port number, doing the I/O, loading the loop counter, and > executing a conditional branch, a scan of a port costs much more. As Bruce has already (correctly) observed, other CPU operations are lost in the noise when coupled with I/O operations. > Is there any other processor with the brain-dead architecture that brings > up all of these issues? The 16550A and edge-triggered interrupts are an > artifact of the IBM PC, circa 1981; the cascaded 8259's and their quirks > are a legacy of the PC/AT, circa 1984. the 8250 family UARTS, and macrocells compatible with them, are used on a staggering array of computing hardware. Look at the Alpha platforms that are a hot FreeBSD port target for example. As I have already noted, polling for work-to-do is an efficiency optimisation as well as a technique for avoiding the 8259's quirkiness. > I think that optimization of the ISRs, at the very least, is > justified, since this code will NEVER be re-used on other platforms. I have already used it on at least one other, non-Intel platform. > It's necessarily hardware-dependent. There IS hardware-independent > code that should remain portable, but this code can't be made > portable; might as well code it tightly and efficiently! It is hardware dependant. It is not, and should not be, processor dependant. > --Brett -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[