Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amdcad.UUCP
Path: utzoo!linus!decvax!decwrl!amdcad!jimb
From: jimb@amdcad.UUCP (Jim Budler)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops
Message-ID: <9645@amdcad.UUCP>
Date: Tue, 18-Feb-86 17:36:44 EST
Article-I.D.: amdcad.9645
Posted: Tue Feb 18 17:36:44 1986
Date-Received: Wed, 19-Feb-86 23:40:54 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP>
Reply-To: jimb@amdcad.UUCP (Jim Budler)
Organization: AMD, Sunnyvale, California
Lines: 20
Xref: linus net.arch:2367 net.micro.mac:4750 net.micro.68k:1435

In article <6780@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) 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..........

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
 Advanced Micro Devices, Inc.
 (408) 749-5806
 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb
 Compuserve:	72415,1200