greg@utcsri.UUCP (05/19/87)
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...