Ambiguous C?
Chris Torek
chris at mimsy.UUCP
Thu Apr 27 09:34:45 AEST 1989
In article <111 at ssp1.idca.tds.philips.nl> roelof at idca.tds.PHILIPS.nl
(R. Vuurboom) writes:
>The intention of the code is to do an int (on the motorola a long)
>access and then determine the 14th bit.
>
>The compiler generated a byte access for 2 bytes further and then tested
>the 6th bit. For locations in memory this will deliver the same result
>however a byte access to the register caused a bus timeout error to occur.
>... Does C specify which (if any) interpretation is correct?
No. In the absence of external constraints, the compiler is free to make
this sort of `optimisation'. The traditional approach has been to compile
device drivers with some or all optimisations disabled. Another would be
to teach your compiler that locations near 0 (this example uses 0) are
`special'. The simplest approach, however, is probably to use volatile:
>#define SCUCMD 0
>#define SCU_BDID 0x2000 /* bit 14 */
>
>error()
>{
> if ( (*(int *)(SCUCMD)) & SCU_BDID )
> ;
>}
if (*(int volatile *)SCUCMD & SCU_BDID)
/* void */;
or, better,
struct scudevice {
long scu_csr; /* command/status register */
long scu_data; /* or whatever */
};
#define SCUADDR 0
#define SCU ((struct scudevice volatile *)SCUADDR)
/*
* Bits in scu_csr.
*/
...
#define SCU_BDID 0x2000
...
if (SCU->scu_csr & SCU_BDID)
If your compiler does not understand `volatile', and has no way to
disable optimisation, you are out of luck. (You can resort to assembly
language subroutines.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris at mimsy.umd.edu Path: uunet!mimsy!chris
More information about the Comp.lang.c
mailing list