Ambiguous C?

[Chris Torek]

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