Date: Tue, 25 Nov 1997 03:16:18 GMT From: mouth@ibm.net (John Kelly) To: Terry Lambert <tlambert@primenet.com> Cc: hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Message-ID: <347b37fe.5114506@smtp-gw01.ny.us.ibm.net> In-Reply-To: <199711241906.MAA14773@usr01.primenet.com> References: <199711241906.MAA14773@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Nov 1997 19:06:36 +0000 (GMT), Terry Lambert <tlambert@primenet.com> wrote: >Actually, it's possible for DOS machines to be perfectly happy in >switching interrupt driven input from COM1 (to say a terminal server) >to COM3 (to say a modem). Single tasking DOS will do one or the other, but not both during the same period of time. >both should remain accessible in the general sense of allowing me >to close one to open the other (ie: alternate the interrupt programming >based on the open). That might be nice for a casual user, but for the type of FreeBSD use prevalent, I don't think it has much value, and I would whack it. >Philosophically, you should buy good hardware. But also philosophically, >you should work on the hardware you're given. I've probably thrown out more hardware than I've kept. Maybe that's why I'm so poor. >> I wrote a code fragment in Turbo C which implements a highly optimized >> framework (not a finished product) for UART receiver burst mode >Is this one of those "take an interrupt, then poll like hell" type >drivers? 8-). Not exactly. Take an interrupt, check the IIR and LSR, and if no errors in your FIFO, execute one assembler REP INSB instruction to empty it. It can't be any tighter. >> if you want to see it. >The more code, the merrier. 8-). Bruce said he wasn't particularly interested, but I'm willing to share my idea with anyone who is. >>I've eliminated all goto statements. >The compiler will put the jump instructions back in, anyway >and all you'll have done is increase the code path by one or > more tests, slowing the thing down. I know the compiler emits jumps but that's beside the point. Relentlessly eliminating all goto statements forces me to analyze the problem to a greater depth, and consistently produces code which is easier to read and comprehend. By organizing well, you won't have many extra tests, and the clock cycles of those few will be insignificant. The new goto-less code is usually so much more efficient and well organized that a few extra test clock cycles are mere drops in a sea of improvement. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?347b37fe.5114506>