Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!gatech!amdcad!jimb
From: jimb@amdcad.UUCP (Jim Budler)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops
Message-ID: <9835@amdcad.UUCP>
Date: Sat, 22-Feb-86 14:39:53 EST
Article-I.D.: amdcad.9835
Posted: Sat Feb 22 14:39:53 1986
Date-Received: Mon, 24-Feb-86 20:48:50 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP> <9645@amdcad.UUCP> <295@hropus.UUCP>
Reply-To: jimb@amdcad.UUCP (Jim Budler)
Organization: AMD, Sunnyvale, California
Lines: 40
Xref: linus net.arch:2396 net.micro.mac:4792 net.micro.68k:1443

In article <295@hropus.UUCP> ka@hropus.UUCP (Kenneth Almquist) writes:
>>> 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.

I guess I wasn't quite clear.  If whatever code you generated cannot
guarantee 2.2uS when run through the optimizer then you cannot say that
you have written a good device driver. I got another flame from somewhere
asking me how I thought it should be done without timing loops or
additional hardware. I didn't say not to use a timing loop, but if
you are going to do software timing DO software timing. i.e. put some real
code in there to GUARANTEE whatever time you want.

And yes, in a situation like this, trying to guarantee 2.2uS, I think
a short piece of assembly code to wait 3uS IS the answer. And how much
of a maintenance problem can 5 or 6 lines of assembly code be.  I've
seen many cases like the Vax _doprint in the Berkeley code and a few other
pieces of code with a couple of lines of in line assembly code in them.
-- 
 Jim Budler
 Advanced Micro Devices, Inc.
 (408) 749-5806
 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb
 Compuserve:	72415,1200