Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!emory!hubcap!ncrcae!sauron!stevem
From: stevem@sauron.Columbia.NCR.COM (Steve McClure)
Newsgroups: comp.arch
Subject: Re: unexpected CPU behavior [was 486 bugs -- it's in there!]
Message-ID: <2159@sauron.Columbia.NCR.COM>
Date: 30 May 90 13:54:28 GMT
References: <1990May27.110726.17007@xavax.com> <16744@haddock.ima.isc.com>
Reply-To: stevem@sauron.UUCP (Steve McClure)
Distribution: na
Organization: E&M-Columbia, NCR Corp, W Columbia, SC
Lines: 30

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, and anyone who really cared would use the
|>"move quick" alternative (MOVEQ #0,destination).  Since the constant
|
|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.  I only heard about this after
|the case because I was still programming in assembler and knew to
|avoid the CLR with I/O.

C compilers seem to keep doing this.  I instinctively set a variable to 0 and
do the assignment.  You find this situation just about anytime you want to do
hardware level stuff.



-- 
----------------------------------------------------------------------
Steve		email: Steve.McClure@Columbia.NCR.COM	803-791-7054
The above are my opinions, which NCR doesn't really care about anyway!
CAUSER's Amiga BBS! | 803-796-3127 | 8pm-8am 8n1 | 300/1200/2400