Date: Tue, 25 Nov 1997 18:01:01 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mouth@ibm.net (John Kelly) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Message-ID: <199711251801.LAA04173@usr08.primenet.com> In-Reply-To: <347b37fe.5114506@smtp-gw01.ny.us.ibm.net> from "John Kelly" at Nov 25, 97 03:16:18 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >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. The point is not to do both, but to switch, as you say. > >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. How about instead of that, if they are shared, it works in this conflict adverse way (ie: only one at a time) and if they're not, it works your way? That way it works, period, instead of not working with the default hardware configuration you get with new commodity machines (as opposed to one you buy from Rod Grimes). Surprisingly, most people run FreeBSD on hardware they have instead of hardware they buy for that purpose, even if you and I aren't in that group. > >> 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. You hadn't described your method, only your reason (hacked hardware) that you felt it should be everyone's method. 8-). Try again, now. > >>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. I find the same thing from relentlessly removing comments. It forces me to write code that doesn't need comments. But that doesn't mean the trade is worth it. > 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. No clock cycles are insignificant. One long term goal is deadlining based RealTime scheduling. With respect, anal elimination of goto's shows a Pascal as a first language background. This isn't bad, but it does cast a perverse light on the universe. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711251801.LAA04173>