Path: utzoo!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!spdcc!ima!haddock!news
From: news@haddock.ima.isc.com (overhead)
Newsgroups: comp.arch
Subject: Re: unexpected CPU behavior [was 486 bugs -- it's in there!]
Message-ID: <16744@haddock.ima.isc.com>
Date: 29 May 90 22:10:26 GMT
Article-I.D.: haddock.16744
References: <1990May27.110726.17007@xavax.com>
Reply-To: jimm@ima.isc.com (Jim McGrath)
Organization: Interactive Systems Co
Lines: 19

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.

Jim