Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utcsri!greg
From: greg@utcsri.UUCP
Newsgroups: comp.lang.c
Subject: Re: volatile, was C vs assembler
Message-ID: <4786@utcsri.UUCP>
Date: Mon, 18-May-87 20:09:55 EDT
Article-I.D.: utcsri.4786
Posted: Mon May 18 20:09:55 1987
Date-Received: Tue, 19-May-87 01:56:22 EDT
References: <165@mas1.UUCP> <175400003@uxc.cso.uiuc.edu>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 40
Summary: 

In article <175400003@uxc.cso.uiuc.edu> hamilton@uxc.cso.uiuc.edu writes:
>jda@mas1 (James D. Allen) says:
>> 	#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?
>
>    check your 68000 processor manual.  under "CLR", it points out:
>"a memory destination will be read before it is written to".
>
This is a case of choosing one of two apparently equivalent pieces of
C code, in order to work around what is arguably a microcode bug. This
type of behaviour ( CLR reading before writing ) is precisely the kind
of weirdness that compilers are supposed to insulate us from.

The ANSI 'volatile' feature can potentially provide this service, if
I understand it correctly. If I write:

#define DSK_SEL (*(char *volatile )0xf12345)	/* not readable */

And then	DSK_SEL = 0;

...then a 68000 compiler may *not* generate a CLR instruction, since the
fact that the location is volatile implies that the uncalled-for read
may not take place. I believe the 68020 CLR op does not generate the
redundant read; if so, then the compiler can use a CLR if it knows the
target is an '020. The point is that I should not have to know about
such weirdnesses as this, I should only have to tell the compiler which
locations are 'volatile' and let it keep itself and the machine in line.

Am I right about 'volatile' in this context? If so, is there actually
a 68k compiler yet that handles this case properly?


-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...