Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!talcott!panda!genrad!decvax!bellcore!petrus!sabre!zeta!epsilon!gamma!ulysses!mhuxr!mhuxt!houxm!hropus!ka
From: ka@hropus.UUCP (Kenneth Almquist)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops
Message-ID: <295@hropus.UUCP>
Date: Fri, 21-Feb-86 18:31:13 EST
Article-I.D.: hropus.295
Posted: Fri Feb 21 18:31:13 1986
Date-Received: Mon, 24-Feb-86 06:34:42 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP> <9645@amdcad.UUCP>
Organization: Bell Labs, Holmdel, NJ
Lines: 22
Xref: linus net.arch:2394 net.micro.mac:4787 net.micro.68k:1442

>> Sorry, but this bad makes it a particularly *bad* USART chip, regardless
>> of any other features.
>> Imagine writing a device driver for it, finding out that the C compiler
>> generates such code that there's far more than 2.2us between writes, and
>> leaving the place. Then, two years later, the site gets a new C compiler
>> with a much better optimizer..........	[JACK JANSEN]
>
> Sorry, but this sounds like a bad device driver to me, not a bad device.
> Depending on a poor C compiler for timing is just as bad as depending
> on any other non-portable 'feature' of a C compiler.  The device driver 
> could be broken by a new C compiler in any of a few thousand other
> ways.						[JIM BUDLER]

I don't like the idea of depending upon the C compiler for timing, but
what is the alternative?  Write the specific parts of the device driver
in assembly language?  This introduces maintainance problems of its own.

You frequently have to depend upon non-portable features of C when writing
device driver code, but of course device drivers are non-portable anyway.
				Kenneth Almquist
				ihnp4!houxm!hropus!ka	(official name)
				ihnp4!opus!ka		(shorter path)