Path: utzoo!attcan!uunet!mcsun!hp4nl!philapd!ssp11!dolf
From: dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer)
Newsgroups: comp.arch
Subject: Re: unexpected CPU behavior [was 486 bugs -- it's in there!]
Message-ID: <754@ssp11.idca.tds.philips.nl>
Date: 27 May 90 21:02:56 GMT
References: <1990May27.110726.17007@xavax.com>
Organization: Philips Information Systems, Apeldoorn, The Netherlands
Lines: 30

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.
>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.

I think Phillip is missing the point as the MOVEQ allows only a Data
Register (D0 - D7) as destination, not just any memory address.
So I believe the CLR is a big problem as the C compiler I had compiled:
    some_IO_reg = 0;
into
    clr.b some_IO_reg
which is not what I wanted as a read of this volatile I/O register
has some side effects (to be precise: Bus Error as it was a write
only I/O register). There was no way to tell the compiler to use a
    move.b #0,some_IO_reg
Note that this was on a mc68000/68008 before ANSI C (i.e. volatile)
-- 
Dolf Grunbauer      Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl
Philips Information Systems            UUCP     ...!mcsun!philapd!dolf
Dept. BS Software,  P.O. Box 245, 7300 AE Apeldoorn, The Netherlands 
read: error in reading .signature