🚀 go-pugleaf

I got conflicting responses regarding this issue. Andrew McRae's response
sounded the most authoritative, but just to be sure I went and determined it
experimentally. I made a program to loop doing clr.b's, ran it on a 68030, and
looked at the bus cycles with my logic analyzer. Sure enough, no reads.  Only
writes. Andrew wins the golden star.

Also, looking in gcc config/m68k.md makes it clear that the author knew that
only the 68000 itself suffered from this mis-feature.

Mike Park still feels there is a problem with the 68EC030's clr instruction.

Thanks for the help!

	-Don

Here are responses:
-----------------------------------------------------------------

Return-Path: <andrew@mega.com.au>
>From: Andrew McRae <andrew@mega.com.au>
Date: Thu, 6 May 93 09:21:06 PDT
To: derway@ndc.com
Subject: Re: 680x0 clr instruction

derway@cco.caltech.edu (D. Erway):
>The original 68000 clr instruction would do a read before write. This lead to
>headaches in device driver code, where reading an address does something. Does
>anyone know if the latter members of this family continue to do this, or if
>they gave up the stupid useless bus cycle? I am specifically interested in
>68030.

The only member of the family to do this is the 68000. The 68010, 68020,
68030 and 68040 do not do this. I am not sure about newer half-breeds
such as the 68332/68302 CPU32 cores etc. The reason this actually
occurs (by legend) is that the 68000 microcode used a second level
of microcode called nanocode, and some instructions doubled up on
nanocode sequences so that a clr could be implemented as a hacked up
read-modify-write arithmetic opcode (sort of an AND with an intermediate
clear stage) - I guess this saved some room. I mean, what is the point
of letting clr change the condition codes to a known value? It would
be much more useful to let a clr happen without changing the condition codes.

Later versions (68010 etc) fixed the extra memory cycle, but of
course the condition code setting of clr has to be backward compatible.
The extra cycle meant that for cyclic clears, it was often *much*
faster to clear a register and then move the register to the memory
locations.

> The reason I ask this group is that I am changing over compilers, and my old
> compiler had a switch to disable it using the clr instruction. I can find no
> such switch in gcc 2.3.3 Perhaps it no longer matters though...
> 
> 		-Don

If you declare a pointer to be volatile with gcc 2.3.3, and store 0
through it, and the compiler has been told to generate 68000 code,
then the compiler will do the right thing and use a move #0 to
do the store rather than a clear e.g

The following code -

func()
{
volatile char *p = (char *)0x10000;

	*p = 0;
}

When compiled with the line (cc68 is our name for gcc)

        cc68 -mc68000 -O -S file.c

produces the following code:
---------
	#NO_APP
	gcc2_compiled.:
	.text
	        .even
	.globl _func
	_func:
	        link a6,#0
	        movel #65536,a0
	        moveb #0,a0@		<----
	        unlk a6
	        rts
--------
When compiled with the line

        cc68 -O -S file.c

generates:
------
	#NO_APP
	gcc2_compiled.:
	.text
	        .even
	.globl _func
	_func:
	        link a6,#0
	        movel #65536,a0
	        clrb a0@		<----
	        unlk a6
	        rts
--------

This behaviour is so much more rational then just disabling the
clr instruction, as the volatile keyword also disables certain
optimisation so that loop contructs that access particular locations
continuall work correctly e.g

      while (*ptr & 1)
		;

This would not work correctly unless ptr were declared volatile.
We use gcc for all our embedded work, which includes a lot of drivers,
and I have never had any problems using it (as long as you declare
things the right way).

Cheers,

Andrew McRae			inet:	andrew@mega.com.au
Megadata Pty Ltd,		uucp:	..!uunet!mega.com.au!andrew
North Ryde  2113		Phone:	+61 2 805 0899
NSW    AUSTRALIA		Fax:	+61 2 887 4847

-----------------------------------------------------------------

Date: Wed, 5 May 1993 21:57:49 -0700
From: Mike Park <mikep@dragoman.com>
To: derway@cco.caltech.edu
Subject: Re: 680x0 clr instruction

Newsgroups: gnu.gcc.help
Distribution: gnu

derway@cco.caltech.edu (D. Erway) writes:

>The original 68000 clr instruction would do a read before write. This lead to
>headaches in device driver code, where reading an address does something. Does
>anyone know if the latter members of this family continue to do this, or if
>they gave up the stupid useless bus cycle? I am specifically interested in
>68030.

The same problem still exists in the 68030.  My suggestion to you
is to clear variables by assigning from a zero variable. ie:

static int zero = 0;
int* csr = 0xfff;   /* special hardware register address */

*csr = zero;  	    /* forces write; don't use *csr = 0; */

-----------------------------------------------------------------

From: Mike Park <mikep@dragoman.com>
Subject: Re: 680x0 clr instruction
To: derway@ndc.com (Don Erway)
Date: Fri, 7 May 1993 01:03:38 -0700 (PDT)

Interesting.  Have you tried the same test with a 68EC030 part?
(It is a standard 030 part without the memory management unit
commonly used in embedded systems).  I had problems with
clearing write only hardware locations with the clr instruction,
but no problems when I changed to mov.  Maybe the bus cycles are
different enough that my hardware failed, even if it wasn't doing
a read.

In summary bewarned that clr and mov can make a difference when
accessing custom hardware from a 68EC030.

Mike
-- 
Mike Park            mikep@dragoman.com          (NeXT Mail OK)