Date: Wed, 21 May 1997 07:59:40 -0600 From: Brett Glass <brett@lariat.org> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards Message-ID: <3.0.1.32.19970521075940.0075bc30@lariat.org> In-Reply-To: <199705210433.OAA08916@genesis.atrad.adelaide.edu.au> References: <3.0.1.32.19970520181142.00734e08@lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:03 PM 5/21/97 +0930, Michael Smith wrote: >You would still have to scan all possible ports and consult their softc >'master' port value. True. But you do not have to scan them extra times! One circuit around the list of ports that use the IRQ is sufficient. >> 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. >> it may scan as many as NSIO-1 extra ports on each interrupt. On a >> system with a many serial ports, this is a LOT of extra time. > >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. >This is an operation possibly best left to the compiler. Have you checked >the generated machine instructions? Haven't disassembled the code yet, but since I've looked at the output of GCC many times, I already know that it has trouble enregistering in loops with pointer dereferences and subroutine calls. >> I don't know what the policy on ASM code is in FreeBSD, but this seems like >> an opportunity to do some VERY serious optimization where it's much needed! > >Processor-specific code in device drivers is not a viable proposition, >given that portability is a significant issue. 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. I think that optimization of the ISRs, at the very least, is justified, since this code will NEVER be re-used on other platforms. 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! --Brett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.19970521075940.0075bc30>