[ECOS] Gcc and the volatile keyword

[Chuck McManis]

So I'm inspecting the read code in my ethernet driver to see if there are 
any obvious mistakes. (or even subtle ones ;-) and because I modelled it 
after the Rhine driver that is supposed to work already (I'm not saying 
that it doesn't, just have to be sure and be explicit in my assumptions) 
and the receive code uses the macro _SU32 to access the read descriptor 
long words.

The definition is:
#define _SU32( _base_, _offset_) \
         *((volatile cyg_uint32 *)((CYG_ADDRWORD)_base_+(_offset_)))

And a read descriptor has four elements, the flags, the received length, 
the buffer pointer, and a pointer to the next descriptor.

So would be considered acceptable/portable to code something liked

/* An element in the ring of read descriptors */
struct vt8325_rdd {
	cyg_unint32		flags;
	cyg_unit32		len;
	cyg_uint8		*buf;
	struct vt8325_rdd	*nxt;
};

And then in the function :
	volatile struct vt8325_rdd	*rdes;

	if (0 == (rdes->flags & VT8325_RDES_OWNED)) {
		... not owned ...

	}

The question is whether the volatile keyword is transitive to the structure 
elements through a pointer, or if only the pointer to the structure is 
considered volatile? And if its the latter and I explicity coded it:

/* An element in the ring of read descriptors */
struct vt8325_rdd {
	volatile cyg_unint32		flags;
	volatile cyg_unit32		len;
	volatile cyg_uint8		*buf;
	volatile struct vt8325_rdd	*nxt;
};

Would that insure that values would not be left in the registers?

And on a more global note, I've already told the HAL to allocate this 
memory out of uncached memory space so if I'm not spin looping on these 
values do I even need volatile?

--Chuck


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss