Path: utzoo!attcan!uunet!samsung!xylogics!transfer!lectroid!bigbootay!dswartz
From: dswartz@bigbootay.sw.stratus.com (Dan Swartzendruber)
Newsgroups: comp.arch
Subject: Re: unexpected CPU behavior [was 486 bugs -- it's in there!]
Message-ID: <1407@lectroid.sw.stratus.com>
Date: 27 May 90 20:47:14 GMT
References: <1990May27.110726.17007@xavax.com:
Sender: usenet@lectroid.sw.stratus.com
Reply-To: dswartz@bigbootay.sw.stratus.com (Dan Swartzendruber)
Organization: Stratus Computer, Software Engineering.
Lines: 33

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
:: 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.
:
: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
:value (8 bits signed) was included in the instruction word, I don't
:believe there was any advantage to CLR versus MOVEQ.
:

Please reread your 680x0 assembler manual.  MOVEQ only works on
data registers.  Either you clear a data register (with MOVEQ)
and move it to the destination, or you move a literal zero there.

The former costs an extra instruction.  The latter isn't much better,
especially when you're clearing a longword, as this embeds a four
byte constant in the instruction.

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

--

Dan S.