Path: utzoo!attcan!uunet!xavax!alvitar
From: alvitar@xavax.com (Phillip Harbison)
Newsgroups: comp.arch
Subject: Re: unexpected CPU behavior [was 486 bugs -- it's in there!]
Message-ID: <1990Jun2.055107.11021@xavax.com>
Date: 2 Jun 90 05:51:07 GMT
Sender: alvitar@xavax.com
Organization: Xavax
Lines: 27

In article <16744@haddock.ima.isc.com> jimm@ima.isc.com (Jim McGrath) writes:
> In article <1990May27.110726.17007@xavax.com> alvitar@xavax.com (Phillip
> Harbison) writes:
> > In article <2813@medusa.informatik.uni-erlangen.de>, csbrod@medusa (Claus
> > Brod) writes:
> > > Motorola's 68000 had a kind of quirk that caused a clr command to
> > > first read the addressed location and then clear it. This led
> > I never considered this to be a big problem.  As you noted, Motorola
> > documented this behavior ...
> I remember it being quite an ugly problem because of a C compiler that
> used the CLR instead of MOVEQ.  The hardware group in my company had
> mapped a read-only and a write-only I/O port to the same address to
> save a bit of wire.  Trying to set the write only port to 0 caused a
> destructive read of the read-only port.

My crew wrote about 14,000 lines of C code for a telecommunications
system.  This was an embedded control application where the code
manipulated alot of hardware registers, most of which were write-only. 
I don't recall any problems, but then, the hardware designers were wise
enough to only strobe the registers on a write cycle.  The compilers
used were Green Hills C and the native compiler for 68000 Xenix.  Maybe
we were just lucky. :-)

-- 
Live: Phil Harbison, Xavax, P.O. Box 7413, Huntsville, AL 35807
Uucp: alvitar@xavax.com
Bell: 205-539-1672, 205-880-8951