Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!csrd.uiuc.edu!usenet
From: bruner@sp15.csrd.uiuc.edu (John Bruner)
Newsgroups: comp.arch
Subject: unexpected CPU behavior [was 486 bugs -- it's in there!]
Message-ID: <1990May25.131947.4302@csrd.uiuc.edu>
Date: 25 May 90 13:19:47 GMT
References: <634@sibyl.eleceng.ua.OZ> <76700202@p.cs.uiuc.edu> <350@necssd.NEC.COM> <2813@medusa.informatik.uni-erlangen.de>
Sender: usenet@csrd.uiuc.edu (news)
Reply-To: bruner@sp15.csrd.uiuc.edu (John Bruner)
Organization: CSRD, University of Illinois
Lines: 21
In-Reply-To: csbrod@medusa.informatik.uni-erlangen.de (Claus Brod )

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
>to numerous difficulties when clearing I/O registers. This one,
>however, has always been documented by Motorola, so it's more
>a feature than a bug. Subsequent 680x0s perform a clr operation
>as God intended.

The 68000 was not the only machine to have this particular quirk.  The
CLR instruction on (at least some models of) the PDP-11 also was
implemented by reading memory and then writing zero.  This was a
consequence of implementing CLR as a single-operand instruction in the
same category as, e.g. increment.

In addition to its unexpected effects upon device registers, another
problem with the 11's CLR was that it could not be used to initialize
main memory from an unknown state (e.g., when the machine was rebooted
the first time after being turned on): the reads were likely to
encounter bad parity and cause a trap.  This was a more visible
problem when semiconductor memories replaced core.  (The work-around
was to initialize memory by moving zero.)