Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!sun!imagen!atari!dyer
From: dyer@atari.UUCP (Landon Dyer)
Newsgroups: comp.lang.c
Subject: 68000 CLR read/modify/write
Message-ID: <719@atari.UUCP>
Date: Sat, 2-May-87 16:42:06 EDT
Article-I.D.: atari.719
Posted: Sat May  2 16:42:06 1987
Date-Received: Sun, 3-May-87 08:43:50 EDT
References: <165@mas1.UUCP>
Organization: Atari Corp., Sunnyvale CA
Lines: 27

> 	I recently implemented a 68000 OS in C.  The amount of assembly
> coding was insignificant.  One interesting anecdote:
> 
> 	#define	DSK_SEL	*(char *)0xf12345  /* WRITE but dont READ */
> 		DSK_SEL = 0;
> 
> caused a parity error and had to be replaced with
> 		temp = 0; DSK_SEL = temp;
> 
> The code generated was CLR.B and MOV.B respectively.  Can anyone
> elucidate?  Notice that here the assembly language programmer might
> well have fallen into the same trap as the C compiler.

On a vanilla 68000, the CLR instruction does a read before writing the
zero.  If the memory has parity checking that needs to be initialized
by writing a value to memory before doing any reads (like the IBM-PC)
then CLR is NOT what you want to use.

The read/modify/write behavior was fixed on the 68010 -- another
reason why I've heard the 68010 called a "finished" 68000....

NB: Don't write any 68000 BITBLT code using CLR.
-- 
-Landon Dyer, Atari Corp.	    {sun,lll-lcc,imagen}!atari!dyer

The views expressed here do not not		You're a mean one, Mr. Grinch,
necessarily reflect those of Atari Corp.	 There're segments in your soul